From nobody Thu Mar 5 21:50:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E241ACC8B for ; Thu, 5 Mar 2015 21:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKvs2JlDQOI4 for ; Thu, 5 Mar 2015 21:50:24 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FB71ACC8C for ; Thu, 5 Mar 2015 21:50:24 -0800 (PST) Received: by padfb1 with SMTP id fb1so39615392pad.7 for ; Thu, 05 Mar 2015 21:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JFimXT7VZ44LNJQlpMPEQ5DYN9xcagByZiqePDWcJIs=; b=0Jofq+vHCfg6ka7hEn4ZzTMDtoy1KQRi2WydEx2GI/WEayLevCXMFAsuyi70P+bFD6 ITUUW7sR3bw5C6dTgYaSookO51OVrA+j1HIweEAuIFBEipCtLEDDnoOfuNBPFExoE78x Ld2gtWrQh3rANyfzDoArRtzAfMyIzPeVWx8ZYS8MB8BeVbV9E0isFFX8xfkTlycqJBwb RWN8E3WhqVT8l+deOO3xygg6sRYL0DHATPNcaFf0G4kwlBW0+pRJNb8bg/hcjyTDJnAP KeE6T/nM7uKXCgzLBGf0UO1vY7emp3eWOWaYMwqeyu6cFHnFc0PL9VNoWiWZKgu2lHKU 3dXA== X-Received: by 10.66.66.75 with SMTP id d11mr22458315pat.132.1425621023635; Thu, 05 Mar 2015 21:50:23 -0800 (PST) Received: from [192.168.248.115] (c-24-6-60-244.hsd1.ca.comcast.net. [24.6.60.244]) by mx.google.com with ESMTPSA id ie1sm8456672pbc.86.2015.03.05.21.50.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 21:50:23 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Douglas Otis In-Reply-To: <751783280.47157.1423594977717.JavaMail.zimbra@peachymango.org> Date: Thu, 5 Mar 2015 21:50:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <86C6FC4E-AB67-4EDB-8DD6-85781D1FDF6D@gmail.com> References: <01PI0N0XDKNA000052@mauve.mrochek.com> <1062018335.31774.1423557232665.JavaMail.zimbra@peachymango.org> <751783280.47157.1423594977717.JavaMail.zimbra@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Tim Draegen , dmarc , "Murray S. Kucherawy" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] interoperability draft for review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 06 Mar 2015 05:50:26 -0000 > On Feb 10, 2015, at 11:02 AM, Franck Martin = wrote: >=20 > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Tim Draegen" , "dmarc" , = ned+dmarc@mrochek.com > Sent: Tuesday, February 10, 2015 9:43:52 AM > Subject: Re: [dmarc-ietf] interoperability draft for review >=20 > On Tue, Feb 10, 2015 at 12:33 AM, Franck Martin = wrote: > > I don't believe the use of X-Original-=46rom is described in any RFC = currently. > > If we're going to talk about it in section 4.3 we need to talk about = how > > it's actually used or refer to some place that does. >=20 > it is RFC5703 >=20 > That's Original-From, so I guess just mention that the X- version was = the pre-standardization name and might still be in use in some places. > I'll check the text but there is something like this. >=20 > Aside: I'm surprised that RFC5703 doesn't include the registration = template required by RFC3864. > It is listed here: = https://www.iana.org/assignments/message-headers/message-headers.xhtml#per= m-headers Dear Franck, Nice Draft.=20 After attending a conference dominated by what could be described as = mass mailers, few expressed concerns about DMARC's impact on often = popular uses of email. As such, the draft = http://tools.ietf.org/html/draft-otis-dmarc-author-align was written to = bring forward plausible approaches to deal with problems created by = large user email providers abusing DMARC. There really needs to be = better solutions than overriding a domain's =E2=80=9Creject=E2=80=9D = with =E2=80=9Cquarantine=E2=80=9D. =46rom an email compatibility = perspective, having a domain level assertion (that could be similarly = overridden) permitting alignment with the Sender header field when = present would spur change in how MUAs expose header fields playing a = significant role in message handling. Such a change may take a period of = time before this method is sufficiently supported. In the meantime, many = users are finding themselves retrieving legitimate messages out of their = spam folder which is teaching the wrong lesson. =20 Alternatively, DMARC could take a bold step and redefine roles of the = header fields by introducing a new header field able to carry = non-aligned Author roles. With DMARC, the =46rom may be unable to = retain its traditional role. By adding a header field =E2=80=9CAuthor" = (instead of X-Original-From) not inadvertently exposed by an MUA to = unwary users, this would allow mailing-lists and international email = addresses necessary sanctuary from DMARC=E2=80=99s overly simplistic = policy scheme. It is not 2005 anymore. We are seeing bot-nets take advantage of any = weakness found or induced with DKIM or SPF. We are working on better = methods for detecting BGP injections, and attempting to correlate = similar abuse methods. It is really unfortunate there are cases where = DKIM remains vulnerable. It also seems many of the vulnerabilities = being exploited are also more than 1 year old. This situation would be = improved by offering a comprehensive definition of a valid DKIM = signature. No spec is perfect. Once one realizes what it takes to = detect BGP injections, SMTP/DANE begins to look much better. Regards, Douglas Otis= From Jason.Bodnar@blackbaud.com Mon Mar 9 16:15:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D621A87CE for ; Mon, 9 Mar 2015 16:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 C-Jj-QZLz0pC for ; Mon, 9 Mar 2015 16:15:33 -0700 (PDT) Received: from esa2.blackbaud.iphmx.com (esa2.blackbaud.iphmx.com [68.232.143.100]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421B01A87C7 for ; Mon, 9 Mar 2015 16:15:33 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5600,1067,7735"; a="22807339" X-IronPort-AV: E=Sophos;i="5.11,371,1422939600"; d="scan'208";a="22807339" Received: from mail4.blackbaud.com (HELO CHS0PEXCHCASS03.blackbaud.global) ([216.235.192.23]) by esa2.blackbaud.iphmx.com with ESMTP; 09 Mar 2015 19:15:32 -0400 Received: from CHS0PEXCHMBXS02.blackbaud.global ([169.254.2.176]) by CHS0PEXCHCASS03.blackbaud.global ([10.20.2.77]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 19:15:24 -0400 From: Jason Bodnar To: "dmarc@ietf.org" Thread-Topic: Sending email on behalf of? Thread-Index: AdBavUUKIZ9sOhm4R7ySLnu7dlg3MA== Date: Mon, 9 Mar 2015 23:15:23 +0000 Message-ID: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.1.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 09 Mar 2015 23:39:43 -0000 The company I work for makes software for non-profits. It's often used to h= ost fundraising races and events. Part of the software allows people signed= up for the event ("participants") to send email to their friends and famil= y asking that they make a donation to support them in the event.=0A= =0A= When Yahoo and AOL published their DMARC records we started having delivera= bility problems. Typical an email sent by a participant would look somethin= g like this:=0A= =0A= HELO mail_server@blackbaud.com=0A= MAIL FROM: info@non-profit.org=0A= RCPT TO: a_family_member@some.esp.com=0A= DATA=0A= Sender: Non-profit-name =0A= From: J Doe =0A= To: Mamma Doe =0A= Reply-To: J Doe =0A= Subject: Please help me find a cure for cancer=0A= ...=0A= =0A= =0A= This, of course, does not work well with DMARC because of:=0A= =0A= From: J Doe =0A= =0A= so we changed our emails to:=0A= =0A= HELO mail_server@blackbaud.com=0A= MAIL FROM: info@non-profit.org=0A= RCPT TO: a_family_member@some.esp.com=0A= DATA=0A= Sender: Non-profit-name =0A= From: J Doe =0A= To: Mamma Doe =0A= Reply-To: J Doe =0A= Subject: Please help me find a cure for cancer=0A= ...=0A= =0A= =0A= which now is delivered but, unfortunately, often appears in Mamma Doe's inb= ox as:=0A= =0A= =0A= From: Non-profit-name on behalf of J Doe =0A= =0A= =0A= According to the non-profits we work with, many people who receive these em= ails are wary of them due to what the From looks like in their email client= s. Are there any options for us to send email on behalf of participants who= have email from ESPs with DMARC reject records AND have a meaningful From = in the recipient's mail client?=0A= =0A= The DMARC draft says:=0A= =0A= =0A= DMARC authenticates use of the RFC5322 [MAIL].From domain by requiring that= it matches (is aligned with) an Authenticated Identifier. The RFC5322 [MAI= L].From domain was selected as the central identity of the DMARC mechanism = because it is a required message header field and therefore guaranteed to b= e present in compliant messages, and most MUAs represent the RFC5322 [MAIL]= .From field as the originator of the message and render some or all of this= header field's content to end users.=0A= =0A= =0A= But this seems contrary to information from OpenSPF:=0A= =0A= http://www.openspf.org/Best_Practices/Webgenerated=0A= =0A= The key component is to ensure that the SMTP "MAIL FROM" address is from yo= ur domain. After that, adding "Sender:" or "Reply-To:" headers is good etiq= uette and help direct replies to the proper address.=0A= =0A= =0A= Thank you.=0A= =0A= --=0A= Jason Bodnar=0A= Staff Software Engineer=0A= Blackbaud, Inc.=0A= =0A= From nobody Mon Mar 9 17:01:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34C21ACE5C for ; Mon, 9 Mar 2015 17:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O16u1XEHrsSF for ; Mon, 9 Mar 2015 17:01:22 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id C9EF21ACE56 for ; Mon, 9 Mar 2015 17:01:05 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 7F1C0803BB; Mon, 9 Mar 2015 17:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1425945665; bh=c0a4uVFVew1uwWYJgUjCMipeDlhhNL/tnuzgXuaTPf8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=G6Xs9aPTEsoW3rR9/ftJ5qxDqNsrgKE3J0jQr4bLX2Z5bWC3hEPQH+dPPmBkPlijX vwAqXJAr3SMYhxvxd99/Z1EfOryIGhsVRdE+c9ZeK17KO4ffELDyoMwH7eaecFjqQS L8QQsSF483Q0/1DKBwJiy+0gM7zCNpdRD2pWWh/s= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> Date: Mon, 9 Mar 2015 17:01:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Jason Bodnar Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:01:24 -0000 On Mar 9, 2015, at 4:15 PM, Jason Bodnar = wrote: > The company I work for makes software for non-profits. It's often used = to host fundraising races and events. Part of the software allows people = signed up for the event ("participants") to send email to their friends = and family asking that they make a donation to support them in the = event. >=20 > When Yahoo and AOL published their DMARC records we started having = deliverability problems. Typical an email sent by a participant would = look something like this: >=20 > HELO mail_server@blackbaud.com > MAIL FROM: info@non-profit.org > RCPT TO: a_family_member@some.esp.com > DATA > Sender: Non-profit-name > From: J Doe > To: Mamma Doe > Reply-To: J Doe > Subject: Please help me find a cure for cancer > ... >=20 >=20 > This, of course, does not work well with DMARC because of: >=20 > From: J Doe >=20 > so we changed our emails to: >=20 > HELO mail_server@blackbaud.com > MAIL FROM: info@non-profit.org > RCPT TO: a_family_member@some.esp.com > DATA > Sender: Non-profit-name > From: J Doe > To: Mamma Doe > Reply-To: J Doe > Subject: Please help me find a cure for cancer > ... >=20 >=20 > which now is delivered but, unfortunately, often appears in Mamma = Doe's inbox as: >=20 >=20 > From: Non-profit-name on behalf of J Doe = >=20 >=20 > According to the non-profits we work with, many people who receive = these emails are wary of them due to what the =46rom looks like in their = email clients. Are there any options for us to send email on behalf of = participants who have email from ESPs with DMARC reject records AND have = a meaningful =46rom in the recipient's mail client? No, there aren't. Yahoo and AOL have published policy that they do not = allow their users to use your service (at least not using their AOL or = Yahoo email addresses). If you want to avoid the "on behalf of" bits you might try removing the = Sender: header. Whatever you do, though, it's going to look at least a = little like mail that should be treated with suspicion - you'll need to = compare your options and decide how to minimize that, possibly with some = A/B testing of different options. It's a problem a lot of ESPs who serve small customers with Yahoo and = AOL addresses are seeing. > The DMARC draft says: >=20 >=20 > DMARC authenticates use of the RFC5322 [MAIL].=46rom domain by = requiring that it matches (is aligned with) an Authenticated Identifier. = The RFC5322 [MAIL].=46rom domain was selected as the central identity of = the DMARC mechanism because it is a required message header field and = therefore guaranteed to be present in compliant messages, and most MUAs = represent the RFC5322 [MAIL].=46rom field as the originator of the = message and render some or all of this header field's content to end = users. >=20 >=20 > But this seems contrary to information from OpenSPF: >=20 > http://www.openspf.org/Best_Practices/Webgenerated >=20 > The key component is to ensure that the SMTP "MAIL FROM" address is = from your domain. After that, adding "Sender:" or "Reply-To:" headers is = good etiquette and help direct replies to the proper address. SPF is all about tying a responsible domain to a sending IP address. It = doesn't really bother itself with the From: field much. Similarly, DKIM = is about attaching a responsible domain to a message, one that needn't = be related to any of the other email headers. It's not until you add = DMARC to the mix that there's any requirement for those domains to have = anything to do with the domain in the From: field. Cheers, Steve --=20 Having an Email Crisis? (800) 823-9674=20 Steve Atkins - Word to the Wise - steve@wordtothewise.com From nobody Mon Mar 9 21:29:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EA01A1A4C for ; Mon, 9 Mar 2015 21:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.909 X-Spam-Level: *** X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwRbMls17IGl for ; Mon, 9 Mar 2015 21:29:13 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 87A671A1A3D for ; Mon, 9 Mar 2015 21:29:13 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E8D661C3841; Tue, 10 Mar 2015 13:29:10 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CEE04120EC9; Tue, 10 Mar 2015 13:29:10 +0900 (JST) From: "Stephen J. Turnbull" To: Jason Bodnar In-Reply-To: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> References: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Mar 2015 13:29:10 +0900 Message-ID: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 04:29:15 -0000 Jason Bodnar writes: > According to the non-profits we work with, many people who receive > these emails are wary of them due to what the From looks like in > their email clients. Are there any options for us to send email on > behalf of participants who have email from ESPs with DMARC reject > records AND have a meaningful From in the recipient's mail client? Almost surely not. As Steve Atkins points out, this is precisely what DMARC "p=reject" at those providers is *intended* to prevent.[1] If you can do it, spammers and phishers can do it too. There is a way to avoid DMARC[2] that works in clients that implement the RFCs extremely flexibly, but very few users have clients that handle such messages well, and some clients handle them absymally badly. I can't recommend it in your application. In my experience, the best you can do is 0. Tell your non-profit clients that it's a problem with the "recommender's" mailbox provider (and the recipient's client), which will occur no matter what third party sends the email on their behalf. Perhaps they have suggestions on better phrasing for the display name (see part 2). 1. For each email, check for a restrictive DMARC policy for the apparent sender, and if not, send the message with the "optimal" message header. (For bonus points you might be able to cache the policy for popular sending domains, but caching for long periods is risky as the TTL on the DMARC policy record is usually only a few minutes.) 2. If the policy is restrictive, "preformat" the display name part of the header as well as you can, and use your address as the address part. Example: From: "John Doe (jdoe@dmarc-abuser.com) via NPO" You may even be able to omit the quotation marks in the display name part, but that's a little risky because of the "." (IIRC it's technically OK in a comment, i.e., in parentheses, but I've seen clients and MTAs complain anyway.) I suspect that you can still get screwed up here, as some MUAs automatically add the address with display name to a contact list, and will proceed to use the display name from the contact list in preference to the display name in From. Then you could get this in Mama Doe's mail client: From: "John Doe (jdoe@dmarc-abuser.com) via NPO" Jane Doe (jane@other-abuser.com) recommended you as a potential contributor to Truly Worthy Cause. because "info@npo.org" is the address used to look up the display name in the contact list, and the client just stores the display name in >From verbatim, as an alternative "real name" for that address in the contact list. That looks even more suspicious to me. In that case, the strategy you are already using is probably the best available. Footnotes: [1] Yahoo! and AOL use p=reject because spammers stole contact lists from their users, and use those stolen lists to do exactly what you want to do, but without having the address owner's permission. [2] Eg, send the actual message with the headers you want to present as a MIME message/rfc822 attachment, and put your real address in the outer message's From field. From nobody Tue Mar 10 05:21:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226901ACD04 for ; Tue, 10 Mar 2015 05:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iPlUrHz1-Av for ; Tue, 10 Mar 2015 05:21:42 -0700 (PDT) Received: from mailer3.americangreetings.com (mailer3.americangreetings.com [66.119.43.163]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5A1ACDCE for ; Tue, 10 Mar 2015 05:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1425990097; x=1457526097; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=M3dL7BrqmHIPyhdeQ+ixW29qbc+vNwoVe08Vv0Y33ws=; b=pCjdd5170vUUqUtwk+kes/pyxH9mCMw0TtymwpY22zptyLEmAhAOn+McJK6OANwZ J9p59j2ZWb4vRrgq0NYSwMajZZrRRU/ropo26JQL2FfYwdL8RusWmVcZZ7G06KHk exRxdO3deULJMs8bOhEw7ZrgkWeuJZbb70y3oliykHs=; Received: from [66.119.43.83] ([66.119.43.83:48196] helo=dc3-mbox.ops.ag.com) by momentum7 (envelope-from ) (ecelerity 3.5.9.42398 r(Platform:3.5.9.0)) with ESMTP id 8E/3D-12791-1D1EEF45; Tue, 10 Mar 2015 08:21:37 -0400 Received: from [10.10.232.59] ([10.10.232.59]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with SMTP id t2ACLbU9025753 for ; Tue, 10 Mar 2015 08:21:38 -0400 Message-ID: <54FEE1D2.90500@americangreetings.com> Date: Tue, 10 Mar 2015 08:21:38 -0400 From: "M. Hammer" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> In-Reply-To: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:21:50 -0000 Jason, You can pattern your approach on what we at American Greetings do for our card notifications. The non-profit should send as themselves (without a sender field) and put something in the subject line that indicates the individual who is making the request through the non-profit. You can use the reply-to field to allow the recipient to reply directly to the originator of the request if they choose. This allows the non-profit to publish their own SPF/DKIM/DMARC records without worrying about the records of other domains. Both Steve and Stephan are correct in what they wrote in response to your question. Mike On 3/9/2015 7:15 PM, Jason Bodnar wrote: > The company I work for makes software for non-profits. It's often used to host fundraising races and events. Part of the software allows people signed up for the event ("participants") to send email to their friends and family asking that they make a donation to support them in the event. > > When Yahoo and AOL published their DMARC records we started having deliverability problems. Typical an email sent by a participant would look something like this: > > HELO mail_server@blackbaud.com > MAIL FROM: info@non-profit.org > RCPT TO: a_family_member@some.esp.com > DATA > Sender: Non-profit-name > From: J Doe > To: Mamma Doe > Reply-To: J Doe > Subject: Please help me find a cure for cancer > ... > > > This, of course, does not work well with DMARC because of: > > From: J Doe > > so we changed our emails to: > > HELO mail_server@blackbaud.com > MAIL FROM: info@non-profit.org > RCPT TO: a_family_member@some.esp.com > DATA > Sender: Non-profit-name > From: J Doe > To: Mamma Doe > Reply-To: J Doe > Subject: Please help me find a cure for cancer > ... > > > which now is delivered but, unfortunately, often appears in Mamma Doe's inbox as: > > > From: Non-profit-name on behalf of J Doe > > > According to the non-profits we work with, many people who receive these emails are wary of them due to what the From looks like in their email clients. Are there any options for us to send email on behalf of participants who have email from ESPs with DMARC reject records AND have a meaningful From in the recipient's mail client? > > The DMARC draft says: > > > DMARC authenticates use of the RFC5322 [MAIL].From domain by requiring that it matches (is aligned with) an Authenticated Identifier. The RFC5322 [MAIL].From domain was selected as the central identity of the DMARC mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most MUAs represent the RFC5322 [MAIL].From field as the originator of the message and render some or all of this header field's content to end users. > > > But this seems contrary to information from OpenSPF: > > http://www.openspf.org/Best_Practices/Webgenerated > > The key component is to ensure that the SMTP "MAIL FROM" address is from your domain. After that, adding "Sender:" or "Reply-To:" headers is good etiquette and help direct replies to the proper address. > > > Thank you. > > -- > Jason Bodnar > Staff Software Engineer > Blackbaud, Inc. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Tue Mar 10 05:51:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FA31ACE41 for ; Tue, 10 Mar 2015 05:51:42 -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 H1YofTdFk1cX for ; Tue, 10 Mar 2015 05:51:35 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0071ACDE8 for ; Tue, 10 Mar 2015 05:51:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2031; t=1425991880; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zH6K+8b6MS826zoSQXh39i3lAKM=; b=mq1uTI8Hq+0ijkzJJoNt QX5BJhst0r+VJTcgR6vd8p54nO3IqKIgQ/9eIzNYwopjbQVg9xUqu4aI7XF61uyP Szg9dtvtUwAuOeAXs+jeLdak56AACyNUal+OWyGz0mO+7r5WfkiV+3//Mc+2RL5c 7+XxoANE4qr7SVqLCMJP+wo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Mar 2015 07:51:20 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3996897724.103225.2864; Tue, 10 Mar 2015 07:51:20 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2031; t=1425991708; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xc8idA5 CEyvEpp71q0pwgid4bSEkzEUHSoW7sOE/9Ao=; b=EFBrUonX9rqBwrp961rcklM LcHeSgNFppteb5+J1iaeeT+i0weBRnIPJAUvnDfwLHo0/D69JPfdA3vadc+yd/le j8RtwD9huAtFSwfxDWVTXmv6RjNy8NVUgKOY7z1ERNzahT2s8j2X5J3h78TX3Ekr Bpv47EDMz7ZTcNPBpU/o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Mar 2015 08:48:28 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2589211659.9.504; Tue, 10 Mar 2015 08:48:27 -0400 Message-ID: <54FEE8C6.9020309@isdg.net> Date: Tue, 10 Mar 2015 08:51:18 -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: Steve Atkins , "dmarc@ietf.org" References: <80504D54F63C8C4ABE853DEB0FD3860681BC4DD2@CHS0PEXCHMBXS02.blackbaud.global> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jason Bodnar Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:51:42 -0000 On 3/9/2015 8:01 PM, Steve Atkins wrote: >> But this seems contrary to information from OpenSPF: >> >> http://www.openspf.org/Best_Practices/Webgenerated >> >> The key component is to ensure that the SMTP "MAIL FROM" address is from your domain. After that, adding "Sender:" or "Reply-To:" headers is good etiquette and help direct replies to the proper address. > > SPF is all about tying a responsible domain to a sending IP address. It doesn't really bother itself with the From: field much. Similarly, DKIM is about attaching a responsible domain to a message, one that needn't be related to any of the other email headers. It's not until you add DMARC to the mix that there's any requirement for those domains to have anything to do with the domain in the From: field. > Small reminder point -- Independent of DMARC, DKIM does have a single requirement to bind the 5322.from header at a minimum. So that "separation" was never really there as DKIM was updated to describe as such. It was not possible to make that "separation." DMARC, like all the rest, SSP, ADSP, etc, is just a policy layer; basically an enforcement of a 1st party singer requirement. The problem we face (for nearly 10 years now) is that we lack 3rd party policies. DMARC is ready for it. Just got to do it. When ATPS was done, there was no wide industry support for ADSP but we knew it was desirable. It was replaced with a report-generating "Super ADSP version called DMARC that did get industry interest. Since DMARC does allow for authentication/authorization extensions, IMO, its time to restart and push an ATPS version for DMARC. Feasible or not at a higher scale (which I am not convinced it is not), the IETF should not restrict this practical protocol framework, automated, non-subjective, plug and play, "lower cost" solution. Allow implementators to explore the management of 3rd party policies. Not everyone is going to need to have high-end scale versions of this in order to make it useful. -- HLS From nobody Tue Mar 10 09:14:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3591A1B98 for ; Tue, 10 Mar 2015 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8eDSmbM6u20 for ; Tue, 10 Mar 2015 09:14: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 2598E1A1BA9 for ; Tue, 10 Mar 2015 09:14:46 -0700 (PDT) Received: (qmail 51734 invoked from network); 10 Mar 2015 16:14:35 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 10 Mar 2015 16:14:35 -0000 Date: 10 Mar 2015 16:14:13 -0000 Message-ID: <20150310161413.4872.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: stephen@xemacs.org Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:14:51 -0000 > From: "John Doe (jdoe@dmarc-abuser.com) via NPO" I would try some tests particularly at AOL before I did that. AOL mail tends to reject anything that looks like a munged AOL address. The least painful approach may be to tell people with AOL addresses, sorry, please get a different address. R's, John From nobody Tue Mar 10 09:42:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935BE1A00E4 for ; Tue, 10 Mar 2015 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2DszjGS985Ss for ; Tue, 10 Mar 2015 09:42:18 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8991A00E9 for ; Tue, 10 Mar 2015 09:42:18 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E80421C3888; Wed, 11 Mar 2015 01:42:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C14C2120EC9; Wed, 11 Mar 2015 01:42:16 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20150310161413.4872.qmail@ary.lan> References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Mar 2015 01:42:16 +0900 Message-ID: <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:42:20 -0000 John Levine writes: > > From: "John Doe (jdoe@dmarc-abuser.com) via NPO" > > I would try some tests particularly at AOL before I did that. AOL > mail tends to reject anything that looks like a munged AOL address. > > The least painful approach may be to tell people with AOL addresses, > sorry, please get a different address. Oh, boy, oh, boy, am I glad I *can* tell my users to get another address or suffer. But I don't see how the OP can. First of all, they aren't his users, they are his client's users. Second of all, I can't imagine the client telling *its* donors they have to get a new address to recommend donation to friends and family. And third (the killer) the recipients aren't going to recognize the new address, and so it's going to look as suspicious as the stupid Outlook-style headers. Brother-I-feel-your-pain-ly y'rs, Steve From nobody Tue Mar 10 09:56:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27E71A00D6 for ; Tue, 10 Mar 2015 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pDZuhrNncjY for ; Tue, 10 Mar 2015 09:56:43 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0087.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AB51A6FE9 for ; Tue, 10 Mar 2015 09:55:53 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.1.125.2; Tue, 10 Mar 2015 16:55:32 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.170]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.170]) with mapi id 15.01.0125.002; Tue, 10 Mar 2015 16:55:32 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Sending email on behalf of? Thread-Index: AQHQW02pUGfdIWLMs0uwC7PJNeeC1Z0V67oAgAACuAA= Date: Tue, 10 Mar 2015 16:55:31 +0000 Message-ID: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.134] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(61604003)(199003)(51704005)(189002)(13464003)(377454003)(76176999)(46102003)(102836002)(15975445007)(105586002)(50986999)(97736003)(106356001)(106116001)(54356999)(64706001)(66066001)(107886001)(2351001)(77156002)(450100001)(62966003)(86362001)(110136001)(2950100001)(2900100001)(68736005)(101416001)(92566002)(33656002)(2656002)(87936001)(19580395003)(19580405001)(2501003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB605; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB605; x-forefront-prvs: 051158ECBB received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 16:55:31.8062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB605 Archived-At: Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:56:45 -0000 > And third (the killer) the > recipients aren't going to recognize the new address, and so it's > going to look as suspicious as the stupid Outlook-style headers. What's "stupid" about Outlook style headers? How should it look? -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Stephen J. Turnbul= l Sent: Tuesday, March 10, 2015 9:42 AM To: John Levine Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Sending email on behalf of? John Levine writes: > > From: "John Doe (jdoe@dmarc-abuser.com) via NPO" >=20 > I would try some tests particularly at AOL before I did that. AOL > mail tends to reject anything that looks like a munged AOL address. >=20 > The least painful approach may be to tell people with AOL addresses, > sorry, please get a different address. Oh, boy, oh, boy, am I glad I *can* tell my users to get another address or suffer. But I don't see how the OP can. First of all, they aren't his users, they are his client's users. Second of all, I can't imagine the client telling *its* donors they have to get a new address to recommend donation to friends and family. And third (the killer) the recipients aren't going to recognize the new address, and so it's going to look as suspicious as the stupid Outlook-style headers. Brother-I-feel-your-pain-ly y'rs, Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Mar 10 11:34:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3E51A87CA for ; Tue, 10 Mar 2015 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.309 X-Spam-Level: * X-Spam-Status: No, score=1.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, 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 y48H0TW6DAf6 for ; Tue, 10 Mar 2015 11:34:40 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EB0191A87C9 for ; Tue, 10 Mar 2015 11:34:39 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9BD961C387F; Wed, 11 Mar 2015 03:34:38 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 76D7D120EC9; Wed, 11 Mar 2015 03:34:38 +0900 (JST) From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Mar 2015 03:34:38 +0900 Message-ID: <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:34:41 -0000 Terry Zink writes: > > And third (the killer) the recipients aren't going to recognize > > the new address, and so it's going to look as suspicious as the > > stupid Outlook-style headers. > > What's "stupid" about Outlook style headers? How should it look? Technically, maybe nothing, in the OP's case. Depends on how much involvement the putative author (John Doe) has in composition or approval of the message text. If "none", then I suppose the "on behalf of" in the From field as displayed by Outlook has the semantics it normally has in English: the NPO wrote and sent the message as the fully responsible agent of John Doe, with no intervention from Mr. Doe. In most cases I see, however, Sender is a robot Mediator, typically a mailing list. In those cases the Outlook header display is the equivalent of "From the White House Mailroom on behalf of Barack Obama". Practically, the OP's client NPO wants the message to look like a personal invitation from an existing donor to another potential donor who is an acquaintance. This is being done with the permission (at least) of the existing donor. So I don't see why Outlook (or any MUA) would fail to display it that way. As far as I can see, if the message is legitimate (ie, has the permission of the existing donor and owner of the intended From address), the "on behalf of" style is unuseful to anyone, and clearly confusing to many non-technical users. I don't know of any cases where it's useful, given that illegitimate messages can (and do) avoid suspicious display by the simple expedient of omitting the Sender field. "Stupid" is perhaps unnecessarily derogatory, but it's an idea that has proven to be more trouble than it's worth in practice, and it should be retired (or at least made an option). How should it look? How about From: John Doe Sender: NPO or just From: John Doe for that matter? Sender is not very useful to the 99.44% of mail users who aren't RFC nerds, since no MUA I know has a "report delivery problem to sender" function (let alone a hotkey for it), and those users aren't going to know that a problem with message delivery should be reported to Sender (rather than From). Regards, From nobody Tue Mar 10 11:43:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F081A1B51 for ; Tue, 10 Mar 2015 11:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_INVITATION=-2, 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 BI-zrHUyS9A8 for ; Tue, 10 Mar 2015 11:43:35 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9A41A8707 for ; Tue, 10 Mar 2015 11:43:31 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 14:43:30 -0400 From: "MH Michael Hammer (5304)" To: "Stephen J. Turnbull" , Terry Zink Thread-Topic: [dmarc-ietf] Sending email on behalf of? Thread-Index: AQHQW01ZFEKKsdC/tk6D43xCz+huhZ0WLsgAgAADtICAABuxAP//vdIw Date: Tue, 10 Mar 2015 18:43:29 +0000 Message-ID: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:43:38 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Stephen J. > Turnbull > Sent: Tuesday, March 10, 2015 2:35 PM > To: Terry Zink > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Sending email on behalf of? >=20 > Terry Zink writes: >=20 > > > And third (the killer) the recipients aren't going to recognize > >= the new > address, and so it's going to look as suspicious as the > > stupid Outlo= ok-style > headers. > > > > What's "stupid" about Outlook style headers? How should it look? >=20 > Technically, maybe nothing, in the OP's case. Depends on how much > involvement the putative author (John Doe) has in composition or approval > of the message text. If "none", then I suppose the "on behalf of" in the > From field as displayed by Outlook has the semantics it normally has in > English: the NPO wrote and sent the message as the fully responsible agen= t > of John Doe, with no intervention from Mr. Doe. In most cases I see, > however, Sender is a robot Mediator, typically a mailing list. In those = cases > the Outlook header display is the equivalent of "From the White House > Mailroom on behalf of Barack Obama". >=20 If it had the format you suggest it would almost certainly be fraudulent. I= f it was legitimate it would be from @eop.gov. > Practically, the OP's client NPO wants the message to look like a persona= l > invitation from an existing donor to another potential donor who is an > acquaintance. This is being done with the permission (at > least) of the existing donor. So I don't see why Outlook (or any MUA) wo= uld > fail to display it that way. >=20 How does the recipient know that the NPO has permission? In fact, how does = the recipient know that it is really the NPO if it is spoofing the existing= donor's email address?=20 > As far as I can see, if the message is legitimate (ie, has the permission= of the > existing donor and owner of the intended From address), the "on behalf of= " > style is unuseful to anyone, and clearly confusing to many non-technical > users. I don't know of any cases where it's useful, given that illegitim= ate > messages can (and do) avoid suspicious display by the simple expedient of > omitting the Sender field. "Stupid" is perhaps unnecessarily derogatory,= but > it's an idea that has proven to be more trouble than it's worth in practi= ce, and > it should be retired (or at least made an option). >=20 > How should it look? How about >=20 > From: John Doe > Sender: NPO >=20 This is meaningless to the recipient in terms of authenticating the relatio= nship or the From: if the From: email address is "spoofed". > or just >=20 > From: John Doe >=20 This is meaningless to the recipient in terms of authenticating the relatio= nship or the From: if the From: email address is "spoofed". It falls into t= he category of : "If you could read my mind". > for that matter? Sender is not very useful to the 99.44% of mail users w= ho > aren't RFC nerds, since no MUA I know has a "report delivery problem to > sender" function (let alone a hotkey for it), and those users aren't goin= g to > know that a problem with message delivery should be reported to Sender > (rather than From). >=20 Sender in its present incarnation is not particularly useful, period. From nobody Tue Mar 10 12:32:55 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBF01A8865 for ; Tue, 10 Mar 2015 12:32:53 -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 e4kMYFfjHUSv for ; Tue, 10 Mar 2015 12:32:52 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 020E21A8726 for ; Tue, 10 Mar 2015 12:32:48 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E32FF1C387F; Wed, 11 Mar 2015 04:32:47 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BDE31120EC9; Wed, 11 Mar 2015 04:32:47 +0900 (JST) From: "Stephen J. Turnbull" To: "MH Michael Hammer (5304)" In-Reply-To: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Mar 2015 04:32:47 +0900 Message-ID: <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:32:54 -0000 MH Michael Hammer (5304) writes: > How does the recipient know that the NPO has permission? In fact, > how does the recipient know that it is really the NPO if it is > spoofing the existing donor's email address? He doesn't, and he doesn't. That's my point: absent some form of authentication, he doesn't know, and Outlook's use of "on behalf of" doesn't help one bit. > This is meaningless to the recipient in terms of authenticating the > relationship or the From: if the From: email address is "spoofed". Terry specifically asked what I don't like about Outlook's header display. There was no question about authentication AFAICS, and I certainly didn't try to answer any such question. > Sender in its present incarnation is not particularly useful, > period. I don't disagree. I just think Outlook's display makes it worse than useless. From nobody Tue Mar 10 14:14:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD401A88AC for ; Tue, 10 Mar 2015 14:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rkBKKc4VicSc for ; Tue, 10 Mar 2015 14:14:08 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FC11A014B for ; Tue, 10 Mar 2015 14:14:08 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.125.2; Tue, 10 Mar 2015 21:14:06 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.170]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.170]) with mapi id 15.01.0125.002; Tue, 10 Mar 2015 21:14:06 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Sending email on behalf of? Thread-Index: AQHQW02pUGfdIWLMs0uwC7PJNeeC1Z0V67oAgAACuACAABytAIAAAnmAgAANxoCAABop0A== Date: Tue, 10 Mar 2015 21:14:05 +0000 Message-ID: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.134] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(450100001)(92566002)(86362001)(106356001)(77156002)(62966003)(50986999)(2950100001)(2900100001)(54356999)(105586002)(93886004)(33656002)(68736005)(106116001)(76176999)(101416001)(102836002)(2501003)(107886001)(2351001)(97736003)(2656002)(87936001)(110136001)(64706001)(66066001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 051158ECBB received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 21:14:05.6518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:14:10 -0000 Pj4gU2VuZGVyIGluIGl0cyBwcmVzZW50IGluY2FybmF0aW9uIGlzIG5vdCBwYXJ0aWN1bGFybHkg dXNlZnVsLA0KPj4gcGVyaW9kLg0KDQo+IEkgZG9uJ3QgZGlzYWdyZWUuICBJIGp1c3QgdGhpbmsg T3V0bG9vaydzIGRpc3BsYXkgbWFrZXMgaXQgd29yc2UgdGhhbg0KPiB1c2VsZXNzLg0KDQpUaGUg T3V0bG9vayBjbGllbnQgaXMgdXNlZCBpbiBtYW55IHBsYWNlcyAtIGl0IGhvb2tzIHVwIHdpdGgg dGhlIEV4Y2hhbmdlIE1UQSBidXQgYWxzbyB3aXRoIG11bHRpcGxlIG90aGVyIG1haWwgc2Vydmlj ZXMgbGlrZSBZYWhvbyBNYWlsLCBIb3RtYWlsLCBHbWFpbC4uLiBhbnl0aGluZyB0aGF0IHN1cHBv cnRzIG1haWwuIEl0IGhhcyBhbHNvIGJlZW4gYXJvdW5kIGZvciBhcyBsb25nIGFzIEkgY2FuIHJl bWVtYmVyLCBnb2luZyBiYWNrIGludG8gdGhlIDE5OTAncyBhbmQgaGFzIGEgdmVyeSBsYXJnZSBp bnN0YWxsLWJhc2UuIEl0IHByZS1kYXRlcyBhbnkgZW1haWwgYXV0aGVudGljYXRpb24gc3RhbmRh cmQsIGFuZCBzdXBwb3J0cyAyODIyIGhlYWRlcnMgbGlrZSBTZW5kZXIsIFJlcGx5LVRvLCBldGMu DQoNClNheWluZyBPdXRsb29rJ3MgZGlzcGxheSBpcyAid29yc2UgdGhhbiB1c2VsZXNzIiBmYWls cyB0byBjb25zaWRlciB0aGUgY29udGV4dCBpbiB3aGljaCB3YXMgZGV2ZWxvcGVkIChpbiB0aGUg YWJzZW5jZSBvZiBhZHZpY2UgaXQgZGlkIHdoYXQgaXQgY291bGQpLCB0aGUgbWFzc2l2ZSBpZi10 aGVuLWVsc2UgcGlwZWxpbmUgdGhhdCBtdXN0IHRha2UgYXV0aGVudGljYXRpb24gaW50byBhY2Nv dW50LCB3aGV0aGVyIG9yIG5vdCBpdCBjYW4gdHJ1c3QgZW1haWwgaGVhZGVycywgY2hlY2tpbmcg dGhlIHJlY2lwaWVudCBlbWFpbCBhZGRyZXNzIChIb3RtYWlsLCBHbWFpbCwgWWFob28gYWxsIGhh dmUgc2xpZ2h0bHkgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBvZiBBdXRoZW50aWNhdGlvbi1S ZXN1bHRzIHN0YW1waW5nKSwgaG93IHRvIGRlcGxveSBtYW55IGNoYW5nZXMgdG8gbXVsdGlwbGUg dmVyc2lvbnMgaW4gcHJvZHVjdGlvbiwgaG93IHRvIGF1Z21lbnQgdGhlIGV4cGVyaWVuY2Ugd2l0 aCBFeGNoYW5nZSwgYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIGFkZGluZyBwdWJsaWMgZG9jdW1l bnRhdGlvbiB0byBNU0ROLCBldGMuDQoNClNlZWluZyBhcyBob3cgdGhlcmUgaXNuJ3QgYW55IGNv bnNlbnN1cyBvbiBob3cgTVRBcyBzaG91bGQgZGlzcGxheSB0aGluZ3MsIE91dGxvb2sncyBpbXBs ZW1lbnRhdGlvbiBvZiBkaXNwbGF5aW5nIG11bHRpcGxlIHNlbmRlci9mcm9tL3JlcGx5LXRvICBm aWVsZHMgaXMgb24tcGFyIHdpdGggYWxtb3N0IGFueW9uZSBlbHNlJ3MuDQoNCi0tVGVycnkNCg== From nobody Tue Mar 10 19:19:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720551A885F for ; Tue, 10 Mar 2015 19:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFSMivTHi9Cj for ; Tue, 10 Mar 2015 19:19:44 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BAB4D1A1B9E for ; Tue, 10 Mar 2015 19:19:44 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 2A85D1C38D1; Wed, 11 Mar 2015 11:19:43 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1272A120EC9; Wed, 11 Mar 2015 11:19:43 +0900 (JST) From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Mar 2015 11:19:42 +0900 Message-ID: <878uf46zsx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 11 Mar 2015 02:19:46 -0000 Terry Zink writes: > Seeing as how there isn't any consensus on how MTAs should display > things, Outlook's implementation of displaying multiple > sender/from/reply-to fields is on-par with almost anyone else's. That criterion ("no consensus") is like saying that since there's no consensus on what constitutes great art, my daughter's finger painting is on-par with Picasso's Guernica. We have testimony here (and I can confirm that from observation of Mailman lists, as well as report my personal "Ugh!" reaction) that Outlook's "on behalf of" treatment of the Sender field causes confusion and annoyance for third party services. The ball is in your court, tell us about the benefits, don't tell us that pros and cons don't matter. I'm perfectly willing to believe that it has benefits in environments I have not experienced, I just can't think of any. Especially not in the modern environment where malicious agents will spoof any field that might be displayed to support their frauds. This is the attitude of most in the Mailman community. It won't ameliorate our pain, but at least it will help me to reduce the open hostility my community shows to Outlook over this issue, if you can come up with plausible arguments "pro" this display. BTW, I consider this subthread mildly on-topic, as trying to understand the protocols we propose requires understanding the threat models, and it is fundamental to DMARC that header display is part of any threat model (to the point where DMARC interdicts whole message for the sole purpose of ensuring that "From" is not displayed to the recipient). Regards, Steve From nobody Wed Mar 11 13:14:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201231A86E4 for ; Wed, 11 Mar 2015 13:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 hMRa0SuWA8uX for ; Wed, 11 Mar 2015 13:14:48 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8932C1A854D for ; Wed, 11 Mar 2015 13:14:48 -0700 (PDT) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.1.125.2; Wed, 11 Mar 2015 20:14:46 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.9.45]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.9.45]) with mapi id 15.01.0125.002; Wed, 11 Mar 2015 20:14:46 +0000 From: Terry Zink To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] Sending email on behalf of? Thread-Index: AQHQW02pUGfdIWLMs0uwC7PJNeeC1Z0V67oAgAACuACAABytAIAAAnmAgAANxoCAABop0IAAV4gAgAEpygA= Date: Wed, 11 Mar 2015 20:14:46 +0000 Message-ID: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> <878uf46zsx.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <878uf46zsx.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.116] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2SR01MB608; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(199003)(68736005)(2950100001)(102836002)(77156002)(2900100001)(62966003)(87936001)(2656002)(110136001)(66066001)(86362001)(105586002)(33656002)(64706001)(97736003)(19580405001)(19580395003)(54356999)(50986999)(76176999)(106356001)(106116001)(46102003)(101416001)(93886004)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2SR01MB608; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BY2SR01MB608; BCL:0; PCL:0; RULEID:; SRVR:BY2SR01MB608; x-forefront-prvs: 0512CC5201 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 20:14:46.1886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2SR01MB608 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 11 Mar 2015 20:14:50 -0000 SGksIFN0ZXBoZW4sDQoNCkkgdW5kZXJzdGFuZCB5b3VyIHBvaW50IHRoYXQgc29tZSBVWCBkaXNw bGF5cyBhcmUgYmV0dGVyIHRoYW4gb3RoZXJzLiBIb3dldmVyLCBJJ20gbm90IGdvaW5nIHRvIGdl dCBpbnRvIGEgZGViYXRlIGFib3V0IHRoZSBtZXJpdHMgYW5kIGRyYXdiYWNrcywgYW5kIHVuZGVy IHdoYXQgc2NlbmFyaW9zLCBhYm91dCBob3cgT3V0bG9vayB2cy4gaG93IG90aGVyIG1haWwgY2xp ZW50cyBjaG9vc2UgdG8gZGlzcGxheSBTZW5kZXI6LCBGcm9tOiwgUmVwbHktVG86LCBhbmQgb3Ro ZXIgZmllbGRzLiBJdCdzIG5vdCB3aXRoaW4gbXkgYXJlYSBvZiBvd25lcnNoaXAgbm9yIGhhdmUg SSBsb29rZWQgYW55IHVzYWJpbGl0eSBzdHVkaWVzIHN1cnJvdW5kaW5nIHNob3dpbmcgaXQgYXMg WCB2cy4gWS4gUmF0aGVyLCB3ZSBoYXZlIEludGVybmV0IFJGQ3MgdGhhdCBkZWZpbmUgaG93IHRv IGhhbmRsZSBlbWFpbCBidXQgbm8gUkZDcyBhYm91dCBob3cgdG8gZGlzcGxheSBlbWFpbC4NCg0K VGhlcmUgaXMgYSBsb3Qgb2Ygb3ZlcmxhcCBpbiBzb21lIG1haWwgY2xpZW50cywgYnV0IHRoZXJl IGlzIGFsc28gYW1iaWd1aXR5IGFib3V0IGhvdyB0byBzaG93IGNlcnRhaW4gdGhpbmdzLiBUbyBz YXkgIk15IHVzZXJzIGxpa2UgdGhpcywgYW5kIGRvbid0IGxpa2UgdGhhdCIgaXMgZ29vZCBhbmVj ZG90YWwgZXZpZGVuY2UgYnV0IHdoYXQgcHJvcG9ydGlvbiBvZiBtYWlsIGZsb3cgaXMgdGhhdD8g SG93IHJlcHJlc2VudGF0aXZlIGlzIGl0IGZvciBldmVyeW9uZSBlbHNlPyBIb3cgbXVjaCBkb2Vz IHRoZSBleGlzdGluZyB1c2VyIGJhc2UgdW5kZXJzdGFuZCBvciBldmVuIGNhcmUgYWJvdXQgaG93 IHNvbWV0aGluZyBsaWtlIHRoaXMgaXMgZGlzcGxheWVkPyBJcyBpdCBnb29kIGVub3VnaD8gVGhl c2UgYXJlIG5vdCBxdWVzdGlvbnMgdGhhdCBhcmUgZWFzaWx5IGFuc3dlcmVkLg0KDQpUaGFua3Mu DQoNCi0tIFRlcnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVu IEouIFR1cm5idWxsIFttYWlsdG86c3RlcGhlbkB4ZW1hY3Mub3JnXSANClNlbnQ6IFR1ZXNkYXks IE1hcmNoIDEwLCAyMDE1IDc6MjAgUE0NClRvOiBUZXJyeSBaaW5rDQpDYzogZG1hcmNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gU2VuZGluZyBlbWFpbCBvbiBiZWhhbGYgb2Y/ DQoNClRlcnJ5IFppbmsgd3JpdGVzOg0KDQogPiBTZWVpbmcgYXMgaG93IHRoZXJlIGlzbid0IGFu eSBjb25zZW5zdXMgb24gaG93IE1UQXMgc2hvdWxkIGRpc3BsYXkNCiA+IHRoaW5ncywgT3V0bG9v aydzIGltcGxlbWVudGF0aW9uIG9mIGRpc3BsYXlpbmcgbXVsdGlwbGUNCiA+IHNlbmRlci9mcm9t L3JlcGx5LXRvICBmaWVsZHMgaXMgb24tcGFyIHdpdGggYWxtb3N0IGFueW9uZSBlbHNlJ3MuDQoN ClRoYXQgY3JpdGVyaW9uICgibm8gY29uc2Vuc3VzIikgaXMgbGlrZSBzYXlpbmcgdGhhdCBzaW5j ZSB0aGVyZSdzIG5vDQpjb25zZW5zdXMgb24gd2hhdCBjb25zdGl0dXRlcyBncmVhdCBhcnQsIG15 IGRhdWdodGVyJ3MgZmluZ2VyIHBhaW50aW5nDQppcyBvbi1wYXIgd2l0aCBQaWNhc3NvJ3MgR3Vl cm5pY2EuDQoNCldlIGhhdmUgdGVzdGltb255IGhlcmUgKGFuZCBJIGNhbiBjb25maXJtIHRoYXQg ZnJvbSBvYnNlcnZhdGlvbiBvZg0KTWFpbG1hbiBsaXN0cywgYXMgd2VsbCBhcyByZXBvcnQgbXkg cGVyc29uYWwgIlVnaCEiIHJlYWN0aW9uKSB0aGF0DQpPdXRsb29rJ3MgIm9uIGJlaGFsZiBvZiIg dHJlYXRtZW50IG9mIHRoZSBTZW5kZXIgZmllbGQgY2F1c2VzDQpjb25mdXNpb24gYW5kIGFubm95 YW5jZSBmb3IgdGhpcmQgcGFydHkgc2VydmljZXMuDQoNClRoZSBiYWxsIGlzIGluIHlvdXIgY291 cnQsIHRlbGwgdXMgYWJvdXQgdGhlIGJlbmVmaXRzLCBkb24ndCB0ZWxsIHVzDQp0aGF0IHByb3Mg YW5kIGNvbnMgZG9uJ3QgbWF0dGVyLiAgSSdtIHBlcmZlY3RseSB3aWxsaW5nIHRvIGJlbGlldmUN CnRoYXQgaXQgaGFzIGJlbmVmaXRzIGluIGVudmlyb25tZW50cyBJIGhhdmUgbm90IGV4cGVyaWVu Y2VkLCBJIGp1c3QNCmNhbid0IHRoaW5rIG9mIGFueS4gIEVzcGVjaWFsbHkgbm90IGluIHRoZSBt b2Rlcm4gZW52aXJvbm1lbnQgd2hlcmUNCm1hbGljaW91cyBhZ2VudHMgd2lsbCBzcG9vZiBhbnkg ZmllbGQgdGhhdCBtaWdodCBiZSBkaXNwbGF5ZWQgdG8NCnN1cHBvcnQgdGhlaXIgZnJhdWRzLiAg VGhpcyBpcyB0aGUgYXR0aXR1ZGUgb2YgbW9zdCBpbiB0aGUgTWFpbG1hbg0KY29tbXVuaXR5LiAg SXQgd29uJ3QgYW1lbGlvcmF0ZSBvdXIgcGFpbiwgYnV0IGF0IGxlYXN0IGl0IHdpbGwgaGVscCBt ZQ0KdG8gcmVkdWNlIHRoZSBvcGVuIGhvc3RpbGl0eSBteSBjb21tdW5pdHkgc2hvd3MgdG8gT3V0 bG9vayBvdmVyIHRoaXMNCmlzc3VlLCBpZiB5b3UgY2FuIGNvbWUgdXAgd2l0aCBwbGF1c2libGUg YXJndW1lbnRzICJwcm8iIHRoaXMgZGlzcGxheS4NCg0KQlRXLCBJIGNvbnNpZGVyIHRoaXMgc3Vi dGhyZWFkIG1pbGRseSBvbi10b3BpYywgYXMgdHJ5aW5nIHRvDQp1bmRlcnN0YW5kIHRoZSBwcm90 b2NvbHMgd2UgcHJvcG9zZSByZXF1aXJlcyB1bmRlcnN0YW5kaW5nIHRoZSB0aHJlYXQNCm1vZGVs cywgYW5kIGl0IGlzIGZ1bmRhbWVudGFsIHRvIERNQVJDIHRoYXQgaGVhZGVyIGRpc3BsYXkgaXMg cGFydCBvZg0KYW55IHRocmVhdCBtb2RlbCAodG8gdGhlIHBvaW50IHdoZXJlIERNQVJDIGludGVy ZGljdHMgd2hvbGUgbWVzc2FnZQ0KZm9yIHRoZSBzb2xlIHB1cnBvc2Ugb2YgZW5zdXJpbmcgdGhh dCAiRnJvbSIgaXMgbm90IGRpc3BsYXllZCB0byB0aGUNCnJlY2lwaWVudCkuDQoNClJlZ2FyZHMs DQpTdGV2ZQ0K From nobody Thu Mar 12 08:42:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB11A8A59 for ; Wed, 11 Mar 2015 22:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmapOOYRzjpr for ; Wed, 11 Mar 2015 22:12:32 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2E85E1A00E5 for ; Wed, 11 Mar 2015 22:12:31 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 591161C3852; Thu, 12 Mar 2015 14:12:30 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 33E3F120EC9; Thu, 12 Mar 2015 14:12:30 +0900 (JST) From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> <878uf46zsx.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 12 Mar 2015 14:12:29 +0900 Message-ID: <87pp8e6bpe.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 08:42:29 -0700 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Mar 2015 05:12:37 -0000 Terry Zink writes: > There is a lot of overlap in some mail clients, but there is also > ambiguity about how to show certain things. To say "My users like > this, and don't like that" "Like" and "dislike" are *not* what was reported here. Mail that we should presume is legitimate (based on the OP's testimony) was suspected of being fraudulent merely because of the "on behalf of" display. So "on behalf of" appears to be generating Type II errors (false positive for abuse), while DMARC is intended to prevent Type I errors (false negative for abuse). > is good anecdotal evidence but what proportion of mail flow is > that? How representative is it for everyone else? How much does the > existing user base understand or even care about how something like > this is displayed? Is it good enough? These are not questions that > are easily answered. Nor are they the questions I'm interested in here. I want to know if there are use cases where displaying "on behalf of" is *useful*, or if when it matters, it primarily induces user *mistakes*. Of course to Microsoft's Outlook developers, those are crucial questions. We aren't Outlook developers (not even you), so we don't actually care. I think we do care about user psychology in deciding whether a particular message is abusive, though. From nobody Thu Mar 12 11:44:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2150F1A044F for ; Thu, 12 Mar 2015 11:44:15 -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 eJ4y6-8f-tyl for ; Thu, 12 Mar 2015 11:44:10 -0700 (PDT) Received: from mail.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 764251A00DB for ; Thu, 12 Mar 2015 11:44:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2548; t=1426185839; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=A7/56tU 4q2mJ4/7b3p+u96+PntU=; b=ECKNssykIY2Hezb1lN9GVNtMr6eJqCMWdRUUbJG hzCSI0xOZFrHlrIsACtH3R5DC9GCrxT5pQLWK6NGZI381cdFjymF3k+zQVSdztEw obFqPOIXq+B1OKQXA9GjtfC8PN1KENWGUW62P0DZkfdoJnXUrn7uuY/z8SOSq/Oe a45o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 12 Mar 2015 13:43:59 -0500 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4190853595.1.2288; Thu, 12 Mar 2015 13:43:58 -0500 References: <87vbi979wp.fsf@uwakimon.sk.tsukuba.ac.jp> <20150310161413.4872.qmail@ary.lan> <87mw3k7qjb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2yo7lc1.fsf@uwakimon.sk.tsukuba.ac.jp> <87fv9c7in4.fsf@uwakimon.sk.tsukuba.ac.jp> <878uf46zsx.fsf@uwakimon.sk.tsukuba.ac.jp> <87pp8e6bpe.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87pp8e6bpe.fsf@uwakimon.sk.tsukuba.ac.jp> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <05039388-4BAA-4740-ADDA-904072818ADE@isdg.net> X-Mailer: iPad Mail (12B435) From: Hector Santos Date: Thu, 12 Mar 2015 14:43:58 -0400 To: "Stephen J. Turnbull" Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Sending email on behalf of? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Mar 2015 18:44:15 -0000 > On Mar 12, 2015, at 1:12 AM, Stephen J. Turnbull wrote: >=20 > Terry Zink writes: >=20 >> There is a lot of overlap in some mail clients, but there is also >> ambiguity about how to show certain things. To say "My users like >> this, and don't like that" >=20 > "Like" and "dislike" are *not* what was reported here. Mail that we > should presume is legitimate (based on the OP's testimony) was > suspected of being fraudulent merely because of the "on behalf of" > display. So "on behalf of" appears to be generating Type II errors > (false positive for abuse), while DMARC is intended to prevent Type I > errors (false negative for abuse). >=20 >> is good anecdotal evidence but what proportion of mail flow is >> that? How representative is it for everyone else? How much does the >> existing user base understand or even care about how something like >> this is displayed? Is it good enough? These are not questions that >> are easily answered. >=20 > Nor are they the questions I'm interested in here. I want to know if > there are use cases where displaying "on behalf of" is *useful*, or if > when it matters, it primarily induces user *mistakes*. >=20 > Of course to Microsoft's Outlook developers, those are crucial > questions. We aren't Outlook developers (not even you), so we don't > actually care. I think we do care about user psychology in deciding > whether a particular message is abusive, though. Actually, I do care because the desire is for consistent and persistent beha= vior across the MUA board. When dealing with subjective concepts such as Us= er Psychology, then its becomes much harder to address due to lack of persis= tency and consistency.=20 We are looking for generic, reproducible, verifiable automatic computer soft= ware logic, that removes the burden from the user, including operators, maki= ng the complex decision about what is good or bad. The exceptions are alway= s taken into account. Most of the time, you are going to depend on what the= backend does consistently and persistently for all user types because the b= ackend has to worry about a group of MUA types -- there is not just one type= of course, even if there is a monopoly, there are far too many MUAs. This i= ncludes the old school RFC-based MUAs. The current trend is to move users to= online MUAs, but that has always been a direction with the older methods st= ill viable. They are not going away.=20 -- Hector Santos http://www.santronics.com= From nobody Sun Mar 15 11:53:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924C71A1B69 for ; Sun, 15 Mar 2015 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793] 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 tMZayqn1W6RX for ; Sun, 15 Mar 2015 11:53:42 -0700 (PDT) Received: from wmail.tana.it (unknown [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719421A1B5F for ; Sun, 15 Mar 2015 11:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1426445619; bh=o7cyBpjLCYis7ynU3b7XLmHFp+dDl1fZgexBworgfrQ=; l=803; h=Date:From:To; b=iuPOwNbg9X9vc+A9ZHgOAlIy5FpJTOI4Zg5lGYMOjIOpK34XcdBp9q3tDjLI15zNE K1JEI6tEYVYe9t6l7R47IoMsRgdOdMFcj8kt427z7PfagXbKQcRd4Kp7SXgGcf8dJ4 wGOI/rvRZUxDrZNjB0CISo7/jA4oJRj4atlFNRrU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA; Sun, 15 Mar 2015 19:53:39 +0100 id 00000000005DC044.000000005505D533.00000860 Message-ID: <5505D533.6040201@tana.it> Date: Sun, 15 Mar 2015 19:53:39 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: dmarc-ietf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 15 Mar 2015 18:53:43 -0000 This seems to be a bug: OLD: dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] ; "URI" is imported from [URI]; commas (ASCII ; 0x2c) and exclamation points (ASCII 0x21) ; MUST be encoded; the numeric portion MUST fit ; within an unsigned 64-bit integer NEW: dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] ; "URI" is imported from [URI]; commas (ASCII ; 0x2c), exclamation points (ASCII 0x21), and ; semicolons (ASCII 0x3b) MUST be percent-encoded; ; the numeric portion MUST fit within an unsigned ; 64-bit integer Is it equivalent to have, say, rua=mailto:a@example.com%2cb@example.com and rua=mailtoa@example.com, mailto:b@example.com? Is the following meant to to be allowed? mailto:dmarc@ietf.org?subject=Formal%20specification%2c%20URI Ale From nobody Sun Mar 15 21:17:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3B21A000D for ; Sun, 15 Mar 2015 21:17:40 -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 GOjDw7biPWca for ; Sun, 15 Mar 2015 21:17:39 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBB51A001A for ; Sun, 15 Mar 2015 21:17:38 -0700 (PDT) Received: by wibg7 with SMTP id g7so27844159wib.1 for ; Sun, 15 Mar 2015 21:17:37 -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=lktXGn0EpCfyevPw+uMQ+z3IwMPjk9GwarS9uEWNtW4=; b=yGMjaJo939M9m6NFVap1MP0WXBaOfGVDrWt7i4BfG6P7b5rS/UgSXW4osHeZzEJDbP Q+yTsUQvK+J6q0U5dbNcpzvuVYuAW5JXVIXDS3gBsxS0iZPefSTnG2EK0E1QAdU+7jDo /wlFqFWJarVjBm8Gr0/B81F20iS5cKfW7Ccwyz5gGUolf3ibshsN2reYIu655CxQa5pk XJbzyCIv90BNJRiEMC6RtvU+GPXjTuLAPvimYxJzKMCsoMrz7RDD8UV8ReCWk1JbajAK W6IlbVfZVEMbZdsHCPzM3XlZnRp3ZMmvO7T023EMrxEFw+WRHGG/QEzUljRe6+GP60ZZ CXYA== MIME-Version: 1.0 X-Received: by 10.194.239.65 with SMTP id vq1mr115182168wjc.98.1426479457562; Sun, 15 Mar 2015 21:17:37 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Sun, 15 Mar 2015 21:17:37 -0700 (PDT) In-Reply-To: <5505D533.6040201@tana.it> References: <5505D533.6040201@tana.it> Date: Sun, 15 Mar 2015 21:17:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c1b8f058f926051160219f Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 04:17:40 -0000 --001a11c1b8f058f926051160219f Content-Type: text/plain; charset=UTF-8 On Sun, Mar 15, 2015 at 11:53 AM, Alessandro Vesely wrote: > This seems to be a bug: > > OLD: > dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] > ; "URI" is imported from [URI]; commas (ASCII > ; 0x2c) and exclamation points (ASCII 0x21) > ; MUST be encoded; the numeric portion MUST fit > ; within an unsigned 64-bit integer > NEW: > dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] > ; "URI" is imported from [URI]; commas (ASCII > ; 0x2c), exclamation points (ASCII 0x21), and > ; semicolons (ASCII 0x3b) MUST be percent-encoded; > ; the numeric portion MUST fit within an unsigned > ; 64-bit integer > > Is it equivalent to have, say, rua=mailto:a@example.com%2cb@example.com > and > rua=mailtoa@example.com, mailto:b@example.com? > > Is the following meant to to be allowed? > mailto:dmarc@ietf.org?subject=Formal%20specification%2c%20URI > Section 2.2 of RFC3986 lists semi-colon as a reserved character that has to be percent-encoded in these URLs. We don't need to repeat it here, I think. -MSK --001a11c1b8f058f926051160219f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 15, 2015 at 11:53 AM, Alessandro Vesely <vesely@= tana.it> wrote:
This seems to be a bug:

OLD:
=C2=A0 =C2=A0 =C2=A0dmarc-uri=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D URI [ "!&q= uot; 1*DIGIT [ "k" / "m" / "g" / "t"= ; ] ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; "URI" is imported from [URI]; commas (ASCII
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; 0x2c) and exclamation points (ASCII 0x21)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; MUST be encoded; the numeric portion MUST fit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; within an unsigned 64-bit integer
NEW:
=C2=A0 =C2=A0 =C2=A0dmarc-uri=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D URI [ "!&q= uot; 1*DIGIT [ "k" / "m" / "g" / "t"= ; ] ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; "URI" is imported from [URI]; commas (ASCII
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; 0x2c), exclamation points (ASCII 0x21), and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; semicolons (ASCII 0x3b) MUST be percent-encoded;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; the numeric portion MUST fit within an unsigned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; 64-bit integer

Is it equivalent to have, say, rua=3Dmailto:a@example.com%2cb@example.com = and
rua=3Dmailtoa@example.com, mailt= o:b@example.com?

Is the following meant to to be allowed?
=C2=A0 =C2=A0mailto:dmarc@ietf.org?su= bject=3DFormal%20specification%2c%20URI

Section 2.2 of RFC3986 lists semi-colon as a reserved character that has t= o be percent-encoded in these URLs.=C2=A0 We don't need to repeat it he= re, I think.

-MSK
--001a11c1b8f058f926051160219f-- From nobody Mon Mar 16 03:52:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4061A86F2 for ; Mon, 16 Mar 2015 03:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPsIEiZXXLF5 for ; Mon, 16 Mar 2015 03:52:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF4B1A86F3 for ; Mon, 16 Mar 2015 03:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1426503118; bh=drABgnsjdAvoEuxLVK7tZ+Ycmu4RY9hT5RzBpJOpeKc=; l=2786; h=Date:From:To:CC:References:In-Reply-To; b=Jn/VnBJnPmQ50K2ycLU2Y0qnOhgxoGlKSSYRilHI1f1Sa3sl/hr3dL2MzQh15LABR eMKUFi2cLwxrbEtmklPMhl/cGQR7AFRmD4/JwfFvBOOdr1ZzFo9Cv5sbOfSVidgsxN /YeOvUInAfJGVBIIW9bgbKunjDVRnnuWu7bFXT+Q= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA; Mon, 16 Mar 2015 11:51:58 +0100 id 00000000005DC066.000000005506B5CE.00003362 Message-ID: <5506B5CE.9080108@tana.it> Date: Mon, 16 Mar 2015 11:51:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5505D533.6040201@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 10:52:02 -0000 On Mon 16/Mar/2015 05:17:37 +0100 Murray S. Kucherawy wrote: > On Sun, Mar 15, 2015 at 11:53 AM, Alessandro Vesely wrote: > >> This seems to be a bug: >> >> OLD: >> dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] >> ; "URI" is imported from [URI]; commas (ASCII >> ; 0x2c) and exclamation points (ASCII 0x21) >> ; MUST be encoded; the numeric portion MUST fit >> ; within an unsigned 64-bit integer >> NEW: >> dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] >> ; "URI" is imported from [URI]; commas (ASCII >> ; 0x2c), exclamation points (ASCII 0x21), and >> ; semicolons (ASCII 0x3b) MUST be percent-encoded; >> ; the numeric portion MUST fit within an unsigned >> ; 64-bit integer >> >> Is it equivalent to have, say, rua=mailto:a@example.com%2cb@example.com >> and >> rua=mailtoa@example.com, mailto:b@example.com? >> >> Is the following meant to to be allowed? >> mailto:dmarc@ietf.org?subject=Formal%20specification%2c%20URI > > Section 2.2 of RFC3986 lists semi-colon as a reserved character that has to > be percent-encoded in these URLs. We don't need to repeat it here, I think. If the spec is going to be read by ignorants like me, it's better to repeat than to omit. RFC3986 has a very wide scope, and uses phrases like "may (or may not) be defined as delimiters". It says: If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed. Commma and exclamation (which are sub-delims like semicolon) are apparently used in dmarc-uri's rule. The preceding DMARC section says: DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM]. However, DKIM production rules don't seem to be formally imported. If they are imported, semicolon exclusion is implied by the definition: VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON Anyway, I'd add the "percent-" word, lest anyone tries ,... How about the other two questions? I didn't survey but a few DMARC records, but RFC6068 exemplifies the following: Also note that it is syntactically valid to specify both and an whose value is "to". That is, is equivalent to is equivalent to However, the latter form is NOT RECOMMENDED because different user agents handle this case differently. In particular, some existing clients ignore "to" s. Yahoo instead uses 1st level syntax: rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com; Ale From nobody Mon Mar 16 09:29:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D471A8897 for ; Mon, 16 Mar 2015 09:29:06 -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 xlcXHawYIIKW for ; Mon, 16 Mar 2015 09:29:05 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4431A1B2A for ; Mon, 16 Mar 2015 09:29:04 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 716B11C3841; Tue, 17 Mar 2015 01:29:03 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 48B96120EC9; Tue, 17 Mar 2015 01:29:03 +0900 (JST) From: "Stephen J. Turnbull" To: Alessandro Vesely In-Reply-To: <5506B5CE.9080108@tana.it> References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 17 Mar 2015 01:29:03 +0900 Message-ID: <87k2ygvrcg.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc-ietf , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 16:29:07 -0000 Alessandro Vesely writes: > If the spec is going to be read by ignorants like me, it's better > to repeat than to omit. -1. It's good that you read the spec, but that's not the primary purpose of the spec. It's a bad idea to repeat definitions clearly stated in another document (even in informal comments on the formal spec) when you refer to the original document; you're just asking for new ambiguity. From nobody Mon Mar 16 09:46:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9391A88C6 for ; Mon, 16 Mar 2015 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IR_PO3nEL2T for ; Mon, 16 Mar 2015 09:46:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id B06ED1A88C5 for ; Mon, 16 Mar 2015 09:46:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJO5FBQF3K00DBFX@mauve.mrochek.com> for dmarc@ietf.org; Mon, 16 Mar 2015 09:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1426524064; bh=mI51TkLziACHxdqEWqv2mB7EcNy5Oj/xjwotuQGSPX0=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=OKvp1OhAXtmeQhgCDDz/hVB8ZT7SqWfmpk9jXKjmFIYQDoIs7pFxtEC9K+hoHlYNp WOzmQygDap97K6ehNSJZoMogRAqXze1/IpSh9kSGUwo5f7piawbU+hxI4JWxCtqEew uAvd2JyAhdu6ROx9RVnbf/MB3uTHDRquKlfFqWC4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJ6KCZSXQ80000AQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 16 Mar 2015 09:41:01 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PJO5FABNXO0000AQ@mauve.mrochek.com> Date: Mon, 16 Mar 2015 09:37:18 -0700 (PDT) In-reply-to: "Your message dated Tue, 17 Mar 2015 01:29:03 +0900" <87k2ygvrcg.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> <87k2ygvrcg.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" Archived-At: Cc: dmarc-ietf , "Murray S. Kucherawy" , Alessandro Vesely Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 16:46:06 -0000 > Alessandro Vesely writes: > > If the spec is going to be read by ignorants like me, it's better > > to repeat than to omit. > -1. It's good that you read the spec, but that's not the primary > purpose of the spec. It's a bad idea to repeat definitions clearly > stated in another document (even in informal comments on the formal > spec) when you refer to the original document; you're just asking for > new ambiguity. +1. Repeating stuff like this is in the long term a surefire of silly states, where one repetition gets updated but not another. The "running code" that comes to mind is the MIME specification, which originally had a bunch of repeated and overlapping syntax definitions. In this case it only took one revision for it to get out of sync and cause confusion. Ned From nobody Mon Mar 16 12:22:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC51A8BAF for ; Mon, 16 Mar 2015 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 AurZkUif_zfr for ; Mon, 16 Mar 2015 12:22:33 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5363E1A8AFA for ; Mon, 16 Mar 2015 12:22:33 -0700 (PDT) Received: by wixw10 with SMTP id w10so35339502wix.0 for ; Mon, 16 Mar 2015 12:22:32 -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=+3ROQ2BjIfvhMauSi2ikuSOGYuxhyOPX9r15GkAM4co=; b=p7QUq/a2U054KLwOodhXE+njW6F10kuHIdov8gaFYIKKod8Zniujyb+xmAkqh88NLx yBfI4Bt4Xc6B7L/5a6us2UZyzmBstm9Ds+oPBratFZ9/5DbJumO8U/pciKR+DaPU+YfV JCMlR6l1qSRRs6FAGeGGUYgXulCe1diOpMzGn5zSz8eVEh0CBb4dRjdNiVmAFVyniqUX 4ipKN8RE97QF/12t0i1dgQYqArDmDFpvsjceUFZixg1g5qKtHIN5I0Rqs1f/o1uMDo0x +5M3z5uOOQHOCSdS5ZqF+6nL2w+AKLNlB56pqpt86y1D2MGOaVwjnW7dQgzBjtmPT4AI K56Q== MIME-Version: 1.0 X-Received: by 10.194.79.226 with SMTP id m2mr124393510wjx.60.1426533751976; Mon, 16 Mar 2015 12:22:31 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 16 Mar 2015 12:22:31 -0700 (PDT) In-Reply-To: <5506B5CE.9080108@tana.it> References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> Date: Mon, 16 Mar 2015 12:22:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=047d7bf0c5388bf98d05116cc580 Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 19:22:35 -0000 --047d7bf0c5388bf98d05116cc580 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 3:51 AM, Alessandro Vesely wrote: > > Section 2.2 of RFC3986 lists semi-colon as a reserved character that has > to > > be percent-encoded in these URLs. We don't need to repeat it here, I > think. > > If the spec is going to be read by ignorants like me, it's better to repeat > than to omit. RFC3986 has a very wide scope, and uses phrases like "may > (or > may not) be defined as delimiters". It says: > > If data for a URI component would conflict with a reserved > character's purpose as a delimiter, then the conflicting data must be > percent-encoded before the URI is formed. > Right, which is why things like semi-colon don't need to be percent-encoded; they're already special characters in the context of a URL. > Commma and exclamation (which are sub-delims like semicolon) are apparently > used in dmarc-uri's rule. The preceding DMARC section says: > > DMARC records follow the extensible "tag-value" syntax for DNS-based > key records defined in DKIM [DKIM]. > > However, DKIM production rules don't seem to be formally imported. If > they are > imported, semicolon exclusion is implied by the definition: > > VALCHAR = %x21-3A / %x3C-7E > ; EXCLAMATION to TILDE except SEMICOLON > They aren't formally imported, and I'm not sure that's necessary here. The ABNF we have should be comprehensive over DMARC tag-value sets. The prose you cited is merely meant to convey that they follow the same style. > How about the other two questions? I didn't survey but a few DMARC > records, > but RFC6068 exemplifies the following: > > Also note that it is syntactically valid to specify both and an > whose value is "to". That is, > > > > is equivalent to > > > > is equivalent to > > > > However, the latter form is NOT RECOMMENDED because different user > agents handle this case differently. In particular, some existing > clients ignore "to" s. > > Yahoo instead uses 1st level syntax: > > rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com; > Your question is "Are they equivalent?" I believe they are. Although it might be ideal to have a specification so tight that there's exactly one way to do something, in the end I don't think it's harmful to have two ways to say the same thing. It's more of a concern if there's to ways to interpret a single thing; that's when we arguably have something to fix. The goal in allowing a comma-separated list of URLs is that you might conceivably want to put an http and a mailto URL in there, in the "try A first, then try B" sense. We need to allow for that possibility. We also need to account for the possibility of a comma that is inside of a URL; those are the ones that need to be encoded. Outside of a URL, they're delimiters. Unless I'm missing something, the ABNF for DMARC allows all three of the cited examples, as well as Yahoo's use, and all four of them mean the same thing. That doesn't strike me as a bug. -MSK --047d7bf0c5388bf98d05116cc580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 16, 2015 at 3:51 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> Section 2.2 of RFC3986 lists semi-colon as a reserved characte= r that has to
> be percent-encoded in these URLs.=C2=A0 We don't need to repeat it= here, I think.

If the spec is going to be read by ignorants like me, it's = better to repeat
than to omit.=C2=A0 RFC3986 has a very wide scope, and uses phrases like &q= uot;may (or
may not) be defined as delimiters".=C2=A0 It says:

=C2=A0 =C2=A0If data for a URI component would conflict with a reserved
=C2=A0 =C2=A0character's purpose as a delimiter, then the conflicting d= ata must be
=C2=A0 =C2=A0percent-encoded before the URI is formed.

Right, which is why things like semi-colon don't need t= o be percent-encoded; they're already special characters in the context= of a URL.
=C2=A0
Commma and exclamation (which are sub-delims like semicolon) are apparently=
used in dmarc-uri's rule.=C2=A0 The preceding DMARC section says:

=C2=A0 =C2=A0DMARC records follow the extensible "tag-value" synt= ax for DNS-based
=C2=A0 =C2=A0key records defined in DKIM [DKIM].

However, DKIM production rules don't seem to be formally imported.=C2= =A0 If they are
imported, semicolon exclusion is implied by the definition:

=C2=A0 =C2=A0VALCHAR=C2=A0 =C2=A0=3D=C2=A0 %x21-3A / %x3C-7E
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0; EXCLAMATION to TILDE except SEMICOLON

<= div>They aren't formally imported, and I'm not sure that's nece= ssary here.=C2=A0 The ABNF we have should be comprehensive over DMARC tag-v= alue sets.=C2=A0 The prose you cited is merely meant to convey that they fo= llow the same style.
=C2=A0
How about the other two questions?=C2=A0 I didn't survey but a few DMAR= C records,
but RFC6068 exemplifies the following:

=C2=A0 =C2=A0Also note that it is syntactically valid to specify both <t= o> and an
=C2=A0 =C2=A0<hfname> whose value is "to".=C2=A0 That is,
=C2=A0 =C2=A0<mailto:addr1@an.exampl= e,addr2@an.example>

=C2=A0 =C2=A0is equivalent to

=C2=A0 =C2=A0<mailto:?to=3Daddr1@an.example,addr2@an.example>

=C2=A0 =C2=A0is equivalent to

=C2=A0 =C2=A0<mailto:addr1@an.exampl= e?to=3Daddr2@an.example>

=C2=A0 =C2=A0However, the latter form is NOT RECOMMENDED because different = user
=C2=A0 =C2=A0agents handle this case differently.=C2=A0 In particular, some= existing
=C2=A0 =C2=A0clients ignore "to" <hfvalue>s.

Yahoo instead uses 1st level syntax:

=C2=A0 =C2=A0rua=3Dmailto:= dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com;

Your= question is "Are they equivalent?"=C2=A0 I believe they are.=C2= =A0 Although it might be ideal to have a specification so tight that there&= #39;s exactly one way to do something, in the end I don't think it'= s harmful to have two ways to say the same thing.=C2=A0 It's more of a = concern if there's to ways to interpret a single thing; that's when= we arguably have something to fix.

The goal in allowing = a comma-separated list of URLs is that you might conceivably want to put an= http and a mailto URL in there, in the "try A first, then try B"= sense.=C2=A0 We need to allow for that possibility.=C2=A0 We also need to = account for the possibility of a comma that is inside of a URL; those are t= he ones that need to be encoded.=C2=A0 Outside of a URL, they're delimi= ters.

Unless I'm missing something, the ABNF for DMAR= C allows all three of the cited examples, as well as Yahoo's use, and a= ll four of them mean the same thing.=C2=A0 That doesn't strike me as a = bug.

-MSK
--047d7bf0c5388bf98d05116cc580-- From nobody Mon Mar 16 12:43:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B298F1A8F3E for ; Mon, 16 Mar 2015 12:43:46 -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 4GfPWkIme7lj for ; Mon, 16 Mar 2015 12:43:45 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A52A1A8BB1 for ; Mon, 16 Mar 2015 12:43:45 -0700 (PDT) Received: by weop45 with SMTP id p45so20587690weo.0 for ; Mon, 16 Mar 2015 12:43: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=rHSFU8O+Eh7waJ17H1rULNYTJRxKlXpubT1jmneGQdA=; b=NuaZFTSLthUgR5sOlj8504pnhaq63UrOeeopnacdPxlWjd6MdJppU8kLIc00+CUAcF 77tsO/sW/CYFPzYgbW8B4s9hsugGQvJ4mTYZydQ62LwgDny3HOwOQCDps+U8Xsd7xoh6 KAWzTqJhWIT2vI4RIWyt8uzcWu6x5ANNTiKoJtdQPpLLaVmRVMQXqCSJiooGg9Kilp6H UcqujWdOihEabe49gwakh11MfeQ52qKuHhnCD96D/ccAd0xmgIUs8hNsaFSuYSH10ScD 7hx3SfOtHgksC3Pt0Dy2dkhaKBzf5ak1qRFIXO9+J0Bqz3xsUD89dRvySFj7R1S5fLoX 1Lpg== MIME-Version: 1.0 X-Received: by 10.180.74.202 with SMTP id w10mr97767025wiv.0.1426535024040; Mon, 16 Mar 2015 12:43:44 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 16 Mar 2015 12:43:43 -0700 (PDT) In-Reply-To: References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> Date: Mon, 16 Mar 2015 12:43:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d043d650b5e242205116d116e Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 19:43:46 -0000 --f46d043d650b5e242205116d116e Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 12:22 PM, Murray S. Kucherawy wrote: > Your question is "Are they equivalent?" I believe they are. Although it > might be ideal to have a specification so tight that there's exactly one > way to do something, in the end I don't think it's harmful to have two ways > to say the same thing. It's more of a concern if there's to ways to > interpret a single thing; that's when we arguably have something to fix. > Sigh. s/to ways/two ways/ -MSK --f46d043d650b5e242205116d116e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 16, 2015 at 12:22 PM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
Your question is "Are they equivalent?"=C2= =A0 I believe they are.=C2=A0 Although it might be ideal to have a specific= ation so tight that there's exactly one way to do something, in the end= I don't think it's harmful to have two ways to say the same thing.= =C2=A0 It's more of a concern if there's to ways to interpret a sin= gle thing; that's when we arguably have something to fix.

Sigh.=C2=A0 s/to ways/two ways/

<= div>-MSK
--f46d043d650b5e242205116d116e-- From nobody Mon Mar 16 12:57:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEE91A905E for ; Mon, 16 Mar 2015 12:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di7mAq48ckzy for ; Mon, 16 Mar 2015 12:57:15 -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 558331A905A for ; Mon, 16 Mar 2015 12:57:15 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id t2GJv6ZJ081867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 16 Mar 2015 12:57:11 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com t2GJv6ZJ081867 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1426535831; bh=yry/wmdus/++dbq9J/bj19qZ1V1tqw+BlAXu2cxI6Ek=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=A+eDD0jOx7wkTp2BI5GENm8zsHzaXfdHQ3dY6Ntdv+sVt64I1a4+p6FOSPxu+4I6o VHnicKSmzjHh081ufuEaOsP6ilGQcezue+OmL+MIYcONRDIi24ibXXjYDcfA8JAy2t 3WafwlI0wxcsRWwcoXJ2654YjwPYsLkq5+G2wuf4= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <55073593.3070503@crash.com> Date: Mon, 16 Mar 2015 12:57:07 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Mon, 16 Mar 2015 12:57:11 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 19:57:16 -0000 On 03/16/2015 12:22 PM, Murray S. Kucherawy wrote: > [...] > > The goal in allowing a comma-separated list of URLs is that you might > conceivably want to put an http and a mailto URL in there, in the "try > A first, then try B" sense. We need to allow for that possibility. > We also need to account for the possibility of a comma that is inside > of a URL; those are the ones that need to be encoded. Outside of a > URL, they're delimiters. Just to be explicit, it also allows for multiple mailto: URIs - something that is seen "in the wild," though perhaps not if one looks up a half dozen DMARC records at random. But at the end of January multiple mailto: URIs could be seen in ten of the Alexa Top 100 domains, in both "rua" and "ruf" tags. --S. From nobody Mon Mar 16 12:59:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6691A905C for ; Mon, 16 Mar 2015 12:59: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 VZK_QBZ6eqlo for ; Mon, 16 Mar 2015 12:59:50 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778081A905A for ; Mon, 16 Mar 2015 12:59:50 -0700 (PDT) Received: by weop45 with SMTP id p45so20847291weo.0 for ; Mon, 16 Mar 2015 12:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7nDjo5qQsu+W9nkxjCRIs8of6E6IT9ZGZ0luuyGM6hc=; b=p2Rx9fgfrBHIvvMbsjpWDJ49b+9wdtCJlWCF0tmUyV+Pz6T6ccHLz+V4mPHYh0MOYA ArRAIBL0lK6LYtKdeOLdESgtFyDZ5mCgnD5lRBPY0lz2sp+A4iKApwJ7tCJXw2XEKqaH hUdKXyeM+tTcVMKOG5nEdPJUFrZr+QN73kHDtmtYVptrJLIgiTs6PdTuzm0ycK1rWF1v rDm0dbxD8HcHZAZx+ZEaThCugNKRczGovqQ44jJJzFnq84zXe7bM/NGsdisn1ghc3v+u IiNFI2SuAqV63/eu6xHU94HSjGbjP5B4v3HQs4kq/BnUJlVODj8Ny2iNVNzCTXuKw6sY wO8A== MIME-Version: 1.0 X-Received: by 10.180.79.65 with SMTP id h1mr125102868wix.59.1426535989266; Mon, 16 Mar 2015 12:59:49 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 16 Mar 2015 12:59:49 -0700 (PDT) In-Reply-To: <55073593.3070503@crash.com> References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> <55073593.3070503@crash.com> Date: Mon, 16 Mar 2015 12:59:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Steven M Jones Content-Type: multipart/alternative; boundary=14dae9cc9534e64ea605116d4a29 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Mar 2015 19:59:52 -0000 --14dae9cc9534e64ea605116d4a29 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 12:57 PM, Steven M Jones wrote: > Just to be explicit, it also allows for multiple mailto: URIs - > something that is seen "in the wild," though perhaps not if one looks up > a half dozen DMARC records at random. But at the end of January multiple > mailto: URIs could be seen in ten of the Alexa Top 100 domains, in both > "rua" and "ruf" tags. > Right, and there might be some operational reason why you want to send one message to A and B, versus a message to A and then a message to B. (Fewer calls to fork()/exec(), perhaps.) -MSK --14dae9cc9534e64ea605116d4a29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 16, 2015 at 12:57 PM, Steven M Jones <smj@crash.c= om> wrote:
Just to be explicit, it also allows f= or multiple mailto: URIs -
something that is seen "in the wild," though perhaps not if one l= ooks up
a half dozen DMARC records at random. But at the end of January multiple mailto: URIs could be seen in ten of the Alexa Top 100 domains, in both
"rua" and "ruf" tags.
= =C2=A0

Right, and there might be some opera= tional reason why you want to send one message to A and B, versus a message= to A and then a message to B.=C2=A0 (Fewer calls to fork()/exec(), perhaps= .)

-MSK
--14dae9cc9534e64ea605116d4a29-- From nobody Tue Mar 17 08:23:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A97A1A1F04 for ; Tue, 17 Mar 2015 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTTP_EXCESSIVE_ESCAPES=1.572, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_7vb3mbjZuj for ; Tue, 17 Mar 2015 08:23:37 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C851A1C06 for ; Tue, 17 Mar 2015 08:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1426605813; bh=+R2qi8G85OBmXXfNHIAYk+GcNKH21dIWA62xTJdRaMU=; l=5311; h=Date:From:To:CC:References:In-Reply-To; b=J0TpT6Qo3FqLe1fBIspiwlrxLCHHxzriCNhgPARUyS05D3bgZhYFMTG8KFXRSt8jn sayKRHdJdpsU0MPl1uF98JyMozW0aoMEma4anCrzMUfAVPLpUrjxCZ6HQiOgBvlQJo vm7kcxDvux+mfJx/sKk/htBo84QR8v4CLlqZMtZg= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA; Tue, 17 Mar 2015 16:23:33 +0100 id 00000000005DC050.00000000550846F5.0000202C Message-ID: <550846F5.5030004@tana.it> Date: Tue, 17 Mar 2015 16:23:33 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 15:23:39 -0000 On Mon 16/Mar/2015 20:22:31 +0100 Murray S. Kucherawy wrote: > On Mon, Mar 16, 2015 at 3:51 AM, Alessandro Vesely wrote: > >>> Section 2.2 of RFC3986 lists semi-colon as a reserved character that has to >>> be percent-encoded in these URLs. We don't need to repeat it here, I think. >> >> If the spec is going to be read by ignorants like me, it's better to repeat >> than to omit. RFC3986 has a very wide scope, and uses phrases like "may >> (or may not) be defined as delimiters". It says: >> >> If data for a URI component would conflict with a reserved >> character's purpose as a delimiter, then the conflicting data must be >> percent-encoded before the URI is formed. > > Right, which is why things like semi-colon don't need to be > percent-encoded; they're already special characters in the context of a URL. So are comma and exclamation. What puzzles me is that DMARC spec treats them differently while RFC3896 does not. Comma and semicolon seem to behave the same; e.g.: http://www.tana.it/comma,comma.txt http://www.tana.it/comma%2ccomma.txt http://www.tana.it/comma%25%32%63comma.txt http://www.tana.it/semicolon;semicolon.txt http://www.tana.it/semicolon%3bsemicolon.txt http://www.tana.it/semicolon%25%33%62semicolon.txt >> Commma and exclamation (which are sub-delims like semicolon) are apparently >> used in dmarc-uri's rule. The preceding DMARC section says: >> >> DMARC records follow the extensible "tag-value" syntax for DNS-based >> key records defined in DKIM [DKIM]. >> >> However, DKIM production rules don't seem to be formally imported. If >> they are >> imported, semicolon exclusion is implied by the definition: >> >> VALCHAR = %x21-3A / %x3C-7E >> ; EXCLAMATION to TILDE except SEMICOLON > > They aren't formally imported, and I'm not sure that's necessary here. The > ABNF we have should be comprehensive over DMARC tag-value sets. The prose > you cited is merely meant to convey that they follow the same style. Right. The question is if implementations can reuse DKIM parsers. >> How about the other two questions? I didn't survey but a few DMARC >> records, but RFC6068 exemplifies the following: >> >> Also note that it is syntactically valid to specify both and an >> whose value is "to". That is, >> >> >> >> is equivalent to >> >> >> >> is equivalent to >> >> >> >> However, the latter form is NOT RECOMMENDED because different user >> agents handle this case differently. In particular, some existing >> clients ignore "to" s. >> >> Yahoo instead uses 1st level syntax: >> >> rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com; > > Your question is "Are they equivalent?" I believe they are. Although it > might be ideal to have a specification so tight that there's exactly one > way to do something, in the end I don't think it's harmful to have two ways > to say the same thing. It's more of a concern if there's to ways to > interpret a single thing; that's when we arguably have something to fix. I tried the "NOT RECOMMENDED" syntax quoted above. Dmarcian[1] doesn't raise a brow, and RFC3896-compliant uriparser[2] ingests it smoothly. However, although I sent a test message to a gmail account, I received no report. I guess Google's implementation doesn't deploy a proper URI parser, but just looks for "mailto:" followed by a plain path consisting of a single[3] addr-spec (as defined in RFC6068, i.e. w/o comments) with no query nor fragment --that's what I'd do myself, but I find no arguments in the spec that help proving that that record is bad. [1] https://dmarcian.com/dmarc-inspector/torreinpietra.it [2] http://uriparser.sourceforge.net/doc/html/ [3] haven't yet tried two %2c-separated addr-specs. > The goal in allowing a comma-separated list of URLs is that you might > conceivably want to put an http and a mailto URL in there, in the "try A > first, then try B" sense. We need to allow for that possibility. We also > need to account for the possibility of a comma that is inside of a URL; > those are the ones that need to be encoded. Outside of a URL, they're > delimiters. The spec says a report "is normally sent to each". How can a publisher express that two URIs are meant to be either-or alternatives to each other? > Unless I'm missing something, the ABNF for DMARC allows all three of the > cited examples, as well as Yahoo's use, and all four of them mean the same > thing. That doesn't strike me as a bug. Recall that it took years and an RFC revision to have mailto: URIs treated with reasonable uniformity by web browsers. Here we are specifying an entirely new kind of client, which avails of its specific URI-transmission protocol. IMHO, if we want %2c to be interpreted as addr-spec separator or otherwise, we ought to spell it loud and clear. It may also be worth to require domain in addr-spec to be A-label, as that simplifies verification and improves dn_ compression. Such idea apparently conflicts with the example at the end of Section 6.3 of RFC6068, where the IDN is percent-encoded instead. Ale From nobody Wed Mar 18 13:08:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96BE1A1B92 for ; Wed, 18 Mar 2015 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 S7_XgcJpXEXB for ; Wed, 18 Mar 2015 13:08:29 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399651A00FA for ; Wed, 18 Mar 2015 13:08:29 -0700 (PDT) Received: by wibg7 with SMTP id g7so99761980wib.1 for ; Wed, 18 Mar 2015 13:08: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 :content-type; bh=ojYNpaa/EWVEmFxWSKnOS+N/gPlgo3y7E8TzwYFbJq0=; b=kmqPuejjtYVhNjWvmr2PcQGKlyfnvgtHnMQIv4TAGYdr3DaPo/fEnhYA+kDvJmIWGN SF+698ZCu/KPD3qxIi8qXpc1DthHy0NpeSYsOac1mWWQaq+NOcGsaH8rPRdFdVkN1FKW SCG49pXcavYBhlWfM4R17c+hFzGlh7RpXhqOeUzO3XuGn2XV923+A2760Uc0Uk/oUQEZ +zW9Yb5V3GZUzLCMTczNydWj1zaRicYlaCb+NnNWl3orms/amF0Xs9K3lY6eLujt/jEr 5FuevHACPWEbx/h3eytqC/leXCNgd1k96G5X3R7XeCK4ROCwJ2xSbKix2hhX5uQNRqgS RIqw== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr142457117wjc.111.1426709307985; Wed, 18 Mar 2015 13:08:27 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Wed, 18 Mar 2015 13:08:27 -0700 (PDT) In-Reply-To: <20150318200459.23F9B18020A@rfc-editor.org> References: <20150318200459.23F9B18020A@rfc-editor.org> Date: Wed, 18 Mar 2015 13:08:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7bacb11e802235051195a581 Archived-At: Subject: [dmarc-ietf] Fwd: RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (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: Wed, 18 Mar 2015 20:08:32 -0000 --047d7bacb11e802235051195a581 Content-Type: text/plain; charset=UTF-8 FYI: ---------- Forwarded message ---------- From: Date: Wed, Mar 18, 2015 at 1:04 PM Subject: RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7489 Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Author: M. Kucherawy, Ed., E. Zwicky, Ed. Status: Informational Stream: Independent Date: March 2015 Mailbox: superuser@gmail.com, zwicky@yahoo-inc.com Pages: 73 Characters: 162707 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-kucherawy-dmarc-base-12.txt URL: https://www.rfc-editor.org/info/rfc7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --047d7bacb11e802235051195a581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI:

---------- For= warded message ----------
From: <rfc-editor@rf= c-editor.org>
Date: Wed, Mar 18, 2015 at 1:04 PM
Subjec= t: RFC 7489 on Domain-based Message Authentication, Reporting, and Conforma= nce (DMARC)
To: ietf-announce@= ietf.org, rfc-dist@rfc-edito= r.org
Cc: drafts-updat= e-ref@iana.org, rfc-editor= @rfc-editor.org


A new Request for Comments is now available = in online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7489

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Domain-based Message= Authentication, Reporting, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Confo= rmance (DMARC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0M. Kucherawy, Ed., =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E. Zw= icky, Ed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Informational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0Independent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 superuser@gmail.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 zwicky@yahoo-inc.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 73
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 162707
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-kucherawy-dmarc-bas= e-12.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.rfc-edit= or.org/info/rfc7489

Domain-based Message Authentication, Reporting, and Conformance
(DMARC) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable
and authenticated domain identifiers with messages, communicate
policies about messages that use those identifiers, and report about
mail using those identifiers.=C2=A0 These abilities have several benefits:<= br> Receivers can provide feedback to Domain Owners about the use of
their domains; this feedback can provide valuable insight about the
management of internal operations and the presence of external domain
name abuse.

DMARC does not produce or encourage elevated delivery privilege of
authenticated email.=C2=A0 DMARC is a mechanism for policy distribution
that enables increasingly strict handling of messages that fail
authentication checks, ranging from no action, through altered
delivery, up to message rejection.


INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinfo/ietf-announce
=C2=A0 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist=

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



--047d7bacb11e802235051195a581-- From nobody Wed Mar 18 13:20:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A340F1A889F for ; Wed, 18 Mar 2015 13:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw7Tb8C0iOso for ; Wed, 18 Mar 2015 13:20:02 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id CB4191A889C for ; Wed, 18 Mar 2015 13:20:01 -0700 (PDT) Received: from [192.168.1.10] (208-104-146-37.brvd.dsl.dyn.comporium.net [208.104.146.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id B55D5CB46; Wed, 18 Mar 2015 16:19:47 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DABB0142-E041-459E-951B-AC49D67908AC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Draegen In-Reply-To: Date: Wed, 18 Mar 2015 16:19:59 -0400 Message-Id: References: <20150318200459.23F9B18020A@rfc-editor.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (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: Wed, 18 Mar 2015 20:20:04 -0000 --Apple-Mail=_DABB0142-E041-459E-951B-AC49D67908AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Murray & Elizabeth, thanks for wrestling this through the process. = The Working Group can now adopt this as input. /goes off to figure out which buttons need to be pushed =3D- Tim > On Mar 18, 2015, at 4:08 PM, Murray S. Kucherawy = wrote: >=20 > FYI: >=20 > ---------- Forwarded message ---------- > From: > > Date: Wed, Mar 18, 2015 at 1:04 PM > Subject: RFC 7489 on Domain-based Message Authentication, Reporting, = and Conformance (DMARC) > To: ietf-announce@ietf.org , = rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org , = rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7489 >=20 > Title: Domain-based Message Authentication, Reporting, = and > Conformance (DMARC) > Author: M. Kucherawy, Ed., > E. Zwicky, Ed. > Status: Informational > Stream: Independent > Date: March 2015 > Mailbox: superuser@gmail.com , > zwicky@yahoo-inc.com > Pages: 73 > Characters: 162707 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-kucherawy-dmarc-base-12.txt >=20 > URL: https://www.rfc-editor.org/info/rfc7489 = >=20 > Domain-based Message Authentication, Reporting, and Conformance > (DMARC) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. >=20 > Originators of Internet Mail need to be able to associate reliable > and authenticated domain identifiers with messages, communicate > policies about messages that use those identifiers, and report about > mail using those identifiers. These abilities have several benefits: > Receivers can provide feedback to Domain Owners about the use of > their domains; this feedback can provide valuable insight about the > management of internal operations and the presence of external domain > name abuse. >=20 > DMARC does not produce or encourage elevated delivery privilege of > authenticated email. DMARC is a mechanism for policy distribution > that enables increasingly strict handling of messages that fail > authentication checks, ranging from no action, through altered > delivery, up to message rejection. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet = community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce = > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist = >=20 > For searching the RFC series, see https://www.rfc-editor.org/search = > For downloading RFCs, see https://www.rfc-editor.org/rfc.html = >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org = . Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_DABB0142-E041-459E-951B-AC49D67908AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Murray & Elizabeth, thanks for = wrestling this through the process.  The Working Group can now = adopt this as input.

/goes off to figure out which buttons need to be = pushed
=3D- Tim


On Mar 18, 2015, at 4:08 PM, Murray S. = Kucherawy <superuser@gmail.com> wrote:

FYI:

---------- Forwarded message ----------
From: <rfc-editor@rfc-editor.org>
Date: = Wed, Mar 18, 2015 at 1:04 PM
Subject: RFC 7489 on = Domain-based Message Authentication, Reporting, and Conformance = (DMARC)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org


A new Request for Comments is now available in online RFC = libraries.


        RFC 7489

        Title:      Domain-based = Message Authentication, Reporting, and
                    = Conformance (DMARC)
        Author:     M. Kucherawy, = Ed.,
                    E. = Zwicky, Ed.
        Status:     Informational
        Stream:     Independent
        Date:       March = 2015
        Mailbox:    superuser@gmail.com,                     zwicky@yahoo-inc.com
        Pages:      73
        Characters: 162707
        Updates/Obsoletes/SeeAlso:  =  None

        I-D Tag:    = draft-kucherawy-dmarc-base-12.txt

        URL:        https://www.rfc-editor.org/info/rfc7489

Domain-based Message Authentication, Reporting, and Conformance
(DMARC) is a scalable mechanism by which a mail-originating
= organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable
and authenticated domain identifiers with messages, communicate
policies about messages that use those identifiers, and report about
mail using those identifiers.  These abilities have several = benefits:
Receivers can provide feedback to Domain Owners about the use of
their domains; this feedback can provide valuable insight about the
management of internal operations and the presence of external domain
name abuse.

DMARC does not produce or encourage elevated delivery privilege of
authenticated email.  DMARC is a mechanism for policy = distribution
that enables increasingly strict handling of messages that fail
authentication checks, ranging from no action, through altered
delivery, up to message rejection.


INFORMATIONAL: This memo provides information for the Internet = community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



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

= --Apple-Mail=_DABB0142-E041-459E-951B-AC49D67908AC-- From nobody Wed Mar 18 13:30:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8CD1A1B67 for ; Wed, 18 Mar 2015 13:30:41 -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 1qwgO33scx1R for ; Wed, 18 Mar 2015 13:30:39 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C290C1A8ACB for ; Wed, 18 Mar 2015 13:30:31 -0700 (PDT) Received: by wgdm6 with SMTP id m6so45069578wgd.2 for ; Wed, 18 Mar 2015 13:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=emmS1KxDZS/Vx+4QvC6k51qKdEBuEhh9RyNkgL9zOoc=; b=X5UUpI+D9L8bPyKcbYZxMWJm/COml2W5XYTj6hH0aL+khgVzYRt6Pbt2K0dyQfCf0R 8bZIg9XebzGHrWKwGuKXWyVoDLmL/SL1bXV481s0yjQDMJwBLZdVVRDYm9q/hBal79QI qHSuiDCJFGpE4XoKnscbn6ONtGcpS8yq+a9/cM4Na/rzMO0bzH3UeMzarUKVF6OhJb5N TGR9qsKe4qZpPTZK3+nME5adbb6lIGVmsYQHP3hPT2IOtsu0uatMJbTvigDAKLwqE9sK U0ild33XEVKw0FMQnxm/ERSfl3/hpdBmI7flugVGGGLquyDTGJT1KWOsJY5vP6eu3pXf cIsg== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr10066061wic.94.1426710630496; Wed, 18 Mar 2015 13:30:30 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Wed, 18 Mar 2015 13:30:30 -0700 (PDT) In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> Date: Wed, 18 Mar 2015 13:30:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=001a11c381ce540321051195f48b Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (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: Wed, 18 Mar 2015 20:30:41 -0000 --001a11c381ce540321051195f48b Content-Type: text/plain; charset=UTF-8 On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen wrote: > Hi Murray & Elizabeth, thanks for wrestling this through the process. The > Working Group can now adopt this as input. > > /goes off to figure out which buttons need to be pushed > =- Tim > > I have to resubmit it as "draft-ietf-dmarc-base" and then you guys have to approve it in, assuming you still want me to act as editor. Did you want to do that right away or wait until the earlier milestones have been met? -MSK --001a11c381ce540321051195f48b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen <tim@eudaemon= .net> wrote:
Hi Murray & Elizabeth, thanks for wrestling this through the proc= ess.=C2=A0 The Working Group can now adopt this as input.

/goes off to figure out which buttons need to be pushed
= =3D- Tim


I have to resubmit= it as "draft-ietf-dmarc-base" and then you guys have to approve = it in, assuming you still want me to act as editor.=C2=A0 Did you want to d= o that right away or wait until the earlier milestones have been met?
-MSK
=C2=A0
--001a11c381ce540321051195f48b-- From nobody Wed Mar 18 14:01:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1B1A88D6 for ; Wed, 18 Mar 2015 14:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzcJqISiKkEW for ; Wed, 18 Mar 2015 14:01:17 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 69A221A911E for ; Wed, 18 Mar 2015 14:01:17 -0700 (PDT) Received: from [192.168.1.10] (208-104-146-37.brvd.dsl.dyn.comporium.net [208.104.146.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id A74EFCB46; Wed, 18 Mar 2015 17:01:03 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC8A3672-9235-447D-B493-E9451E78545A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Draegen In-Reply-To: Date: Wed, 18 Mar 2015 17:01:15 -0400 Message-Id: <745E88D3-62C0-4ED8-9302-E6691F38C8F3@eudaemon.net> References: <20150318200459.23F9B18020A@rfc-editor.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (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: Wed, 18 Mar 2015 21:01:19 -0000 --Apple-Mail=_DC8A3672-9235-447D-B493-E9451E78545A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 18, 2015, at 4:30 PM, Murray S. Kucherawy = wrote: >=20 > On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen > wrote: > Hi Murray & Elizabeth, thanks for wrestling this through the process. = The Working Group can now adopt this as input. >=20 > /goes off to figure out which buttons need to be pushed > =3D- Tim >=20 >=20 > I have to resubmit it as "draft-ietf-dmarc-base" and then you guys = have to approve it in, assuming you still want me to act as editor. Did = you want to do that right away or wait until the earlier milestones have = been met? You might as well do it right away. The earlier milestones are not = coupled to the DMARC base draft. =3D- Tim --Apple-Mail=_DC8A3672-9235-447D-B493-E9451E78545A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Mar 18, 2015, at 4:30 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen = <tim@eudaemon.net> wrote:
Hi Murray = & Elizabeth, thanks for wrestling this through the process.  = The Working Group can now adopt this as input.

/goes off to figure out which buttons = need to be pushed
=3D- Tim


I have to resubmit it as "draft-ietf-dmarc-base" and then you = guys have to approve it in, assuming you still want me to act as = editor.  Did you want to do that right away or wait until the = earlier milestones have been met?

You might as well do it right away.  The = earlier milestones are not coupled to the DMARC base draft.

=3D- Tim

= --Apple-Mail=_DC8A3672-9235-447D-B493-E9451E78545A-- From nobody Wed Mar 18 14:43:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689041A88F7 for ; Wed, 18 Mar 2015 14:43:35 -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 pzcW8uNFSWnn for ; Wed, 18 Mar 2015 14:43:33 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE3B1A88E4 for ; Wed, 18 Mar 2015 14:43:32 -0700 (PDT) Received: by wixw10 with SMTP id w10so51733879wix.0 for ; Wed, 18 Mar 2015 14:43:31 -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=zFuViJ1Xl453eajRf1q3k7PSc4Nj36OQqzNdFjnfFDY=; b=bPoIlcIUBTYjpGFOK8MvEmEorc4wLFN3x8Q7j+5+Fd5Lvne0kqr8f93sKI90f80Dap Lhb7TSvjqjmfq5Z/iap4wtlNDsaeTqjIE1TpthpiZsG5OseZwf3vVZ+9K4ePZ2yOIEDB WCcy6sa6YN3+WX8w0czHy3FzS2ISYb80d++F1Vu9PeJmmbLnusD2TttIjczT4EY6jeu1 6PDayK/TJdNliFWLMHUZeNCf4nToWI6ZMKtPBAYMm/ioUOUue4qXzE8jOjKWszu1Kqhl JuXa6ZWFwTSnNajMGt0j5wEpXOg8eLJUHwiDaxzjivyklrpG3opxL7dtLgTtJPgZyeaX Wpcg== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr10920002wix.52.1426715011389; Wed, 18 Mar 2015 14:43:31 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Wed, 18 Mar 2015 14:43:31 -0700 (PDT) In-Reply-To: <550846F5.5030004@tana.it> References: <5505D533.6040201@tana.it> <5506B5CE.9080108@tana.it> <550846F5.5030004@tana.it> Date: Wed, 18 Mar 2015 14:43:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d044289e8732093051196f9a5 Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] Formal specification, URI X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Mar 2015 21:43:35 -0000 --f46d044289e8732093051196f9a5 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 8:23 AM, Alessandro Vesely wrote: > > Right, which is why things like semi-colon don't need to be > > percent-encoded; they're already special characters in the context of a > URL. > > So are comma and exclamation. What puzzles me is that DMARC spec treats > them > differently while RFC3896 does not. Comma and semicolon seem to behave the > same; e.g.: > Ah, that's true. I was looking specifically at one and not all three. At this point, since RFC7489 has just been published, I suggest you choose (perhaps with direction from the co-chairs) how to record this discrepancy for handling when the base draft gets updated. You could open an erratum report, or you could add it to the WG's tracker, or maybe they have another suggestion. > > They aren't formally imported, and I'm not sure that's necessary here. > The > > ABNF we have should be comprehensive over DMARC tag-value sets. The > prose > > you cited is merely meant to convey that they follow the same style. > > Right. The question is if implementations can reuse DKIM parsers. > Without studying the ABNF again, I believe so. DKIM parsers separate tag-value entities at unencoded semicolons, after which the tag name and tag value are separated at unencoded equal signs. DMARC records are the same up to that point, and it's below there for "ruf" and "rua" in the DMARC case that things get interesting. Just like in the case of "b=" for DKIM, those two have special rules for value interpretation: make up a list of URIs using an unencoded comma as the separator. > > Your question is "Are they equivalent?" I believe they are. Although it > > might be ideal to have a specification so tight that there's exactly one > > way to do something, in the end I don't think it's harmful to have two > ways > > to say the same thing. It's more of a concern if there's to ways to > > interpret a single thing; that's when we arguably have something to fix. > > I tried the "NOT RECOMMENDED" syntax quoted above. Dmarcian[1] doesn't > raise a > brow, and RFC3896-compliant uriparser[2] ingests it smoothly. However, > although I sent a test message to a gmail account, I received no report. I > guess Google's implementation doesn't deploy a proper URI parser, but just > looks for "mailto:" followed by a plain path consisting of a single[3] > addr-spec (as defined in RFC6068, i.e. w/o comments) with no query nor > fragment > --that's what I'd do myself, but I find no arguments in the spec that help > proving that that record is bad. > I think we've wandered into implementation comparisons rather than getting the ABNF right in the specification. Or maybe a better way to say that is: I don't think fixing the discrepancy you've raised would resolve the disparity you're observing. > The spec says a report "is normally sent to each". How can a publisher > express > that two URIs are meant to be either-or alternatives to each other? > Is that a capability you require? I don't think that's a use case I've ever encountered. > It may also be worth to require domain in addr-spec to be A-label, as that > simplifies verification and improves dn_ compression. Such idea apparently > conflicts with the example at the end of Section 6.3 of RFC6068, where the > IDN > is percent-encoded instead. > That is a completely different topic, something that should be taken up when we do a standards track version. -MSK --f46d044289e8732093051196f9a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 17, 2015 at 8:23 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> Right, whic= h is why things like semi-colon don't need to be
> percent-encoded; they're already special characters in the context= of a URL.

So are comma and exclamation.=C2=A0 What puzzles me is that DMARC sp= ec treats them
differently while RFC3896 does not.=C2=A0 Comma and semicolon seem to behav= e the
same; e.g.:

Ah, that's true.=C2=A0 = I was looking specifically at one and not all three.

At t= his point, since RFC7489 has just been published, I suggest you choose (per= haps with direction from the co-chairs) how to record this discrepancy for = handling when the base draft gets updated.=C2=A0 You could open an erratum = report, or you could add it to the WG's tracker, or maybe they have ano= ther suggestion.
=C2=A0
> They aren't formally imported, and I'm not su= re that's necessary here.=C2=A0 The
> ABNF we have should be comprehensive over DMARC tag-value sets.=C2=A0 = The prose
> you cited is merely meant to convey that they follow the same style.
Right.=C2=A0 The question is if implementations can reuse DKIM parse= rs.

Without studying the ABNF again, I belie= ve so.=C2=A0 DKIM parsers separate tag-value entities at unencoded semicolo= ns, after which the tag name and tag value are separated at unencoded equal= signs.=C2=A0 DMARC records are the same up to that point, and it's bel= ow there for "ruf" and "rua" in the DMARC case that thi= ngs get interesting.=C2=A0 Just like in the case of "b=3D" for DK= IM, those two have special rules for value interpretation: make up a list o= f URIs using an unencoded comma as the separator.
=C2=A0
> Your question is "Are they equivalent?"=C2= =A0 I believe they are.=C2=A0 Although it
> might be ideal to have a specification so tight that there's exact= ly one
> way to do something, in the end I don't think it's harmful to = have two ways
> to say the same thing.=C2=A0 It's more of a concern if there's= to ways to
> interpret a single thing; that's when we arguably have something t= o fix.

I tried the "NOT RECOMMENDED" syntax quoted above.=C2=A0 D= marcian[1] doesn't raise a
brow, and RFC3896-compliant uriparser[2] ingests it smoothly.=C2=A0 However= ,
although I sent a test message to a gmail account, I received no report.=C2= =A0 I
guess Google's implementation doesn't deploy a proper URI parser, b= ut just
looks for "mailto:" followed by a plain path consisting of a sing= le[3]
addr-spec (as defined in RFC6068, i.e. w/o comments) with no query nor frag= ment
--that's what I'd do myself, but I find no arguments in the spec th= at help
proving that that record is bad.

I thin= k we've wandered into implementation comparisons rather than getting th= e ABNF right in the specification.=C2=A0 Or maybe a better way to say that = is: I don't think fixing the discrepancy you've raised would resolv= e the disparity you're observing.
=C2=A0
The spec says a report "is normally sent to ea= ch".=C2=A0 How can a publisher express
that two URIs are meant to be either-or alternatives to each other?

Is that a capability you require?=C2=A0 I don&= #39;t think that's a use case I've ever encountered.
=C2=A0
<= /div>
It may also be worth to require domain in addr-spec to be A-label, as that<= br> simplifies verification and improves dn_ compression.=C2=A0 Such idea appar= ently
conflicts with the example at the end of Section 6.3 of RFC6068, where the = IDN
is percent-encoded instead.

That is a c= ompletely different topic, something that should be taken up when we do a s= tandards track version.

-MSK
--f46d044289e8732093051196f9a5-- From nobody Wed Mar 18 15:40:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3031A90EE for ; Wed, 18 Mar 2015 15:40:35 -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 1G2NKHk2UvZo for ; Wed, 18 Mar 2015 15:40:33 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43B31A8927 for ; Wed, 18 Mar 2015 15:40:33 -0700 (PDT) Received: by pabyw6 with SMTP id yw6so55586196pab.2 for ; Wed, 18 Mar 2015 15:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q3HFEQmkiYaCWrBwdSWEALm5F8eMTFjtt/tgFa2l0Yc=; b=Uyp8uaMqgkwde1mUAmV/CuiqtVNAm1qnvqoMQFl9dAhFQh+N7nfy/sz+jntPIAHTub vv1eOPCRECgntl2VIImFCNC63EE7F1NVJnNzM/voYJTKxO0xO6NJVMMzUjMayxIiCR/R N74LqI0oAkizFBt30RAEG27P0Zgd4HQrxSO8Z1rDvELHedg1+8ouxYdoTTZOr0qeLdBS 1hpIcTs/onOaSs0RjNKQqRe0Yt+RvL0AvwTlRBP++ZOYihd4lSl6Xd2JnIsMLrkMTiJU Uw7nGfscNevGcxeSy+Vx2nVY3JF50THRwK1RYNuMarYIOkWiam+x2cCSODJTwT50ta4N 6HGg== X-Received: by 10.66.241.36 with SMTP id wf4mr110776315pac.8.1426718433317; Wed, 18 Mar 2015 15:40: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 y2sm29252437pdm.31.2015.03.18.15.40.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 15:40:32 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Wed, 18 Mar 2015 15:40:30 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20150318200459.23F9B18020A@rfc-editor.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 18 Mar 2015 22:40:35 -0000 Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows These are reviewed by https://tools.ietf.org/html/draft-dmarc-interoperability-00 https://tools.ietf.org/html/draft-otis-dmarc-author-align-01 was written to highlight possible solutions. John Levine's recommendation that mailing-list operators take on the costly burden of having their participants change their providers is not practical. Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the author role information, otherwise the From is likely overwritten as the only practical means of ensuring message acceptance in the face of provider DMARC (ab)use. By defining a new header field, this should reduce disparity in where to find the author role than that caused by current ad hoc solutions. Such a definition would also better avoid downgrading 'reject' into 'quarantine'. Any thoughts? Regards, Douglas Otis From nobody Wed Mar 18 16:38:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D31A9174 for ; Wed, 18 Mar 2015 16:38:35 -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 VZCrGsBJw-xR for ; Wed, 18 Mar 2015 16:38:33 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F6B1A9170 for ; Wed, 18 Mar 2015 16:38:33 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([10.255.109.167]) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com ([10.255.109.166]) with Microsoft SMTP Server (TLS) id 15.1.130.2; Wed, 18 Mar 2015 23:38:31 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.240]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.4.240]) with mapi id 15.01.0130.000; Wed, 18 Mar 2015 23:38:30 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Thread-Index: AQHQYcySX0+9LP+ZM0WUWBZb9GzSo50i5WUQ Date: Wed, 18 Mar 2015 23:38:30 +0000 Message-ID: References: <20150318200459.23F9B18020A@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(377454003)(199003)(33656002)(62966003)(77156002)(102836002)(15975445007)(68736005)(2900100001)(86362001)(450100001)(106356001)(105586002)(54356999)(50986999)(106116001)(76176999)(2501003)(92566002)(64706001)(46102003)(19580405001)(19580395003)(2950100001)(107886001)(2656002)(87936001)(2351001)(97736003)(101416001)(110136001)(3554006)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 051900244E received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2015 23:38:30.6018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 18 Mar 2015 23:38:35 -0000 > Based upon the almost complete lack of interest of > bulk email providers at promoting a solution, it seems the path > forward is to define a new non-aligned header field able to retain the=20 > author role information, otherwise the From is likely overwritten as=20 > the only practical means of ensuring message acceptance in the face of=20 > provider DMARC (ab)use. If bulk email providers have shown no interest in promoting a solution, why= do we think they'd latch onto this new non-aligned header field as a solut= ion? -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, March 18, 2015 3:41 PM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Dear DMARC WG, Now that RFC7489 has been published, there remains several=20 unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows These are reviewed by https://tools.ietf.org/html/draft-dmarc-interoperability-00 https://tools.ietf.org/html/draft-otis-dmarc-author-align-01 was written to highlight possible solutions. John Levine's recommendation that mailing-list operators take on=20 the costly burden of having their participants change their providers=20 is not practical. Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the=20 author role information, otherwise the From is likely overwritten as=20 the only practical means of ensuring message acceptance in the face of=20 provider DMARC (ab)use. By defining a new header field, this should reduce disparity in where to=20 find the author role than that caused by current ad hoc solutions. Such=20 a definition would also better avoid downgrading 'reject' into=20 'quarantine'. Any thoughts? Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Mar 19 11:41:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF71A87BF for ; Thu, 19 Mar 2015 11:41:12 -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 40AFOTi9ddtp for ; Thu, 19 Mar 2015 11:41:10 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108731A8782 for ; Thu, 19 Mar 2015 11:41:10 -0700 (PDT) Received: by pabxg6 with SMTP id xg6so70403731pab.0 for ; Thu, 19 Mar 2015 11:41:09 -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=9gat9GdOBqTeS9QstwONxUvVMS86ATJJ/QsEoWmpYCY=; b=x6yt06uk9T0DVD4s3AnZ0vgJQTbygXxJ4PBY+Q/uPHz6Wu49DWjRJVV3q3C/v3etjI gq/G4C2oBVq1pGmf6wiHG02TP4AGNelnb/F2qQq3cK+8fQ52tJ/Fp6jO34H41ze1F5N/ InKMYXQpIlSFmMOoMVRrih8tIVvGXN6SRrRB+FKolV7GrYzwI/0IrSZphgsChfPnDuzQ ZORK97ZagYS6VOiyo6eFi+bNM5vZ8d5M4cI5YwoK5g/gwMlrpNA1fCwAhs++tA1KkmIO Ik3hSn/Cs6vGuE6abw152kX37uoZQCStvlc8bgKCteqqAVLpOIurWL2AS5grF/eLdh9I sagg== X-Received: by 10.70.90.133 with SMTP id bw5mr179565365pdb.93.1426790469791; Thu, 19 Mar 2015 11:41:09 -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 fr13sm4197228pdb.55.2015.03.19.11.41.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Mar 2015 11:41:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: Date: Thu, 19 Mar 2015 11:41:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF873E9-16B5-4DBF-A631-FF13B64E8AA7@gmail.com> References: <20150318200459.23F9B18020A@rfc-editor.org> To: Terry Zink X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 19 Mar 2015 18:41:12 -0000 > On Mar 18, 2015, at 4:38 PM, Terry Zink = wrote: >=20 >> Based upon the almost complete lack of interest of >> bulk email providers at promoting a solution, it seems the path >> forward is to define a new non-aligned header field able to retain = the=20 >> author role information, otherwise the =46rom is likely overwritten = as=20 >> the only practical means of ensuring message acceptance in the face = of=20 >> provider DMARC (ab)use. >=20 > If bulk email providers have shown no interest in promoting a = solution, why > do we think they'd latch onto this new non-aligned header field as a = solution? >=20 > -- Terry Dear Terry, Thank you for your comment. This WG seems indicative of most bulk = sender's who often ask "How is DMARC's disruption of legitimate messaging a = problem=20 for me?" They are clearly not interested in preserving the social and = civic=20 benefits derived from open exchanges enabled by email affected by the = DMARC=20 (ab)use occurring against millions of users. This is further evidenced by the current DMARC scheme that offers no = strategy=20 for preserving the role of Author for messages handled by various = third-parties. =20 Those operating a mailing-list are being forced to either reject a large=20= percentage of their users, or replace the =46rom header with what was = likely to=20 have been the Sender header field. The identity of the Author becomes=20= undefined and might be moved to the Reply-to or perhaps x-original-from = header=20 fields. Unless DMARC defines a fallback policy which allows alignment with that = of=20 the Sender header field, the role of Author is placed at risk. In such=20= cases, defining a special "Non-Aligned From" header field could help = better=20 define where this role might be found in a message without it being automatically displayed. This header field might even offer provisions = for the tagging often found in the Subject header field. Perhaps call this new header field "Author". Since few MUAs are likely = to=20 display this header, only those that make extensive use of email that = depends on third-party services are likely to ensure it being displayed. An approach that would not require cooperation from Bulk senders, while = still allowing forums a means to track a history of who said what.=20 Regards, Douglas Otis > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis > Sent: Wednesday, March 18, 2015 3:41 PM > To: Murray S. Kucherawy > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) >=20 > Dear DMARC WG, >=20 > Now that RFC7489 has been published, there remains several=20 > unresolved problems this WG is charted to resolve, primarily-- > 1. Addressing the issues with indirect mail flows >=20 > These are reviewed by > https://tools.ietf.org/html/draft-dmarc-interoperability-00 >=20 > https://tools.ietf.org/html/draft-otis-dmarc-author-align-01 > was written to highlight possible solutions. >=20 > John Levine's recommendation that mailing-list operators take on=20 > the costly burden of having their participants change their providers=20= > is not practical. Based upon the almost complete lack of interest of > bulk email providers at promoting a solution, it seems the path > forward is to define a new non-aligned header field able to retain the=20= > author role information, otherwise the =46rom is likely overwritten as=20= > the only practical means of ensuring message acceptance in the face of=20= > provider DMARC (ab)use. >=20 > By defining a new header field, this should reduce disparity in where = to=20 > find the author role than that caused by current ad hoc solutions. = Such=20 > a definition would also better avoid downgrading 'reject' into=20 > 'quarantine'. >=20 > Any thoughts? >=20 > Regards, > Douglas Otis From nobody Thu Mar 19 12:52:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1F11A8848 for ; Thu, 19 Mar 2015 12:52:52 -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 LxVrQMYK-B7l for ; Thu, 19 Mar 2015 12:52:51 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166DB1A8846 for ; Thu, 19 Mar 2015 12:52:51 -0700 (PDT) Received: by webcq43 with SMTP id cq43so66081682web.2 for ; Thu, 19 Mar 2015 12:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0zk1VjFyG5ityU6HdX+sZmTzE3sCEgpvzL9/VIAQHsA=; b=wzbRHDH/qC+GFg7egMV/Lw2qf6pDh7TZzh1MoFWkP5BlUtb+BAqwt8oNRg6tskeXna SO6hI01D4htrYwnxzWMA6lskyPiwmrlGB/BcNqT9EE9dMPMB1+bFRabDK3kBfbjW7DQb IgR0hI1rndrtgxm2UVYEJzZJG/8jr2TdFpanEaFydj4gJd+HJrOQRFKANYBkQcp4DRDx hNh21/ugzzmqxKssLm9xmnoxHCFOzVZrVo9pW+E1zE9xw1ZSqDt9xIjrhuUDMYHxYUrc DCgMYHzVu1fI9nffhhxZA3o42bD6+3Sek1sIsHyHb7CVHzaxSbTnBXG9Dy0t57sfvejT ySbA== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr18988378wic.94.1426794769853; Thu, 19 Mar 2015 12:52:49 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Thu, 19 Mar 2015 12:52:49 -0700 (PDT) In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> Date: Thu, 19 Mar 2015 12:52:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=001a11c381ce6cb2e10511a98b5b Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 19 Mar 2015 19:52:52 -0000 --001a11c381ce6cb2e10511a98b5b Content-Type: text/plain; charset=UTF-8 On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink wrote: > > If bulk email providers have shown no interest in promoting a solution, > why do we think they'd latch onto this new non-aligned header field as a > solution? > > +1. And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would be of benefit. Rather, I think it would just confuse things further. The closest thing I can see is considering use of Sender somehow, since there are even a few MUAs that do pay vague attention to it. But that's extremely hand-wavy to start with. -MSK --001a11c381ce6cb2e10511a98b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink <t= zink@exchange.microsoft.com> wrote:

If bulk email providers have shown no interest in promoting a soluti= on, why do we think they'd latch onto this new non-aligned header field= as a solution?


+1.=C2=A0 And since the From field is = the only one users really see every time, I'm not sure that declaring a= nd supporting yet another no-seriously-this-is-the-author field would be of= benefit.=C2=A0 Rather, I think it would just confuse things further.
The closest thing I can see is considering use of Sender someh= ow, since there are even a few MUAs that do pay vague attention to it.=C2= =A0 But that's extremely hand-wavy to start with.

-MSK
--001a11c381ce6cb2e10511a98b5b-- From jbucy@google.com Thu Mar 19 13:45:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3131A9091 for ; Thu, 19 Mar 2015 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiMxHBo9HZT1 for ; Thu, 19 Mar 2015 13:45:02 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2D91A906E for ; Thu, 19 Mar 2015 13:45:01 -0700 (PDT) Received: by oier21 with SMTP id r21so75490656oie.1 for ; Thu, 19 Mar 2015 13:45:01 -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=kYUhFxN790F+2+m5L8XwcCNig4KEuEtpDRyqgm/6yw8=; b=fceokh8Q1vcmACo6VT7SmhpIsQfVvG2tDGHBe8xyg0b3t6xRaGFFn5shWmxNJZnWhx QsuUK7yrBCM9M4dou4kv9yndwGWtN+scB+K7IC52NA13WIFoXVZ4PC/f+4HYeg/+d6X3 mvkG7oIZ7keWiNhygl+f/xPy2qVIAxkYHk89oRUytj9Z3a/Q7Jus3ZP0aaf8X/4i52bc jpe6BPBSVjJR4H9J5/IXG8hbPsPPk1aYUWqvSDWSs1ZRxfnr/Kiyabq5XUaNQOlCrhBH cuytfD/nnXn8PW8/N3+5Nv5XRidfW7H5PskCjzakNoLoUfAsxdgcjLi3XXf218KsK1fJ U+Rw== 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=kYUhFxN790F+2+m5L8XwcCNig4KEuEtpDRyqgm/6yw8=; b=gBKyhaFeSwNd5l6vYEnFn4V9ih6XIWU2g9ighVjUfguJHuqHeQ+MI7DsN6tvNVnWDX KbdsCvSfmWHt0Ogu7tdnkszOkhKGyCwfVoG8cUU+/m7BmzMzOEMe8wmPgRVp6it9FJep 3J+HVP2SQHqRvEbBNND3f3R0jofBilKHmilcO4WN8sruHOIgO6pagcNtYrCWX0JaC3FD UlU+5u175N0+YZn1D1oSLfU1Q6kM0K7NGZdSLylS1pr+IlxFGmOSotHx/qM4Ce0Svt64 hSBb0Ngw7fhHVm1MqyGOfHDM0wz5wBUD6JqvGP+A1+ycvF81IdJ9+RfbodGbKv6FYos0 TUbg== X-Gm-Message-State: ALoCoQl+3qfAdfHRV8u9SPDKzKgaBcIbWxmXwRE/D0nMSCIKSJNCC6QVNuEpmPyCsC/E7jsX85hD MIME-Version: 1.0 X-Received: by 10.60.84.144 with SMTP id z16mr43751194oey.32.1426797901208; Thu, 19 Mar 2015 13:45:01 -0700 (PDT) Received: by 10.202.98.85 with HTTP; Thu, 19 Mar 2015 13:45:01 -0700 (PDT) Date: Thu, 19 Mar 2015 13:45:01 -0700 Message-ID: From: John Bucy To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=089e011825ec1188530511aa467e Archived-At: Subject: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 19 Mar 2015 20:45:40 -0000 --089e011825ec1188530511aa467e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I was glad to see mention of content-transfer-encoding issues in draft-ietf-dmarc-interoperability since gateway-transformation breaks dkim signatures. Is there any interest in trying to develop a mime-aware canonicalization for dkim? cheers john --089e011825ec1188530511aa467e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I was glad to see mention of content-transfer-encoding issues in draft-ietf-dmarc-interoperability since gateway-transformation breaks dkim signatures. Is there any interest in trying to develop a mime-aware canonicalization for dkim?



cheers
john
--089e011825ec1188530511aa467e-- From nobody Thu Mar 19 18:28:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19B21A886C for ; Thu, 19 Mar 2015 18:28:50 -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 J2fUMyDIZ5VY for ; Thu, 19 Mar 2015 18:28:49 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E321A8AF8 for ; Thu, 19 Mar 2015 18:28:44 -0700 (PDT) Received: by wgra20 with SMTP id a20so77143851wgr.3 for ; Thu, 19 Mar 2015 18:28:43 -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=eR9gfkh57vlfiibfRdHmN54MMCO6PiuxFdr/A+u5S+s=; b=qHtZIOtZ1XH4qPf9kZKYIExZfF+yy0sbrZxnTmXE9kXTFUryaGA3bd9mqffTxFZsFY USQqlnXHv3eA0ShATPMyGCXm3/LdOS4dhphZMeeVW+wn0LNYd4wTj2EiKgGmznouKfdO ycQ4DXCks+9snOFoGqR78FHI+zHXknwNNeFdXHs5mZ5+xiq8KmZ0Tvel/1oEp6vU1UzK qjWQTcmCNoKbDXThVdvaAVgRoKxlPZ8qABp02470bY2vgZ9ztzBtu3ULAEKKFeTPSB9H ypbeES/8xTyz6E1Ct1Bj53rDO/EZrLeSmvptHbEaK/bN9BOFEz9YmOGdodI950Ykk8Ky qUZg== MIME-Version: 1.0 X-Received: by 10.194.79.226 with SMTP id m2mr155274374wjx.60.1426814923234; Thu, 19 Mar 2015 18:28:43 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Thu, 19 Mar 2015 18:28:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 18:28:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Bucy Content-Type: multipart/alternative; boundary=047d7bf0c538a8e1530511ae3c09 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 20 Mar 2015 01:28:50 -0000 --047d7bf0c538a8e1530511ae3c09 Content-Type: text/plain; charset=UTF-8 There was one proposed: https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 This working group will be discussing this and other options before long. -MSK On Thu, Mar 19, 2015 at 1:45 PM, John Bucy wrote: > I was glad to see mention of content-transfer-encoding issues > in draft-ietf-dmarc-interoperability since gateway-transformation breaks > dkim signatures. Is there any interest in trying to develop a mime-aware > canonicalization for dkim? > > > > cheers > john > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --047d7bf0c538a8e1530511ae3c09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This working= group will be discussing this and other options before long.

= -MSK


On Thu, Mar 19, 2015 at 1:45 PM, John Bucy <jbucy@google.com> wrote:
I was glad to= see mention of content-transfer-encoding issues in=C2=A0draft-ietf-dmarc-i= nteroperability since gateway-transformation breaks dkim signatures. Is the= re any interest in trying to develop a mime-aware canonicalization for dkim= ?



cheers
john

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


--047d7bf0c538a8e1530511ae3c09-- From nobody Fri Mar 20 10:26:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2C1ACDE7 for ; Fri, 20 Mar 2015 10:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDnm_pdUVhqJ for ; Fri, 20 Mar 2015 10:26:00 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662F91ACDE5 for ; Fri, 20 Mar 2015 10:26:00 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so62770373obc.2 for ; Fri, 20 Mar 2015 10:25:59 -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=MHF7VQxxZNSw5tkfRayWF/qPNqrtPWgSEMfZmBcXr4s=; b=MeIB012loU+LCqzrDds4QHwmD+STzRDVkRzb9NnW1OinPdmTYzu9JHi/AwAx5yjYTI HrMtKRofNVSkDWCY3IdY2FkzHZN2uuoZ4CuNNBoRfkqMsGg/fIYwUYAjsgFc1ZosjgHI 2PD9Qi7fJBgkuqSR2LBdMeWLJrPqLthkMff++gb/doNUdC/a6RXHpUGLyV8o0n5FK6Wi A+Iv2n2gS1tmYKb0URsg+hrDGO2Ew8DHatbEkiIQDk8T5uTCKZR+RM6H5BiWXgg6dMu8 tzf7in9e3ITovV4jUUCrrLURHvucuVm/RdZQaIJSZvIy1KzumeB5UANviDmZoGNDkAXr WcYg== 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=MHF7VQxxZNSw5tkfRayWF/qPNqrtPWgSEMfZmBcXr4s=; b=aJL2jzAcE6XVzJ4SIC5oyZ6hIZPHr2N0NYIdUtH0aM4CrL+Bpv7KJjPgmnWQ87s8Tn 3cge/RfmGIO1VXlWSXfnjwtf+Eu3gfEbAqi6+nTGPRPwIhWhqjPjMAljd6no7Av8VKET 1sFGGhV/deZGln62pfRMpY0nvKEAReedWewbt+3w/Q6knuSi46E39eMYjNNb96iXUTSD Jcxr/Db3cQPSVzJDuwzsNad7NQhKtFbhcBin2zOhZLQH5XM0tSBfWPl+X3Gtwkit4L4d MletzW0/1KnnOEAOcSc8R51EEqhdfU8L5AMbwaZBthRD5Pnv7XzZ4Ra6D6ZZYYZaA0fB ROHQ== X-Gm-Message-State: ALoCoQmuSqcXnnTvxhQ7voYmPBcAQtA01+XGKzWM0+DMq3gxgk0LsgS4aWpzsTdXuPkWP1RzfVue MIME-Version: 1.0 X-Received: by 10.202.45.214 with SMTP id t205mr31444050oit.100.1426872359551; Fri, 20 Mar 2015 10:25:59 -0700 (PDT) Received: by 10.202.98.85 with HTTP; Fri, 20 Mar 2015 10:25:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Mar 2015 10:25:59 -0700 Message-ID: From: John Bucy To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1138ea2421b1770511bb9ce8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 20 Mar 2015 17:26:02 -0000 --001a1138ea2421b1770511bb9ce8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hadn't seen that ID, cool! Is there any test data available? cheers john On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy wrote: > There was one proposed: > > https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 > > This working group will be discussing this and other options before long. > > -MSK > > > On Thu, Mar 19, 2015 at 1:45 PM, John Bucy wrote: > >> I was glad to see mention of content-transfer-encoding issues >> in draft-ietf-dmarc-interoperability since gateway-transformation breaks >> dkim signatures. Is there any interest in trying to develop a mime-aware >> canonicalization for dkim? >> >> >> >> cheers >> john >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > --001a1138ea2421b1770511bb9ce8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hadn't seen that ID, cool! Is there any test data available?



cheers
john

On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
This working group will be discussing this and other options before long.

-MSK


On Thu, Mar 19, 2015 at 1:45 PM, John Bucy <jbucy@google.com> wrote:
I was glad to see mention of content-transfer-encoding issues in draft-ietf-dmarc-interoperability since gateway-transformation breaks dkim signatures. Is there any interest in trying to develop a mime-aware canonicalization for dkim?



cheers
john

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



--001a1138ea2421b1770511bb9ce8-- From nobody Fri Mar 20 11:33:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5861A6FFF for ; Fri, 20 Mar 2015 11:33: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 qhqs-tl16ZIU for ; Fri, 20 Mar 2015 11:33:24 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6741A6FE9 for ; Fri, 20 Mar 2015 11:33:24 -0700 (PDT) Received: by wixw10 with SMTP id w10so252712wix.0 for ; Fri, 20 Mar 2015 11:33:22 -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=g11QWfF79UdVqnSFghbntUNnctC4sMoGyn0kfeOZGeQ=; b=LRMQHLtL+hhsdInniUnoHaPZfGDZu8un8aFRoQ40GFlHrgfyhmI2mpElUJzFnjkyTa 18d8wZxCZf6v1I152oY9AaCm6YzYm9CoU9mO3jIBDWekq51Tk3X2KpEI33J8eril3ZCk L8x2tLp1XvJO33iNgVVQz6aU0CTxtKp9Q+php95IMLg5g7VtzWF9dWsKUKX+KIdwnTBo 5F0warDpLpZcXolNYiFqkpHAxAPykzI731QC9TkpXrNR0Hzty55QH9P6YlPmHCdLkOXH Ls7qmOdOGupQ6Q3bDHY7gDcx6ROMQP+cR+j/4uPbhcVG16mYnPyuZp+tB+QyBSNBjfa1 jvNA== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr165705638wjc.135.1426876402892; Fri, 20 Mar 2015 11:33:22 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Fri, 20 Mar 2015 11:33:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Mar 2015 11:33:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Bucy Content-Type: multipart/alternative; boundary=047d7bd6adce2205640511bc8d57 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 20 Mar 2015 18:33:26 -0000 --047d7bd6adce2205640511bc8d57 Content-Type: text/plain; charset=UTF-8 Not yet. I don't think there are any implementations. We were just banging the idea around. I'm looking at doing one soon for OpenDKIM as an experimental add-on. On Fri, Mar 20, 2015 at 10:25 AM, John Bucy wrote: > Hadn't seen that ID, cool! Is there any test data available? > > > > cheers > john > > On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy > wrote: > >> There was one proposed: >> >> https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 >> >> This working group will be discussing this and other options before long. >> >> -MSK >> >> >> On Thu, Mar 19, 2015 at 1:45 PM, John Bucy wrote: >> >>> I was glad to see mention of content-transfer-encoding issues >>> in draft-ietf-dmarc-interoperability since gateway-transformation breaks >>> dkim signatures. Is there any interest in trying to develop a mime-aware >>> canonicalization for dkim? >>> >>> >>> >>> cheers >>> john >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> >> > --047d7bd6adce2205640511bc8d57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not yet. I don't think there are any implementations.= =C2=A0 We were just banging the idea around.=C2=A0 I'm looking at doing= one soon for OpenDKIM as an experimental add-on.

On Fri, Mar 20, 2015 at 10:25 AM,= John Bucy <jbucy@google.com> wrote:
Hadn't seen that ID, cool! Is there any test= data available?



cheers
john

On Thu, Mar 19, 2015 at 6:28 PM, Murray S.= Kucherawy <superuser@gmail.com> wrote:
There was one proposed:

<= a href=3D"https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00" t= arget=3D"_blank">https://tools.ietf.org/html/draft-kucherawy-dkim-list-cano= n-00

This working group will be discussing this and other = options before long.

-MSK


On Thu, Mar 19, 2015 at 1:45 P= M, John Bucy <jbucy@google.com> wrote:
I was glad to see mentio= n of content-transfer-encoding issues in=C2=A0draft-ietf-dmarc-interoperabi= lity since gateway-transformation breaks dkim signatures. Is there any inte= rest in trying to develop a mime-aware canonicalization for dkim?

<= /div>


cheers
john

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




--047d7bd6adce2205640511bc8d57-- From nobody Fri Mar 20 13:55:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6880C1B30D9 for ; Fri, 20 Mar 2015 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKGbWdY7_nUm for ; Fri, 20 Mar 2015 13:55:56 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id BB4C21B30EF for ; Fri, 20 Mar 2015 13:55:55 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 7E2F4842E for ; Fri, 20 Mar 2015 21:55:53 +0100 (CET) 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, 20 Mar 2015 21:55:52 +0100 Message-ID: <73EC61D098084756AA66DC9344CCC624@fgsr.local> From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> Date: Fri, 20 Mar 2015 21:56:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 20:55:58 -0000 On Wednesday, March 18, 2015 11:40 PM [GMT+1=3DCET], Douglas Otis wrote: > Dear DMARC WG, >=20 > Now that RFC7489 has been published, there remains several > unresolved problems this WG is charted to resolve, primarily-- > 1. Addressing the issues with indirect mail flows Why is it better for DMARC to be adapted to indirect email flows, = instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows = to be kept old-style, or the extra notch of trustworthiness that DMARC = alignment provides? How big is the volume of DMARC-problematic indirect email flows, = compared to the general volume of email which can readily benefit from = DMARC? Regards, Regards, J.Gomez From nobody Fri Mar 20 14:49:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE891A9087 for ; Fri, 20 Mar 2015 14:49:04 -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 qsBpwAEG8Dds for ; Fri, 20 Mar 2015 14:49:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC661A9083 for ; Fri, 20 Mar 2015 14:49:02 -0700 (PDT) Received: from kitterma-e6430.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 C2835C40477 for ; Fri, 20 Mar 2015 16:49:01 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1426888141; bh=4u2adMZONTads5ztYhKebXErhOgPW6uXs9IlRtavbC4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hceC77+Rn08SG22iJKdXjVq9xSFxkOnuRLfhDGDkVXcRwRQkIrq2QIPLRYQiXj9/u x8m5OMmn2v9uBv7h2UuinQ0ytt7Qh5Q6MHGTQbAFWxcH7gL4ACHtK+bppaiC3bVJl4 s6hpu8MjSV8MDs3pXSRlhKQ4iaNDwiqmOel7ZLZg= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 20 Mar 2015 17:49:01 -0400 Message-ID: <1923106.CK3y69GTNc@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <73EC61D098084756AA66DC9344CCC624@fgsr.local> References: <20150318200459.23F9B18020A@rfc-editor.org> <73EC61D098084756AA66DC9344CCC624@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:49:04 -0000 On Friday, March 20, 2015 09:56:15 PM J. Gomez wrote: > On Wednesday, March 18, 2015 11:40 PM [GMT+1=CET], Douglas Otis wrote: > > Dear DMARC WG, > > > > Now that RFC7489 has been published, there remains several > > unresolved problems this WG is charted to resolve, primarily-- > > 1. Addressing the issues with indirect mail flows > > Why is it better for DMARC to be adapted to indirect email flows, instead of > indirect email flows to be adapted to DMARC? > > What does provide more value to end users at large: indirect email flows to > be kept old-style, or the extra notch of trustworthiness that DMARC > alignment provides? > > How big is the volume of DMARC-problematic indirect email flows, compared to > the general volume of email which can readily benefit from DMARC? I think it's fair to say it varies a lot. I took a look at the reports for my personal domain for roughly the last week. All the mail was SPF pass, DKIM signed, and aligned went sent. Here's the numbers (keep in mind that receivers are likely to count multiple recipients of mailing list messages as multiple message - I don't actually write 5,000 emails a week): Total: 5,029 My Serverss: 6 Mail List/Forwarded SPF and DKIM fail: 5,022 Mail List DKIM pass: 1 In my case (since a lot of my mail is via email lists) it's essentially all of it. Scott K From nobody Fri Mar 20 15:19:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30EF1A887E for ; Fri, 20 Mar 2015 15:19:32 -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 voPsoPb-0xjc for ; Fri, 20 Mar 2015 15:19:31 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB741A6EFB for ; Fri, 20 Mar 2015 15:19:31 -0700 (PDT) Received: by wegp1 with SMTP id p1so92260907weg.1 for ; Fri, 20 Mar 2015 15:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b7wy9ghxu5cZCVftXAJ4QgZFh1ctzXgZbfIGyyHs18s=; b=Y17fTloeUb/+OTiE1kpb47yh1Jjgv0Zo227/lwnb4E/aCgXQhXZLtmvqnaqIbDffD4 a8glM9sEVk+i03I5eGV03GE8ifKV075TlA6qj/DqQCBwxFPBjAGO6+CkoBZ99ijeZD0F E94Ee3ccz/AduuIf7lm8Qs1LtSedJ9xXzhvGK8fbtMfQDKVcoVwHj4eg2GQVuBB14uLU R0epEQNTSjPvLfzFyXtlo8d0wxAbgBEb0veOLi6vnKrx5pY0xZGIpUCWINQM+JUgUBfC jg9hQdBYGkAOZuLThDvGGPqZF94I4UwR5KZ4pjxHQaVQyzwZD2AcvKYtbGxyaUnV6wTH FVlg== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr161141007wjc.111.1426889969980; Fri, 20 Mar 2015 15:19:29 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Fri, 20 Mar 2015 15:19:29 -0700 (PDT) In-Reply-To: <73EC61D098084756AA66DC9344CCC624@fgsr.local> References: <20150318200459.23F9B18020A@rfc-editor.org> <73EC61D098084756AA66DC9344CCC624@fgsr.local> Date: Fri, 20 Mar 2015 15:19:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7bacb11ecb5d770511bfb5e2 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:19:32 -0000 --047d7bacb11ecb5d770511bfb5e2 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez wrote: > Why is it better for DMARC to be adapted to indirect email flows, instead > of indirect email flows to be adapted to DMARC? > > What does provide more value to end users at large: indirect email flows > to be kept old-style, or the extra notch of trustworthiness that DMARC > alignment provides? > > How big is the volume of DMARC-problematic indirect email flows, compared > to the general volume of email which can readily benefit from DMARC? > I'm pretty sure volumes are not the problem as much as the painful side effects, most notably unsubscription of uninvolved users from mailing lists when someone protected by DMARC posts to the list. (See Section 5.2 of RFC6377, which describes the same problem in the context of ADSP. RFC7372 might help with this, if and when it ever gets widely implemented.) My own view is that we should pursue whichever of the two avenues is the lower-hanging fruit. The problem at the moment is that it's not at all clear to me which of the two that is. We have among us implementers of both MLM packages and DKIM/SPF packages and standards, so at least the right people are "in the room". There are, however, substantial barriers in both directions. We definitely have our work cut out for us. -MSK --047d7bacb11ecb5d770511bfb5e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
Why is it better for DMARC to be= adapted to indirect email flows, instead of indirect email flows to be ada= pted to DMARC?

What does provide more value to end users at large: indirect email flows to= be kept old-style, or the extra notch of trustworthiness that DMARC alignm= ent provides?

How big is the volume of DMARC-problematic indirect email flows, compared t= o the general volume of email which can readily benefit from DMARC?

I'm pretty sure volumes are not the proble= m as much as the painful side effects, most notably unsubscription of uninv= olved users from mailing lists when someone protected by DMARC posts to the= list.=C2=A0 (See Section 5.2 of RFC6377, which describes the same problem = in the context of ADSP.=C2=A0 RFC7372 might help with this, if and when it = ever gets widely implemented.)

My own view is that we sho= uld pursue whichever of the two avenues is the lower-hanging fruit.=C2=A0 T= he problem at the moment is that it's not at all clear to me which of t= he two that is.=C2=A0 We have among us implementers of both MLM packages an= d DKIM/SPF packages and standards, so at least the right people are "i= n the room".=C2=A0 There are, however, substantial barriers in both di= rections.

We definitely have our work cut out for us.
=
-MSK
--047d7bacb11ecb5d770511bfb5e2-- From nobody Fri Mar 20 16:40:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4070C1A911F for ; Fri, 20 Mar 2015 16:40:42 -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 bPF1YqXNB3g9 for ; Fri, 20 Mar 2015 16:40:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE881A911E for ; Fri, 20 Mar 2015 16:40:41 -0700 (PDT) Received: from [192.168.1.87] (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 t2KNeYDj021551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 Mar 2015 16:40:38 -0700 Message-ID: <550CAFEE.8060706@dcrocker.net> Date: Fri, 20 Mar 2015 16:40:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Terry Zink References: <20150318200459.23F9B18020A@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 20 Mar 2015 16:40:38 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) 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: Fri, 20 Mar 2015 23:40:42 -0000 On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: > And since the From field is the only one users really see every time, > I'm not sure that declaring and supporting yet another > no-seriously-this-is-the-author field would be of benefit. I'd like to try to get us to phrase this differently. In particular, it does not matter what user's 'see'. The information is processed by a filtering agent, independent of the user. So what matters is that the From: field domain is the only field certain to be provided by the author. Everything about DMARC derives from the certainty of that presence. For a mechanism, like DKIM, that seeks a collaborative relationship between origin and destination, there does not need to be certainty that the information will be present. There merely needs to be certainty that /if/ it is present, it is valid. DMARC is not like that. DMARC is an effort to look for spoofing. This means that bad actors will attempt to place the trust-related information (like a domain name) into the message, but without authorization. So, what domain name is certain to be in the message, other than the one in the From field? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 20 22:27:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF611A8BC4 for ; Fri, 20 Mar 2015 22:27:36 -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 qxx_I3W5iXLj for ; Fri, 20 Mar 2015 22:27:35 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3417A1A8ACC for ; Fri, 20 Mar 2015 22:27:34 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 6110D1C38D2; Sat, 21 Mar 2015 14:27:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3A1E5120EC9; Sat, 21 Mar 2015 14:27:33 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <73EC61D098084756AA66DC9344CCC624@fgsr.local> References: <20150318200459.23F9B18020A@rfc-editor.org> <73EC61D098084756AA66DC9344CCC624@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Mar 2015 14:27:33 +0900 Message-ID: <87619uq5ru.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 05:27:37 -0000 J. Gomez writes: > Why is it better for DMARC to be adapted to indirect email flows, > instead of indirect email flows to be adapted to DMARC? Because they *can't* be adapted by definition. DMARC "p=reject" prohibits indirect mail, and "p=quarantine" sends it to the spam bucket. Or perhaps you're thinking of the same thing that Douglas is. To him, I suppose "adapting DMARC" includes third-party authorization mechanisms. I consider those actually to be "adapting DMARC" because they require participation of the first party. YMMV, you may consider that "adapting indirect mail" because often it will be initiated by the 3rd party applying for authorization. However, several proposals have been made for limited authorization by mailbox owners who can't actually change the DMARC policies of the authorizing domain. These also require participation of the authorizing domain but not necessarily the third party. So I prefer our interpretation that TPA is "adapting DMARC". Steve From nobody Fri Mar 20 22:37:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACA11A88DB for ; Fri, 20 Mar 2015 22:37:11 -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 nGw2-lsadi5S for ; Fri, 20 Mar 2015 22:37:10 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F41A872C for ; Fri, 20 Mar 2015 22:37:09 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 4FD371C38F6; Sat, 21 Mar 2015 14:37:09 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2B81A120EC9; Sat, 21 Mar 2015 14:37:09 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <550CAFEE.8060706@dcrocker.net> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Mar 2015 14:37:09 +0900 Message-ID: <874mpeq5bu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 05:37:11 -0000 Dave Crocker writes: > On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: > > And since the From field is the only one users really see every time, > > I'm not sure that declaring and supporting yet another > > no-seriously-this-is-the-author field would be of benefit. > > > I'd like to try to get us to phrase this differently. > > In particular, it does not matter what user's 'see'. The information is > processed by a filtering agent, independent of the user. > > So what matters is that the From: field domain is the > only field certain to be provided by the author. > > Everything about DMARC derives from the certainty of that presence. Except for the very existence of DMARC, which was primarily motivated by phishing and "recommended-by-friend spam", which depend on what the recipient sees, and the recipient's association of trustworthiness with the message's apparent author. So no, the filtering agents don't really matter to DMARC as far as I can see. What matters to DMARC is when inauthentic From addresses get past the filtering agents. At that point DMARC intervenes and (optionally at the domain owner's request) interdicts inauthentic addresses in From:. Steve From nobody Sat Mar 21 00:23:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDF61A8A6A for ; Sat, 21 Mar 2015 00:23:10 -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 JTFtSl-x074D for ; Sat, 21 Mar 2015 00:23:09 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06AAC1A8938 for ; Sat, 21 Mar 2015 00:23:09 -0700 (PDT) Received: by wixw10 with SMTP id w10so4288537wix.0 for ; Sat, 21 Mar 2015 00:23:07 -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=3YLgXJhbVmrM+dRpPYuY8exqOLELen0EFDm79UaEdn0=; b=1D384tfkGxi48j3Ozz/bAhn6llnC9xCbn7Rw1YwiqjCfgcnT7Kpr4NKkJoW/EcK2e4 dK4dA+Kkp+KegPEmBpY5wKQXxeRXifrolSoWnmffcdFeCMDWdzC8BUEVIKEe6M3YqvRH OqP6/3bNh0roPj+zM8yyHQsTEPDv1DzRBQ+Q0B+XP7NRwrENpz+N5gnCzdmtDAIlPzZp wdMh2NRpeAuN1HloJTNU8YZVfzhF2zaZ9/4Y3e0EZs+S7o3zTHYj5hqJhPnlB4kJJb7J A31CUW7VmZbH3PEzDAQzluvo/v19uChUiSrcjolX3TjGxqUS0lBphcvvH2bxwgMdU4JU Cyyw== MIME-Version: 1.0 X-Received: by 10.194.79.226 with SMTP id m2mr165501952wjx.60.1426922587797; Sat, 21 Mar 2015 00:23:07 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Sat, 21 Mar 2015 00:23:07 -0700 (PDT) In-Reply-To: <550CAFEE.8060706@dcrocker.net> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> Date: Sat, 21 Mar 2015 00:23:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7bf0c538f7be750511c74dd7 Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 07:23:10 -0000 --047d7bf0c538f7be750511c74dd7 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker wrote: > On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: > > And since the From field is the only one users really see every time, > > I'm not sure that declaring and supporting yet another > > no-seriously-this-is-the-author field would be of benefit. > > > I'd like to try to get us to phrase this differently. > > In particular, it does not matter what user's 'see'. The information is > processed by a filtering agent, independent of the user. > > So what matters is that the From: field domain is the > only field certain to be provided by the author. > Isn't it important that this information is also the most likely to be presented to the end user as the author of the content that's also shown to the user? Why do you claim it doesn't matter? There would be a lot less incentive to be concerned about From: alignment if that were not the case. -MSK --047d7bf0c538f7be750511c74dd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
On 3/19/2015 12:5= 2 PM, Murray S. Kucherawy wrote:
> And since the From field is the only one users really see every time,<= br> > I'm not sure that declaring and supporting yet another
> no-seriously-this-is-the-author field would be of benefit.


I'd like to try to get us to phrase this differently.

In particular, it does not matter what user's 'see'.=C2=A0 The = information is
processed by a filtering agent, independent of the user.

=C2=A0 =C2=A0 =C2=A0So what matters is that the From: field domain is the =C2=A0 =C2=A0 =C2=A0only field certain to be provided by the author.

Isn't it important that this information = is also the most likely to be presented to the end user as the author of th= e content that's also shown to the user? Why do you claim it doesn'= t matter?

There would be a lot less incentive to be conce= rned about From: alignment if that were not the case.

-MSK
--047d7bf0c538f7be750511c74dd7-- From nobody Sat Mar 21 05:55:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98741A92E4 for ; Sat, 21 Mar 2015 05:55:18 -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 kMhchlm_7y53 for ; Sat, 21 Mar 2015 05:55:16 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5AE1A92E3 for ; Sat, 21 Mar 2015 05:55:16 -0700 (PDT) Received: by padcy3 with SMTP id cy3so137442304pad.3 for ; Sat, 21 Mar 2015 05:55:16 -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=b5lHBKQtFncf8b3eAS2iyUN33VFedzFG2H1/riAnHFQ=; b=BRfn06L4idvmnBvW5HeBkLHRAvBxKpFhUmbTloRvR5BTtgebw3AYUp6UeErc42DL8K r/6YgMuoMaW3SiTMFt4+K7roc97WvCPuS4rHvT/t3iWbimTpylMmHofKllT1JZfNMjfy JBPuwvJicAg2VJlF2fVqe7n13n+5eGF7MvIH0huCzW8VzScbIOV6c5Xnk6GH+9jlvb2L 0hLuzSqtmtjbk3vM40V9tVrkRUL4RywzgdPzNRdH1ODGr7JDs4eAqCXCE+US4KxFkN9C ojt/n808+YIT8A4RmC7frjEFcbsecANz6/4zKaik8DAxmleTdLB2X9r3LFAmSe+KsuDI 2+lw== X-Received: by 10.66.235.36 with SMTP id uj4mr196937675pac.123.1426942516505; Sat, 21 Mar 2015 05:55:16 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id ha5sm1907351pbb.34.2015.03.21.05.55.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Mar 2015 05:55:15 -0700 (PDT) Message-ID: <550D6A2D.7050500@gmail.com> Date: Sat, 21 Mar 2015 05:55:09 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 12:55:18 -0000 On 3/21/2015 12:23 AM, Murray S. Kucherawy wrote: > In particular, it does not matter what user's 'see'. The information is > processed by a filtering agent, independent of the user. > > So what matters is that the From: field domain is the > only field certain to be provided by the author. > > Isn't it important that this information is also the most likely to be > presented to the end user as the author of the content that's also shown > to the user? Why do you claim it doesn't matter? > > There would be a lot less incentive to be concerned about From: > alignment if that were not the case. It's important to distinguish between the initial reason people were motivated to work on DMARC, versus what DMARC does. Users do not process DMARC. When talking about a protocol, talk about the entities that process it. From: happens to be the only place that always has the presence of a domain associated with the origin. And note that without DMARC, these days users typically don't see the domain. In other words, it isn't presented to the user. This inconvenient fact is ignored or dismissed every time someone touts the user's role in DMARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Mar 21 07:36:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FDA1B2850 for ; Sat, 21 Mar 2015 07:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.68 X-Spam-Level: X-Spam-Status: No, score=-99.68 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 xp2J0f2FaAwf for ; Sat, 21 Mar 2015 07:36:50 -0700 (PDT) Received: from catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 30EF51AC3E6 for ; Sat, 21 Mar 2015 07:36:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2569; t=1426948602; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5SWKOD27FPlbqgzpZktbb8H9ElM=; b=d0QwM9Uimo3kjSE8cHO0 WxWLWDGqqx8ZIKOGVfYWjRuMrWz3kua7Fn67/7LaezQgbILYEkOQHFc6v4M5iMST WmBnwbNRRDyt5a9WUDA3XKk++quIddAFxXUZLmAvQ8tLRV0UHrEwPhKND32/Shvp 1gzA6XRbI4Ltr3t0+ScsBcg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 21 Mar 2015 09:36:42 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 658641659.15266.5660; Sat, 21 Mar 2015 09:36:42 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2569; t=1426948410; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=cuFyjue 3hAIw8VSTnXYyqfxQozyj9n1s/VLb/0JnyI4=; b=GCY/B7sZW+/CR5Bu5iJPQnc 7zzjewddGj3RNjpyrwIKR4QyxSICVX6vRtzWhvo0qx2X8WpIsiJ+bseu2+KDCoQK IrMDLVso2809gc02aOMfWZleB/dAwG6GEH3EIL1IBEIqO5YEN/J0AZqpWBWFiox8 KE+Xtt30RombIQOarfPM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 21 Mar 2015 10:33:30 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3545912831.9.1556; Sat, 21 Mar 2015 10:33:29 -0400 Message-ID: <550D81FC.9060105@isdg.net> Date: Sat, 21 Mar 2015 10:36:44 -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: <20150318200459.23F9B18020A@rfc-editor.org> <73EC61D098084756AA66DC9344CCC624@fgsr.local> In-Reply-To: <73EC61D098084756AA66DC9344CCC624@fgsr.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 14:36:53 -0000 As a long time total mail system product(s) developer, at this point, IMV, we have a marketing problem. We did have technical solutions laid out with 3rd party authorization concerns. However, it hasn't been "sold enough" and if even if you do work it, you have to champion it. One can't write documents nor work on ideas while still believing it won't work. If you (the authors) don't believe it, no one else will -- the bottom line. Just consider that DMARC has a problem that all the previous POLICY FRAMEWORKS long had. So how could DMARC replaced ADSP as the "Super ADSP" when ADSP was abandoned by the key DKIM people within the IETF? It does the same thing, same problem? How was that possible? Marketing. DMARC did have the REPORTING part that we intentionally left out in coming up with SSP/ADSP. The view was it would eventually could be abused and most certainly it would be become a high overhead redundant reporting feature -- can't be reporting forever. Thats the one thing I believe I underestimated when I strongly supported and implemented the previous DKIM policy ideas such as SSP and ADSP and also my I-D DSAP (DKIM Signature Authorization Protocol) where some of the initial MLM interfacing ideas were written down. Overall, you got to have a solid protocol first that makes sense independent of any mail component that touches mail. I believe we had something with DKIM + POLICY but it requires you to change the the MLM software or its frontend interface to follow the POLICY concept. Until that happens, nothing is going to change. -- HLS On 3/20/2015 4:56 PM, J. Gomez wrote: > On Wednesday, March 18, 2015 11:40 PM [GMT+1=VET], Douglas Otis wrote: > >> Dear DMARC WG, >> >> Now that RFC7489 has been published, there remains several >> unresolved problems this WG is charted to resolve, primarily-- >> 1. Addressing the issues with indirect mail flows > > Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? > > What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides? > > How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? > > Regards, > > Regards, > J.Gomez > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Sat Mar 21 09:41:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912E41A01F9 for ; Sat, 21 Mar 2015 09:41:08 -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 qVmCCFV4bExr for ; Sat, 21 Mar 2015 09:41:06 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9014C1A016C for ; Sat, 21 Mar 2015 09:41:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 0E11C1C38DF; Sun, 22 Mar 2015 01:41:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DCC45120EC9; Sun, 22 Mar 2015 01:41:04 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <550D6A2D.7050500@gmail.com> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 22 Mar 2015 01:41:04 +0900 Message-ID: <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 16:41:08 -0000 Dave Crocker writes: > From: happens to be the only place that always has the presence of a > domain associated with the origin. Except it doesn't always have a domain associated with the originating MTA, and there's nothing in RFC 5322 that says it does. RFC 5322 says you shouldn't put an address in From that you don't have the right to use, not that it must be aligned with the domain of the injecting MTA. So I must be missing something, because it seems to me that you've got the DMARC From alignment tail wagging the whole RFC 5322 dog here. > And note that without DMARC, these days users typically don't see > the domain. In other words, it isn't presented to the user. This > inconvenient fact is ignored or dismissed every time someone touts > the user's role in DMARC. What's so inconvenient about it? I'm apparently missing something, but I don't see how the fact that the domain sometimes isn't presented is particularly inconvenient for the position that user behavior matters. Specifically, in many cases failure to present the domain as a character string doesn't mean that the displayed identity isn't associated with the address in some way such as presentation of an avatar looked up by address, or in a tool-tip. There may be other subtle channels by which the address can influence user behavior without being displayed as a character string. And sometimes it is presented as a string. Note that these "subtle channels" are MUA functions, and thus outside the purview of current MTA-based DMARC implementations. I think it's quite valid to emphasize the user's role here. From nobody Sat Mar 21 14:32:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349981A9004 for ; Sat, 21 Mar 2015 14:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 zYT4aSq8hVsZ for ; Sat, 21 Mar 2015 14:32:03 -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 ED02E1A8FD7 for ; Sat, 21 Mar 2015 14:32:02 -0700 (PDT) Received: (qmail 47457 invoked from network); 21 Mar 2015 21:32:01 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 21 Mar 2015 21:32:01 -0000 Date: 21 Mar 2015 21:31:39 -0000 Message-ID: <20150321213139.8887.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 21:32:04 -0000 >> How big is the volume of DMARC-problematic indirect email flows, compared >> to the general volume of email which can readily benefit from DMARC? The numbers I've seen say that the volume of mail that DMARC screws up is fairly low, but it is very high value. Personally, I would be happy never to get any more mail from my bank, if it meant that my mailing lists would work again. R's, John From nobody Sat Mar 21 17:46:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96191A00F8 for ; Sat, 21 Mar 2015 17:46:13 -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 9oM6w3GfG79B for ; Sat, 21 Mar 2015 17:46:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DA61A0053 for ; Sat, 21 Mar 2015 17:46:12 -0700 (PDT) Received: from [172.20.0.165] (rrcs-71-41-251-196.sw.biz.rr.com [71.41.251.196]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2M0k4Ph025534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 21 Mar 2015 17:46:07 -0700 Message-ID: <550E10C5.1070509@dcrocker.net> Date: Sat, 21 Mar 2015 17:45:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" , Dave Crocker References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8 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, 21 Mar 2015 17:46:08 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 00:46:14 -0000 On 3/21/2015 9:41 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > From: happens to be the only place that always has the presence of a > > domain associated with the origin. > > Except it doesn't always have a domain associated with the originating > MTA, Well, I said 'origin' and not 'originator' but yeah, I should have thought of a more generic term. I meant not to invoke 'originator' and meant mean "something around the creation of the message, such as author, originator, gateway mta, whatever..."[*] > and there's nothing in RFC 5322 that says it does. RFC 5322 says > you shouldn't put an address in From that you don't have the right to > use, not that it must be aligned with the domain of the injecting MTA. Thanks for the refresher. > So I must be missing something, because it seems to me that you've got > the DMARC From alignment tail wagging the whole RFC 5322 dog here. No idea what you mean. > > And note that without DMARC, these days users typically don't see > > the domain. In other words, it isn't presented to the user. This > > inconvenient fact is ignored or dismissed every time someone touts > > the user's role in DMARC. > > What's so inconvenient about it? Folks tend to promote DMARC's choice of From field due to the fact that it's presented to the end-user, as if the end-user will behave differently with DMARC active. The end-user won't. They mostly don't see the domain name, and it mostly doesn't matter when they do. On the other hand, the fact that the From field is the only domain name reliably associated with content creation and that receiving filtering engines can do an assessment of validity when DMARC validates, is extremely meaningful. But there is no 'user' in the handling equation for DMARC. There may be other > subtle channels by which the address can influence user behavior > without being displayed as a character string. And sometimes it is > presented as a string. > > Note that these "subtle channels" are MUA functions, and thus outside > the purview of current MTA-based DMARC implementations. I think it's > quite valid to emphasize the user's role here. Subtle channels is a fun idea. Unfortunately there is an infinite number of fun ideas. Perhaps you can cite some empirical research evidence of its relevance to this topic? d/ [*] However note that the essence of DMARC is a /very/ tight coupling between content author's domain owner and the originator. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Mar 22 08:06:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6E71AC3A5 for ; Sun, 22 Mar 2015 08:06:00 -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 LmBCGVDkoLT5 for ; Sun, 22 Mar 2015 08:05:57 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 375851AC39F for ; Sun, 22 Mar 2015 08:05:56 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 91A108646 for ; Sun, 22 Mar 2015 16:05:55 +0100 (CET) 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; Sun, 22 Mar 2015 16:05:55 +0100 Message-ID: From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> <73EC61D098084756AA66DC9344CCC624@fgsr.local> <550D81FC.9060105@isdg.net> Date: Sun, 22 Mar 2015 16:06:15 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:06:00 -0000 On Saturday, March 21, 2015 3:36 PM [GMT+1=3DCET], Hector Santos wrote: > As a long time total mail system product(s) developer, at this point, > IMV, we have a marketing problem. >=20 > We did have technical solutions laid out with 3rd party authorization > concerns. However, it hasn't been "sold enough" and if even if you > do work it, you have to champion it. One can't write documents nor > work on ideas while still believing it won't work. If you (the > authors) don't believe it, no one else will -- the bottom line. I consider that any "3rd party authorization scheme" for DMARC will fail = --not to fail technically, but to fail be implemented in the real = world-- if it happens to need, to be workable, the nuanced and = labour-intensive participation of the sender's domain Owner. Consider Yahoo and OAL reckless usage of "p=3Dreject". Why would they = suddenly be any less reckless and choose to take into account any "3rd = party authorization scheme" for DMARC? Do we have any hint from big ESPs = currently using "p=3Dreject" that they are willing to take into account = any "3rd party authorization scheme" for DMARC? If not, we have the risk = to taking the effort to design a great "3rd party authorization scheme" = for DMARC which ultimately will fail to be taken into account in any = significant way in the real world. So, Hector, no matter how good "marketing" is, it is going to be next to = impossible to sell something which is nuanced and labour-intensive, and = at the same time provides little --perceived-- reward to the agents = tasked with implementing it and keeping it current and running in a = well-oiled fashion. Regards, J.Gomez From nobody Sun Mar 22 08:25:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFCD1A8A05 for ; Sun, 22 Mar 2015 08:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRxE3LxDdIIv for ; Sun, 22 Mar 2015 08:25:08 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 74ADE1A8A04 for ; Sun, 22 Mar 2015 08:25:08 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 72E888646 for ; Sun, 22 Mar 2015 16:25:07 +0100 (CET) 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; Sun, 22 Mar 2015 16:25:07 +0100 Message-ID: <8AF248169E194BD2956417D4E7251030@fgsr.local> From: "J. Gomez" To: References: <20150321213139.8887.qmail@ary.lan> Date: Sun, 22 Mar 2015 16:25:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:25:10 -0000 On Saturday, March 21, 2015 10:31 PM [GMT+1=3DCET], John Levine wrote: > > > How big is the volume of DMARC-problematic indirect email flows, > > > compared to the general volume of email which can readily benefit > > > from DMARC?=20 >=20 > The numbers I've seen say that the volume of mail that DMARC screws up > is fairly low, but it is very high value. >=20 > Personally, I would be happy never to get any more mail from my bank, > if it meant that my mailing lists would work again. But do you think the general email-using population will be happy to = miss authentic email from eBay, Amazon, Paypal and American Airlines, = just to get email from some mailing list(s) delivered to their inbox? Also, your mailing list would work again in a heartbeat, in a = DMARC-world, if you just configured them to put the original Header-From = into the "description" of a new Header-From, like: From: "Pedro Antunez" =3D=3D> From: "Pedro Antunez = pedro@example.com" It's about time that MLM software that modifies the in-flight message, = rendering its DKIM signature invalid, takes ownership as Author of the = new modified message they are resending. Regards, J.Gomez From nobody Sun Mar 22 10:18:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75B41A00C2 for ; Sun, 22 Mar 2015 10:18:11 -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 8sgHcJxV1q3K for ; Sun, 22 Mar 2015 10:18:07 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE151A007F for ; Sun, 22 Mar 2015 10:18:07 -0700 (PDT) Received: by wegp1 with SMTP id p1so120263566weg.1 for ; Sun, 22 Mar 2015 10:18:05 -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=iNFbG84M7lvGpRyKt+JO2yPkjrgAPiRukxaGKIhyuZo=; b=OBUqJn83n+WUc5cvIZMxu4c+BACUuRNdvhaI/dDCSxuRCb4+M6D95kypPHG3i8DC2Y WykNLScKi5Csuu7AyAZSX2qCd5vWxnyuyqR/25gU7OujrO3IzO2QrBTv/bQcpPlQ209e aNWeVXfAI/zne1Aer0L24XTqifPRlZHEpjTzDOF0IlkRaxJFTmZoZtXop4PPrnOwrnOn RJYMI8F9sNy5oulKPKqW01Pi36b/EUWh2oz7BM6DNZMia+w6lVVEhqXCQnEHnS9Z3LNn Oo5jCdEHHYbr3iPRLgsGoIi3GdYWQqrFMVaOeLUvkYYePkjyGkQUV6escHYMU0bQ/mEp xSAA== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr174313263wjc.111.1427044685861; Sun, 22 Mar 2015 10:18:05 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Sun, 22 Mar 2015 10:18:05 -0700 (PDT) In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <73EC61D098084756AA66DC9344CCC624@fgsr.local> <550D81FC.9060105@isdg.net> Date: Sun, 22 Mar 2015 10:18:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7bacb11e945b3a0511e3bb86 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 17:18:11 -0000 --047d7bacb11e945b3a0511e3bb86 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 22, 2015 at 8:06 AM, J. Gomez wrote: > I consider that any "3rd party authorization scheme" for DMARC will fail > --not to fail technically, but to fail be implemented in the real world-- > if it happens to need, to be workable, the nuanced and labour-intensive > participation of the sender's domain Owner. > I have to agree. I've seen nothing since the advent of SPF to convince me otherwise. Several have been proposed and none have seen anything more than trivial uptake, even when written down as experimental RFCs or made freely available in open source code. An argument has been made that they got no uptake because they are flawed, but I think that's myopic; the ones that are available are not set in stone and thus could be easily mutated into something more palatable if there was actual interest. That nobody has proposed anything of the form "We would implement third-party scheme X if only it had Y done to it" tells me that the general idea is a dead end, not that the specific proposals on the table are faulty. -MSK --047d7bacb11e945b3a0511e3bb86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 22, 2015 at 8:06 AM, J. Gomez <jgomez@seryr= ich.com> wrote:
I consider that any "3rd pa= rty authorization scheme" for DMARC will fail --not to fail technicall= y, but to fail be implemented in the real world-- if it happens to need, to= be workable, the nuanced and labour-intensive participation of the sender&= #39;s domain Owner.

I have to agree.=C2= =A0 I've seen nothing since the advent of SPF to convince me otherwise.= =C2=A0 Several have been proposed and none have seen anything more than tri= vial uptake, even when written down as experimental RFCs or made freely ava= ilable in open source code.

An argument has been made that they got = no uptake because they are flawed, but I think that's myopic; the ones = that are available are not set in stone and thus could be easily mutated in= to something more palatable if there was actual interest.=C2=A0 That nobody= has proposed anything of the form "We would implement third-party sch= eme X if only it had Y done to it" tells me that the general idea is a= dead end, not that the specific proposals on the table are faulty.

-MSK
--047d7bacb11e945b3a0511e3bb86-- From nobody Sun Mar 22 11:39:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A491A00C3 for ; Sun, 22 Mar 2015 11:39: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 zCHFuouweKhd for ; Sun, 22 Mar 2015 11:39:35 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 38D4E1A0054 for ; Sun, 22 Mar 2015 11:39:34 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 7CE401C3856; Mon, 23 Mar 2015 03:39:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 552B6120EC9; Mon, 23 Mar 2015 03:39:33 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <550E10C5.1070509@dcrocker.net> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 23 Mar 2015 03:39:33 +0900 Message-ID: <87oankop0a.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:39:37 -0000 Dave Crocker writes: > Folks tend to promote DMARC's choice of From field due to the fact > that it's presented to the end-user, as if the end-user will behave > differently with DMARC active. The end-user won't. I haven't noticed anybody advocating that. The claim is that the user behavior changes with the identity in the From field, and whether they trust its authenticity. People do make a lot of fuss about the display of the domain (eg, DMARC itself deprecates From munging that puts the address in a comment or the display name in From). While that isn't the whole story (can't be, since often the domain isn't displayed by the MUA), the address in From is an important part of the correspondent's identity, and users tend to trust that it's authentic and the MUA is using the "right" one for each correspondent. I think it's reasonable to suppose that the identity in From does affect user behavior. > But there is no 'user' in the handling equation for DMARC. Is that all you are trying to say? That seems tautological to me, since DMARC is a software system that operates (usually) in the MTA. I took you to mean that the relationship between the purported identity in From, based on the address in that field, and the user's behavior is irrelevant to specification of DMARC and related protocols. From nobody Sun Mar 22 11:52:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678711A017F for ; Sun, 22 Mar 2015 11:52:01 -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 RleE6hFkSB6N for ; Sun, 22 Mar 2015 11:51:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A601A00C8 for ; Sun, 22 Mar 2015 11:51:59 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2MIppIS007741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Mar 2015 11:51:55 -0700 Message-ID: <550F0F42.8030008@dcrocker.net> Date: Sun, 22 Mar 2015 13:51:46 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" , dcrocker@bbiw.net References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <87oankop0a.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87oankop0a.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 22 Mar 2015 11:51:56 -0700 (PDT) Archived-At: Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:52:01 -0000 On 3/22/2015 1:39 PM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > Folks tend to promote DMARC's choice of From field due to the fact > > that it's presented to the end-user, as if the end-user will behave > > differently with DMARC active. The end-user won't. > > I haven't noticed anybody advocating that. The claim is that the user > behavior changes with the identity in the From field, and whether they > trust its authenticity. Right. And this is claimed in the absence of supporting research and to the contrary of usability experience. > > But there is no 'user' in the handling equation for DMARC. > > Is that all you are trying to say? That seems tautological to me, > since DMARC is a software system that operates (usually) in the MTA. Heh. > I took you to mean that the relationship between the purported > identity in From, based on the address in that field, and the user's > behavior is irrelevant to specification of DMARC and related > protocols. I didn't say that, but I'll say it now, too. (Ignoring the underying truth that users get tricked, which provides the motivation for worrying about spoofing.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Mar 22 12:14:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F9A1A039B for ; Sun, 22 Mar 2015 12:14:50 -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 0ttg9FwHL2Lb for ; Sun, 22 Mar 2015 12:14:49 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 730731A039A for ; Sun, 22 Mar 2015 12:14:49 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 562E21C386D; Mon, 23 Mar 2015 04:14:48 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 332D3120EC9; Mon, 23 Mar 2015 04:14:48 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <8AF248169E194BD2956417D4E7251030@fgsr.local> References: <20150321213139.8887.qmail@ary.lan> <8AF248169E194BD2956417D4E7251030@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 23 Mar 2015 04:14:48 +0900 Message-ID: <87mw34ondj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 19:14:51 -0000 J. Gomez writes: > It's about time that MLM software that modifies the in-flight > message, rendering its DKIM signature invalid, takes ownership as > Author of the new modified message they are resending. Not going to happen. GNU Mailman list owners have had the option since November 2013, many were forced to use it in the Great DMARC Fiasco of last April, and they hate it. So we are not going to force it on anybody. I can't speak for other MLM maintainers, but I suspect many have had similar experiences and probably all have some list owners who hate the idea of "taking ownership" -- they'll probably make it optional too. Many of us hate the idea in principle, anyway. In our interpretation of RFC 5322 the modifications the MLM makes do not create a new message any more than adding Received fields does (and of course there are very good reasons to keep the Message-Id). From nobody Sun Mar 22 13:25:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFBF1A1ABF for ; Sun, 22 Mar 2015 13:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.963 X-Spam-Level: *** X-Spam-Status: No, score=3.963 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 5L4bgKEZN6XW for ; Sun, 22 Mar 2015 13:25:23 -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 76DD21A1ABB for ; Sun, 22 Mar 2015 13:25:23 -0700 (PDT) Received: (qmail 5817 invoked from network); 22 Mar 2015 20:25:22 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 22 Mar 2015 20:25:22 -0000 Date: 22 Mar 2015 20:25:00 -0000 Message-ID: <20150322202500.37229.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <8AF248169E194BD2956417D4E7251030@fgsr.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 20:25:25 -0000 >But do you think the general email-using population will be happy to miss >authentic email from eBay, Amazon, Paypal and American Airlines, just to get >email from some mailing list(s) delivered to their inbox? My impression is that most users put a very low value on commercial bulk mail. I'm not aware of any statistics available to the public. >Also, your mailing list would work again in a heartbeat, in a DMARC-world, if >you just configured them to put the original Header-From into the "description" >of a new Header-From, like: We are aware of the various kludges to circumvent DMARC breakage. We have a whole wiki about them at http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail Rehashing them here and asserting that they are solutions rather than kludges would not be productive. R's, John From nobody Sun Mar 22 15:37:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5861A6F39 for ; Sun, 22 Mar 2015 15:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.297 X-Spam-Level: ** X-Spam-Status: No, score=2.297 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_SPAM=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMGTs5f8q_Pb for ; Sun, 22 Mar 2015 15:37:06 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8F1A6F5D for ; Sun, 22 Mar 2015 15:37:05 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id D62818646 for ; Sun, 22 Mar 2015 23:37:03 +0100 (CET) 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; Sun, 22 Mar 2015 23:37:03 +0100 Message-ID: <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan> Date: Sun, 22 Mar 2015 23:37:22 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:37:08 -0000 On Sunday, March 22, 2015 9:25 PM [GMT+1=3DCET], John Levine wrote: > > But do you think the general email-using population will be happy > > to miss authentic email from eBay, Amazon, Paypal and American > > Airlines, just to get email from some mailing list(s) delivered to > > their inbox?=20 >=20 > My impression is that most users put a very low value on commercial > bulk mail. I'm not aware of any statistics available to the public. Authentic email from eBay, Amazon, Paypal and American Airlines may not = be "commercial bulk email." Instead, it can be email confiming the = success of important transactions, account break-in attempts, or = notifying changes in schedules, etc., and therefore be of very high = value to end-users. > > Also, your mailing list would work again in a heartbeat, in a > > DMARC-world, if you just configured them to put the original > > Header-From into the "description" of a new Header-From, like: >=20 > We are aware of the various kludges to circumvent DMARC breakage. We > have a whole wiki about them at > = http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail >=20 > Rehashing them here and asserting that they are solutions rather than > kludges would not be productive. You say that as if a solution that works but you don't like is not a = solution but a kludge. Internet Email is built on a pile of kludges = after kludges. It just wasn't designed to live as long as it has. Why is this kludge of a solution worst that the kludge of closing down = open email relays in the past? The disappearance of open email relays = surely affected badly several legitimate use cases of email... Regards, J.Gomez From nobody Sun Mar 22 22:38:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812C21A8850 for ; Sun, 22 Mar 2015 22:38: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 dZx7MfUO-QOp for ; Sun, 22 Mar 2015 22:38:36 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 03F011A882F for ; Sun, 22 Mar 2015 22:38:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 8883C1C386D; Mon, 23 Mar 2015 14:38:34 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6DE1A120EC9; Mon, 23 Mar 2015 14:38:34 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <550F0F42.8030008@dcrocker.net> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <87oankop0a.fsf@uwakimon.sk.tsukuba.ac.jp> <550F0F42.8030008@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 23 Mar 2015 14:38:34 +0900 Message-ID: <87fv8wnuhx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:38:37 -0000 Dave Crocker writes: > On 3/22/2015 1:39 PM, Stephen J. Turnbull wrote: > > I took you to mean that the relationship between the purported > > identity in From, based on the address in that field, and the user's > > behavior is irrelevant to specification of DMARC and related > > protocols. > > I didn't say that, but I'll say it now, too. (Ignoring the underying > truth that users get tricked, which provides the motivation for worrying > about spoofing.) Ignoring motivation was appropriate for Milestone 1, which was concerned with ensuring a lack of ambiguity in RFC 7489, which has a well-defined set of requirements. But we are now looking at "next steps", ie, a new set of requirements, because implementing the RFC 7489 requirements turned out to be insufficient to enable many use cases people participating in this WG care about, and to have some rather nasty side effects in combination with preexisting systems. I think discussion of motivation and agent (not limited to mail recipients) behavior is exactly what is needed at this stage, even if it's rather speculative and not founded in formal user interface research. From nobody Sun Mar 22 23:02:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA7B1A887D for ; Sun, 22 Mar 2015 23:02:43 -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 ArcvidLtOjj5 for ; Sun, 22 Mar 2015 23:02:42 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5F1A8872 for ; Sun, 22 Mar 2015 23:02:42 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id A8A291C3869; Mon, 23 Mar 2015 15:02:41 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8DDCD120EC9; Mon, 23 Mar 2015 15:02:41 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 23 Mar 2015 15:02:41 +0900 Message-ID: <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 06:02:43 -0000 J. Gomez writes: > > > But do you think the general email-using population will be happy > > > to miss authentic email from eBay, Amazon, Paypal and American > > > Airlines, just to get email from some mailing list(s) delivered to > > > their inbox? I don't see why enabling mailing lists to continue their traditional practice of adding tags to Subject and footers to the message body would cause any problems whatsoever for authentic direct mail from the businesses you mention. > You say that as if a solution that works but you don't like is not > a solution but a kludge. It is. A *solution* is a practice or product that satisfies user requirements. If there's only one such user, OK, you can say "tough on you." However, *many* mailing list users wish to have the author's address in "From" where it will be automatically and naturally used for reply-to-author in almost all MUAs. As far as I know there is no configuration of From and Reply-To that satisfies this requirement in all use cases. From nobody Mon Mar 23 01:16:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19D1A896E for ; Mon, 23 Mar 2015 01:15:59 -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 qn_0NKPcYpNY for ; Mon, 23 Mar 2015 01:15:58 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7771A8974 for ; Mon, 23 Mar 2015 01:15:57 -0700 (PDT) Received: by wixw10 with SMTP id w10so54336652wix.0 for ; Mon, 23 Mar 2015 01:15:56 -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=p0vwZSzeqfi0HUirq98y3uXMxlwG+qL1sdgTCkDKNpA=; b=zSlNU3Zwp9W+tOjI2Xq4saCGxcV+2+33PcOpq9Zqm9v6lwn+4ZdRlp74QdvJqjwUMB vcV2PBROaEw0SJiNMghYExkx10wBNlNs10ktvK4zEFw52dtKIISAQkUONYXu3FmwWelc HOKzy/p83fAjdvIZu5Ev1voCtYSNmRsEvKU1xH0xbf60nqiteZDnNpIjBdkABjQyEhJS LhbgvLHf23ik4wgyuayRM43gzzujNCUjOoXrG4R1WaZXFLCUz1Qy+7sUAsjbWrwcRDw9 rLudVGrPSbMPmUzuzRzi7vIy7ApdFbZhQgejAYWXyHUUSm0o4UAVJKsjRK/g0s/iRSsv hWew== MIME-Version: 1.0 X-Received: by 10.180.75.243 with SMTP id f19mr17061207wiw.94.1427098556387; Mon, 23 Mar 2015 01:15:56 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 23 Mar 2015 01:15:56 -0700 (PDT) In-Reply-To: <550E10C5.1070509@dcrocker.net> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> Date: Mon, 23 Mar 2015 01:15:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d0438951b8358100511f0465a Archived-At: Cc: Dave Crocker , "Stephen J. Turnbull" , "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 08:15:59 -0000 --f46d0438951b8358100511f0465a Content-Type: text/plain; charset=UTF-8 On Sat, Mar 21, 2015 at 5:45 PM, Dave Crocker wrote: > > > And note that without DMARC, these days users typically don't see > > > the domain. In other words, it isn't presented to the user. This > > > inconvenient fact is ignored or dismissed every time someone touts > > > the user's role in DMARC. > > > > What's so inconvenient about it? > > Folks tend to promote DMARC's choice of From field due to the fact that > it's presented to the end-user, as if the end-user will behave > differently with DMARC active. The end-user won't. They mostly don't > see the domain name, and it mostly doesn't matter when they do. > > On the other hand, the fact that the From field is the only domain name > reliably associated with content creation and that receiving filtering > engines can do an assessment of validity when DMARC validates, is > extremely meaningful. But there is no 'user' in the handling equation > for DMARC. > That's true, I suppose, but there are lots of components of a message system that don't include user input. Spam filters don't have user input but they do care about what gets past them, because their purpose is to identify and prevent delivery of things that are either annoying or deceptive. The user is most certainly the focus. I'm not disagreeing, but I'm not sure where you're going with this... -MSK --f46d0438951b8358100511f0465a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 21, 2015 at 5:45 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
>=C2=A0 > A= nd note that without DMARC, these days users typically don't see
>=C2=A0 > the domain.=C2=A0 In other words, it isn't presented to= the user. This
>=C2=A0 > inconvenient fact is ignored or dismissed every time someon= e touts
>=C2=A0 > the user's role in DMARC.
>
> What's so inconvenient about it?

Folks tend to promote DMARC's choice of From field due to the fa= ct that
it's presented to the end-user, as if the end-user will behave
differently with DMARC active.=C2=A0 The end-user won't.=C2=A0 They mos= tly don't
see the domain name, and it mostly doesn't matter when they do.

On the other hand, the fact that the From field is the only domain name
reliably associated with content creation and that receiving filtering
engines can do an assessment of validity when DMARC validates, is
extremely meaningful.=C2=A0 But there is no 'user' in the handling = equation
for DMARC.

That's true, I suppose, = but there are lots of components of a message system that don't include= user input.=C2=A0 Spam filters don't have user input but they do care = about what gets past them, because their purpose is to identify and prevent= delivery of things that are either annoying or deceptive.=C2=A0 The user i= s most certainly the focus.

I'm not disagreeing, but = I'm not sure where you're going with this...

-MSK=

--f46d0438951b8358100511f0465a-- From nobody Mon Mar 23 03:41:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CC91A8704 for ; Mon, 23 Mar 2015 03:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX4j2okgx74h for ; Mon, 23 Mar 2015 03:41:20 -0700 (PDT) Received: from nm22-vm7.bullet.mail.gq1.yahoo.com (nm22-vm7.bullet.mail.gq1.yahoo.com [98.136.217.70]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD111A870B for ; Mon, 23 Mar 2015 03:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427107280; bh=++VjgTEfnSsDrw8A1CXql1UXLL6OQfXoBYdeM6Al4kA=; h=Date:From:Reply-To:To:Subject:From:Subject; b=hKo2fvQVTkh5VVrTAuRpuf5XN2trWiGiTkbTTCpQldMfBewWDD1PuM81HDQg3JDPlBJPB3Y/z3ABururbncN1g9A1Fx/ZmFJ7mlulik6kswAg6WkpeV80IiatOStcMNW25GdrKXJtpd1NGb1xwQ/KJH/Q6eWWnCyquCmNXo8lz+fGs+2CCrrIz9ej/JO9wOWuIxylurC9au3f6PQRhUIWU0SMvLl4oI6A9lqmO5D1knYDqsBrJSdV3uHUEiuU3oqOAvWuf3z32NDvyXjqUFjA2Dh9Iua90mMoTjyxy+3Rr5snaUyvkIab4mwji7DqN9ENoqluTfkFgYUNgvvpSV7UA== Received: from [98.137.12.189] by nm22.bullet.mail.gq1.yahoo.com with NNFMP; 23 Mar 2015 10:41:20 -0000 Received: from [98.137.12.237] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 23 Mar 2015 10:41:20 -0000 Received: from [127.0.0.1] by omp1045.mail.gq1.yahoo.com with NNFMP; 23 Mar 2015 10:41:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 99469.67960.bm@omp1045.mail.gq1.yahoo.com X-YMail-OSG: 2CgLQcYVM1nGp1d_tkieUBIimxTma555GBBrCffC7kAHKtEp9vn9Mh2jSo546GP .ddtZ9rET0fIGeCf2651ffjVSkNpuVYd1E8_gNquEREkjifCALNyMFk1nR8c2DXa8YyzamjonrAK UTmyrrnhpjevhemrmAWNprlluRWAwFra7p3QLHWTRleK1DPfeZRoseOy8K4WRyJlik_ikcizKyRz G2z44VMOWOecLf4tqpg2bPogNnHj_Ax8uMMb2e.k5uIOmlFumx_enob_I9EwHTg9J.Ns1LGSUqGY 1yOxbhkOyHqEi6TleUJSehGYSNTmAYYyhjHWYVzVmMDNxI37OE0KrW.ITy0QHTvjedc9vtEXfm4B vApbESUwBuacBVEn4AxWFTFoj5.HMjZtB4SjZsDax9cnqp122Xv5323prTtsxEQhO0aDnB7HZ2zk ZyXtAuyUWcDPQDff4P0QFiYC4E3JXU5Fjxs39zQYaSMQL8rptmouKXxwyPr5BcB6pgohC14m6MXA q3KjTC0Xr7i7w0CBBupsT5v9lEO65YTKRoAyb9l4F0RZaWlFzeLEM_HgkmEgdNA-- Received: by 216.39.60.199; Mon, 23 Mar 2015 10:41:19 +0000 Date: Mon, 23 Mar 2015 10:40:32 +0000 (UTC) From: Vlatko Salaj To: "dmarc@ietf.org" Message-ID: <1247058811.307293.1427107232206.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] DMARC is a failure X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 10:41:22 -0000 from what i can see in all ur discussion, most of the essential goals for this wg are gonna fail. with very few exceptions, which i include myself into, nobody here is interested into expanding dmarc to actually encompass real-world email usage, but instead, most of participants are glorifying an obviously flawed protocol, or at very least, finding excuses for it, some pretty unbelievable. instead of working on actually functional 3rd party dmarc addons, what i read here is nothing of real consequence to anything. so, imo, dmarc failed on its promise. whoever wants to implement dmarc on their sending domains should just use p=none, and be done with it. and whoever wants to process dmarc on receiving email should just behave as if requested policy is p=none. and in most situations, that's exactly what's happening, when i review my data for last 1y. nobody wants to lose important email. i'm imagining a bank's usage scenario: dmarc affects ur brand's image when 1. legitimate email doesn't get delivered or, even worse, 2. ends up in spam folder. so, while u fight spoofing which end user will not see, u tarnish ur image, which end user will see. in the end, using dmarc, as a bank, u lose. while trying to fix end user's problem of acting on spoofed email, u essentially break ur own email system. i dare to assume that it's obvious to everybody by now - all that's gonna survive from dmarc are its reporting capabilities. so, i will just send an invitation to those who care to concentrate on dmarc's reporting capabilities, making them more robust, more detailed and much better at actually helping domain owners with deeper insights on unauthorized usage of their email addresses. that's all that dmarc can do for us in present state, and, it seems, in any future version too. if it wasn't such a bureaucrat's waste of time, i would propose a change in wg's milestones, pushing for additional work on reporting capabilities. but, alas, i have no such time. i guess we should all wait for next generation of email engineers to get a fully functional email protection protocol, cause the thinking that's currently in the void is not getting us anywhere exactly. it's all about fixes for yesteryear that break something else today, over fixes of old that broke something else yesterday, while waiting for fixes for today that will break something else tomorrow. and malicious activity still thrives. -- Vlatko Salaj aka goodone goodone.tk From nobody Mon Mar 23 05:14:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8171A87D5 for ; Mon, 23 Mar 2015 05:14: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 g_d3UtJA5L9d for ; Mon, 23 Mar 2015 05:14:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59ED61A8793 for ; Mon, 23 Mar 2015 05:14:27 -0700 (PDT) Received: from [172.20.6.94] (rrcs-71-41-251-196.sw.biz.rr.com [71.41.251.196]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2NCEJs2019459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 05:14:23 -0700 Message-ID: <55100395.4060003@dcrocker.net> Date: Mon, 23 Mar 2015 07:14:13 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Mar 2015 05:14:23 -0700 (PDT) Archived-At: Cc: Dave Crocker , "Stephen J. Turnbull" , "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) 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: Mon, 23 Mar 2015 12:14:29 -0000 On 3/23/2015 3:15 AM, Murray S. Kucherawy wrote: > I'm not disagreeing, but I'm not sure where you're going with this... As always, I'm seeking to have thinking and discussion focus on software behavior, not user behavior. Any discussion of end user perception or behavior is distracting to meaningful analysis or development of technologies like DMARC. At a minimum, a reference to users tends to cause people to project benefits that will not accrue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Mar 23 07:27:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A15A1A8AAA for ; Mon, 23 Mar 2015 07:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B7gcKd_2eWa for ; Mon, 23 Mar 2015 07:27:30 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id E76EB1A8A8F for ; Mon, 23 Mar 2015 07:27:29 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 8EEDE5644A9 for ; Mon, 23 Mar 2015 09:27:29 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 81DDCA04F6 for ; Mon, 23 Mar 2015 09:27:29 -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 ZnScxNV5WoEQ for ; Mon, 23 Mar 2015 09:27:29 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 27BC4A04F5 for ; Mon, 23 Mar 2015 09:27:29 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 27BC4A04F5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427120849; bh=oWLSmqXxyC+YVoZBVD33z7g3zsvit5te4yQQyMPyw1E=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Wg668IiEdvfviwAg5XOVxcy50xrxHz7+qSd7SdHv0OrOFQGFEUWQKVXZ3zzw+1O++ uIpyVmdmJv6vjYqPwyDJAl5qIIK3TeP7RiPT2pGOCGMqqMeR+lwIr9YumurvnfiKkP R7O0mjqEPkB6y7iY9rSPkJqxR4icXe+H3Ikrp1h4= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0832CA04F6 for ; Mon, 23 Mar 2015 09:27:29 -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 E9zQSs08iUAs for ; Mon, 23 Mar 2015 09:27:28 -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 DA331A04F5 for ; Mon, 23 Mar 2015 09:27:28 -0500 (CDT) Date: Mon, 23 Mar 2015 09:27:28 -0500 (CDT) From: Franck Martin To: dmarc Message-ID: <341743611.12421.1427120848801.JavaMail.zimbra@peachymango.org> In-Reply-To: <905729822.12380.1427120800921.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-ietf-dmarc-interoperability-01.txt Thread-Index: XyIsGV/qSDA3WJ3ThXJDOaxNdNVurQ== Archived-At: Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Mar 2015 14:27:31 -0000 Looking better... Special thanks to Elizabeth for improving the document after I integrated (all?) previous comments. Please see this revision and post comments/reviews against it. Thanks. A new version of I-D, draft-ietf-dmarc-interoperability-01.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Name: draft-ietf-dmarc-interoperability Revision: 01 Title: Interoperability Issues Between DMARC and Indirect Email Flows Document date: 2015-03-20 Group: dmarc Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperability-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ Htmlized: http://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-01 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages originate from third party sources, are modified in transit, or are forwarded enroute to their final destination. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 23 08:07:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30AF1A8AB5; Mon, 23 Mar 2015 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPxkwzmYoXW6; Mon, 23 Mar 2015 07:16:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 694961A8AB8; Mon, 23 Mar 2015 07:15:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323141556.8501.47286.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 07:15:56 -0700 Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 08:06:57 -0700 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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, 23 Mar 2015 14:16:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Filename : draft-ietf-dmarc-interoperability-01.txt Pages : 19 Date : 2015-03-23 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages originate from third party sources, are modified in transit, or are forwarded enroute to their final destination. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 23 13:08:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5222D1AD0B1 for ; Mon, 23 Mar 2015 13:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odoFONvxkr6G for ; Mon, 23 Mar 2015 13:08:15 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 152EE1A016C for ; Mon, 23 Mar 2015 13:07:59 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2NK7ta7000597 for ; Mon, 23 Mar 2015 16:07:55 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2NK7smZ030835 for ; Mon, 23 Mar 2015 16:07:54 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: "dmarc@ietf.org" In-reply-to: Your message of Mon, 23 Mar 2015 07:14:13 CDT References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Mon, 23 Mar 2015 16:07:54 -0400 Message-ID: <30834.1427141274@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-23 16:07:55 EDT Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:08:17 -0000 Dave Crocker writes: > As always, I'm seeking to have thinking and discussion focus > on software behavior, not user behavior. > > Any discussion of end user perception or behavior is distracting to > meaningful analysis or development of technologies like DMARC. I can't entirely agree, though I'm not without sympathy to your point of view. DMARC is obviously intended to be applied by the software, and it's tempting to think that the message is either accepted or rejected, end of story, so this shouldn't affect the user interface or user behaviour. In practice I don't think it's that simple. Of course, because of the way DMARC is applied (in the DNS) and messages are signed (by the ISP), the sending user is not of concern here. The expressed concerns center on the perceptions and behaviour of the receiving user. If p=none (or if DMARC is not used), then the receiving user gets the message (modulo other de-spamming techniques), but nothing can be implied about its authenticity, so nothing changes with respect to the non-DMARC behaviour (of the software or the user!). And if the message is rejected due to p=reject, then the user never gets the message at all, so we needn't be concerned with the receiving user's behaviour. But if the message is delivered, either because it passes DMARC, or it fails but is "quarantined", then the receiver will see the message, and will make assumptions regarding the authenticity of its origin based, most likely, on the "From:" header. It seems not unreasonable to suppose that the writer of a user interface would want to indicate somehow to the user that the message was (or was not) vetted as coming from where it says it came from. The DMARC results seem like an obvious source of information for such an indication. One could argue, I suppose, that once again we're talking about the behaviour of software, but the point of all this, unless I woefully misunderstand, is to protect the user from fraud due to the faked provenance of a message. I don't think it will ever be the case that we can sort 100% of messages as "authentic" or "fake" before they reach the user; we have to accept that even if we block the "known fakes" based on DMARC, there will still be authenticated and not-checkable messages that reach the user - and ideally we'd have a way to indicate which are which. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Mon Mar 23 13:23:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570EA1A03D5 for ; Mon, 23 Mar 2015 13:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVfsvenGPYgX for ; Mon, 23 Mar 2015 13:23:29 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D1E1ACC87 for ; Mon, 23 Mar 2015 13:23:28 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 16:23:27 -0400 From: "MH Michael Hammer (5304)" To: Anne Bennett , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Thread-Index: AQHQYcyPcrrs7iHzJUmAQ3HxMcQrhJ0jKLwAgAFTRoCAAdHyAIAAgUGAgABcxYCAAD8fAIAAh3qAgAIQDgCAAEKTgIAAQWz3gAAA97A= Date: Mon, 23 Mar 2015 20:23:27 +0000 Message-ID: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> In-Reply-To: <30834.1427141274@vindemiatrix.encs.concordia.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:23:31 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Anne Bennett > Sent: Monday, March 23, 2015 4:08 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) >=20 >=20 > Dave Crocker writes: >=20 > > As always, I'm seeking to have thinking and discussion focus on > > software behavior, not user behavior. > > > > Any discussion of end user perception or behavior is distracting to > > meaningful analysis or development of technologies like DMARC. >=20 > I can't entirely agree, though I'm not without sympathy to your point of = view. > DMARC is obviously intended to be applied by the software, and it's > tempting to think that the message is either accepted or rejected, end of > story, so this shouldn't affect the user interface or user behaviour. In > practice I don't think it's that simple. >=20 >=20 > Of course, because of the way DMARC is applied (in the DNS) and messages > are signed (by the ISP), the sending user is not of concern here. The > expressed concerns center on the perceptions and behaviour of the > receiving user. Messages can be (DKIM) signed by any entity that handles the messages in qu= estion, not just by an ISP. Aligned (DKIM) signing can only be done with th= e permission of the domain owner/administrator. Messages may be unsigned an= d validated on the basis of SPF.=20 >=20 > If p=3Dnone (or if DMARC is not used), then the receiving user gets the > message (modulo other de-spamming techniques), but nothing can be > implied about its authenticity, so nothing changes with respect to the no= n- > DMARC behaviour (of the software or the user!). >=20 Certainly something can be implied about its authenticity. All p=3Dnone say= s is don't apply policy to the validation. > And if the message is rejected due to p=3Dreject, then the user never get= s the > message at all, so we needn't be concerned with the receiving user's > behaviour. >=20 Sure we can - if it's a false positive for an expected message and it never= arrives. The receiving user's behavior !=3Dhappiness. > But if the message is delivered, either because it passes DMARC, or it fa= ils > but is "quarantined", then the receiver will see the message, and will ma= ke > assumptions regarding the authenticity of its origin based, most likely, = on the > "From:" header. It seems not unreasonable to suppose that the writer of = a > user interface would want to indicate somehow to the user that the messag= e > was (or was not) vetted as coming from where it says it came from. > The DMARC results seem like an obvious source of information for such an > indication. >=20 DMARC addresses only the specific case of direct domain abuse. If I go out = and register the domain concordia.co and I send messages from anne@encs.con= cordia.co to targeted recipients with SPF/DKIM/DMARC properly configured, d= o you really want to give a trust indicator to those end users based on mes= sages passing DMARC? Presumably Concordia.co would ultimately end up on a b= lock list but would you really want to give trust indicators in the interim= ? > One could argue, I suppose, that once again we're talking about the > behaviour of software, but the point of all this, unless I woefully > misunderstand, is to protect the user from fraud due to the faked > provenance of a message. I don't think it will ever be the case that we = can > sort 100% of messages as "authentic" or "fake" before they reach the user= ; > we have to accept that even if we block the "known fakes" based on > DMARC, there will still be authenticated and not-checkable messages that > reach the user - and ideally we'd have a way to indicate which are which. >=20 >=20 >=20 > Anne. > -- > Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal > H3G 1M8 > anne@encs.concordia.ca +1 514 848-2424= x2285 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Mar 23 13:42:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ABE1B2A05 for ; Mon, 23 Mar 2015 13:42:18 -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 Ye-EyNbx4AQX for ; Mon, 23 Mar 2015 13:42:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE7F1A0060 for ; Mon, 23 Mar 2015 13:42:14 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2NKfh0c002582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 13:41:47 -0700 Message-ID: <55107A81.6000702@dcrocker.net> Date: Mon, 23 Mar 2015 15:41:37 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anne Bennett , "dmarc@ietf.org" References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> In-Reply-To: <30834.1427141274@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Mar 2015 13:41:47 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) 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: Mon, 23 Mar 2015 20:42:18 -0000 Anne, On 3/23/2015 3:07 PM, Anne Bennett wrote: > But if the message is delivered, either because it passes DMARC, > or it fails but is "quarantined", then the receiver will see the > message, and will make assumptions regarding the authenticity of > its origin based, most likely, on the "From:" header. It seems Unfortunately, user references for this sort of work have no productive use to that work, but instead often prove counter-productive. You make an assumption about user assumptions. Forgive me, but I doubt you have a reliable, objective, empirical basis for making that assertion or much that derives from it. In fact there's a reasonable chance that your assumption is flawed. That's why I keep stressing the importance of keeping user references out of these discussions. They are not helpful to the work and they are distracting. > not unreasonable to suppose that the writer of a user interface > would want to indicate somehow to the user that the message was > (or was not) vetted as coming from where it says it came from. > The DMARC results seem like an obvious source of information > for such an indication. "Not unreasonable' is a common justification for UI design choices. The reality of successful UI design is that many choices that are "not unreasonable" don't work or work poorly. Consequently, "not unreasonable" is a singularly insufficient justification. At the very best, it can serve to provide input to experimental processes that investigate actual efficacy. > One could argue, I suppose, that once again we're talking > about the behaviour of software, but the point of all this, > unless I woefully misunderstand, is to protect the user from > fraud due to the faked provenance of a message. As a very general mission statement -- or an even higher-level motivator for working in this space -- perhaps, but that has essentially no effect on design choices here. In practical and operational terms, the point of all this is to allow filtering engines to make better decisions about possibly-spoofed mail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Mar 23 14:13:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BFB1A1AB9 for ; Mon, 23 Mar 2015 14:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUlh1tNvcIuH for ; Mon, 23 Mar 2015 14:13:06 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id D15FF1A1AB6 for ; Mon, 23 Mar 2015 14:13:04 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 248058640 for ; Mon, 23 Mar 2015 22:12:55 +0100 (CET) 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; Mon, 23 Mar 2015 22:12:54 +0100 Message-ID: <11B0614056784A5F816F99A3C1E46B13@fgsr.local> From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 23 Mar 2015 22:13:11 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:13:09 -0000 On Monday, March 23, 2015 7:02 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > > > But do you think the general email-using population will be > > > > happy to miss authentic email from eBay, Amazon, Paypal and > > > > American Airlines, just to get email from some mailing list(s) > > > > delivered to their inbox? >=20 > I don't see why enabling mailing lists to continue their traditional > practice of adding tags to Subject and footers to the message body > would cause any problems whatsoever for authentic direct mail from the > businesses you mention. Verifiable authenticity of email greatly depends on DMARC's success. = Because without DMARC's success the authenticity of email can only be = verified heuristically and not systematically. If mailing-lists configured old-style hinder the adoption and ultimate = success of DMARC, then received email will not be able to be verified as = authentic in any systematic way, but only heuristically. That greatly = lessens the value of email as a viable medium for important[*] = communications that users want to receive. [*] I define here "important" as: "potentially expensive for the user if = missed and/or potentially expensive for the user if successfully = spoofed". Therefore, as per the above reasoning, given that the "traditional = practice of mailing lists adding tags to Subject and footers to the = message body" breaks DMARC, it is also breaking the mechanism (DMARC) = which could take email to the next level as a viable medium for = important communications. I vote for steam-rolling mailing lists configured old-style to the = history books. Mailing list operators just need to take ownership in the = Header-From for the messages whose DKIM signature they break, and all is = back to working great again! > > You say that as if a solution that works but you don't like is not > > a solution but a kludge. >=20 > It is. A *solution* is a practice or product that satisfies user > requirements. If there's only one such user, OK, you can say "tough > on you." However, *many* mailing list users wish to have the author's > address in "From" where it will be automatically and naturally used > for reply-to-author in almost all MUAs. As far as I know there is no > configuration of From and Reply-To that satisfies this requirement in > all use cases. Well, I posit the user requirement is, at large, to take email to the = next level a viable medium for important communications. Regards, J.Gomez From nobody Mon Mar 23 14:45:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C01B2AB6 for ; Mon, 23 Mar 2015 14:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5njZ9_XhzVPK for ; Mon, 23 Mar 2015 14:45:53 -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 058231B2AB5 for ; Mon, 23 Mar 2015 14:45:52 -0700 (PDT) Received: (qmail 2212 invoked from network); 23 Mar 2015 21:45:52 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 23 Mar 2015 21:45:52 -0000 Date: 23 Mar 2015 21:45:30 -0000 Message-ID: <20150323214530.39217.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <11B0614056784A5F816F99A3C1E46B13@fgsr.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:45:53 -0000 >Verifiable authenticity of email greatly depends on DMARC's success. Because without >DMARC's success the authenticity of email can only be verified heuristically and not >systematically. Rehashing old arguments will not change anyone's mind. False assertions are like these are utterly useless. Please stop. R's, John From nobody Mon Mar 23 14:57:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFDE1A1B8F for ; Mon, 23 Mar 2015 14:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW2bgJt30j9j for ; Mon, 23 Mar 2015 14:57:01 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 195D21A1B67 for ; Mon, 23 Mar 2015 14:57:01 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 3F3DF84BC for ; Mon, 23 Mar 2015 22:57:00 +0100 (CET) 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; Mon, 23 Mar 2015 22:56:59 +0100 Message-ID: <6C6CB26661A74BDD8DCF3A431009CEA8@fgsr.local> From: "J. Gomez" To: References: <20150323214530.39217.qmail@ary.lan> Date: Mon, 23 Mar 2015 22:57:17 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:57:02 -0000 On Monday, March 23, 2015 10:45 PM [GMT+1=3DCET], John Levine wrote: > > Verifiable authenticity of email greatly depends on DMARC's > > success. Because without DMARC's success the authenticity of email > > can only be verified heuristically and not systematically. >=20 > Rehashing old arguments will not change anyone's mind. False > assertions are like these are utterly useless. >=20 > Please stop. To castle into old denial will not change anyone's mind, either. But please, go on. Regards, J. Gomez From nobody Mon Mar 23 17:25:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8B1A90CF for ; Mon, 23 Mar 2015 17:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFDqCrMfzgQx for ; Mon, 23 Mar 2015 17:25:16 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3224F1A90CB for ; Mon, 23 Mar 2015 17:25:16 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so136047478obc.0 for ; Mon, 23 Mar 2015 17:25:15 -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=F4Sssh/pCZZfi/95dtGqJto9RyIwtjFNLtijyMJa4uQ=; b=GuCVYpmlGEY0iC8cNwao+fVl/HGyxRYmb93RzZ1IWnLlXfEXH//p0zs9dFusVR5X6q Y3KMpzv7SB4DYWeA96N5w/yGFnE3+RECEKh4bJDE/BBcZ7S17FWO3RTzj7hCP8uv0I38 fOpd5v3cwsEt46aXcLE8Wh84FwcTPXbV2+boxc5ondfCD04DXNQutBqbDyUI5eavLJpM 0fvU2Uy/wEoXIRhiyfnSrA0WQ1TW55tQVdS/7zQzge2dyn68gnBhApW9rOb7kp7mI1gm COj/XuvXix9Nra+x26HHXpJKaH6zdfOCT7HULANuNUs2NK+3CpR4g6dW09evPiUYHpj9 miMg== 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=F4Sssh/pCZZfi/95dtGqJto9RyIwtjFNLtijyMJa4uQ=; b=OstHXLJl0EEnuCL4atXJoDSHn0HGOfM41xNVfPRbm4qdoG01UocV0w6XImfK97hcJl a/+syJ+Cxs6B3kxWwgO6khOZA4kOcR3T0q/SkLyKgLT5zARv8E74t5diewfl909IUq03 iHggtPfQ5LxWD2LMmsU8UOni5eDSad6wsEZzzgDlTIp8/RMIxCFpo5tpIwGAB2CrMxYk yZ4QcC/1degiHpJc4hCMpn2wRXtgcOzygVE+WM5Afa+gwcvZ+9iKzmkcEE62JPtlaiE+ vzP3wWfoo0jM3o6zsCIaaGARNORaiorzdt46jRRVmDjKGLidkLshNMm3mZslZmvLuKK/ USCw== X-Gm-Message-State: ALoCoQn0mMKwCVHwDC/HDFA55IPSBA0hsmn/jsIKnUXjqMt66CbSCs3/w+TpKSeavG4qmsP4jWxs MIME-Version: 1.0 X-Received: by 10.60.84.144 with SMTP id z16mr1395675oey.32.1427156715639; Mon, 23 Mar 2015 17:25:15 -0700 (PDT) Received: by 10.202.98.85 with HTTP; Mon, 23 Mar 2015 17:25:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 17:25:15 -0700 Message-ID: From: John Bucy To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e011825ec1343db0511fdd1a2 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 00:25:17 -0000 --089e011825ec1343db0511fdd1a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Based on a quick glance, it doesn't look like draft-kucherawy-dkim-list-canon-00 addresses encoded headers like rfc2047. An mta could opt to send a message with unencoded utf8 headers (display name, subject, etc) to another peer advertising SMTPUTF8 even if none of the envelope were internationalized addresses. If the recipient then needed to relay the message on to a site that didn't support SMTPUTF8, it would have to encode the headers. On Fri, Mar 20, 2015 at 11:33 AM, Murray S. Kucherawy wrote: > Not yet. I don't think there are any implementations. We were just > banging the idea around. I'm looking at doing one soon for OpenDKIM as an > experimental add-on. > > On Fri, Mar 20, 2015 at 10:25 AM, John Bucy wrote: > >> Hadn't seen that ID, cool! Is there any test data available? >> >> >> >> cheers >> john >> >> On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy > > wrote: >> >>> There was one proposed: >>> >>> https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 >>> >>> This working group will be discussing this and other options before long. >>> >>> -MSK >>> >>> >>> On Thu, Mar 19, 2015 at 1:45 PM, John Bucy wrote: >>> >>>> I was glad to see mention of content-transfer-encoding issues >>>> in draft-ietf-dmarc-interoperability since gateway-transformation breaks >>>> dkim signatures. Is there any interest in trying to develop a mime-aware >>>> canonicalization for dkim? >>>> >>>> >>>> >>>> cheers >>>> john >>>> >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> >>>> >>> >> > --089e011825ec1343db0511fdd1a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Based on a quick glance, it doesn't look like draft-kucherawy-dkim-list-canon-00 addresses encoded headers like rfc2047. An mta could opt to send a message with unencoded utf8 headers (display name, subject, etc) to another peer advertising SMTPUTF8 even if none of the envelope were internationalized addresses. If the recipient then needed to relay the message on to a site that didn't support SMTPUTF8, it would have to encode the headers.

On Fri, Mar 20, 2015 at 11:33 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Not yet. I don't think there are any implementations.  We were just banging the idea around.  I'm looking at doing one soon for OpenDKIM as an experimental add-on.

On Fri, Mar 20, 2015 at 10:25 AM, John Bucy <jbucy@google.com> wrote:
Hadn't seen that ID, cool! Is there any test data available?



cheers
john

On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
This working group will be discussing this and other options before long.

-MSK


On Thu, Mar 19, 2015 at 1:45 PM, John Bucy <jbucy@google.com> wrote:
I was glad to see mention of content-transfer-encoding issues in draft-ietf-dmarc-interoperability since gateway-transformation breaks dkim signatures. Is there any interest in trying to develop a mime-aware canonicalization for dkim?



cheers
john

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





--089e011825ec1343db0511fdd1a2-- From nobody Mon Mar 23 17:54:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F75E1ACEF9 for ; Mon, 23 Mar 2015 17:54: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 0i9hXSd_JGRe for ; Mon, 23 Mar 2015 17:54:23 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 24AAA1ACE3B for ; Mon, 23 Mar 2015 17:54:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E48711C3868; Tue, 24 Mar 2015 09:54:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A7721120EC9; Tue, 24 Mar 2015 09:54:21 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <11B0614056784A5F816F99A3C1E46B13@fgsr.local> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 24 Mar 2015 09:54:21 +0900 Message-ID: <87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 00:54:25 -0000 J. Gomez writes: > Verifiable authenticity of email greatly depends on DMARC's > success. Because without DMARC's success the authenticity of email > can only be verified heuristically and not systematically. This is an error of logic. *Authenticity* (defined as "did the message satisfy DMARC From alignment when injected?") of *each* message *can* be verified independently of other messages, and if From alignment is verified, the message *is* authentic (modulo black helicopters with 4096-bit encryption breaking equipment). It's what to think about non-verifiable mail that becomes unclear. Since the "important" mail is direct mail, From alignment will be preserved until received by the addressee. Therefore list behavior only affects DMARC verifiability of list traffic, *not* those other mail flows, as far as I can see. > Well, I posit the user requirement is, at large, to take email to > the next level a viable medium for important communications. I understand what you're saying, and we all agree that email as we currently know it has an important role for Internet communication, and that for it to continue to fulfill that role we need to improve its security in several ways. But (as Dave Crocker is emphasizing in another subthread), we need to be very careful to define requirements in terms of what the software can do, and then do our best to define and implement protocols that satisfy the requirements and *prove* that the software does satisfy those requirements. The "requirement" you propose is not implementable in a software system alone, whether it is satisfied or not cannot be verified from the behavior of software alone, and therefore cannot be posited as a requirement in the sense used in software engineering. Please think about what I've written. It's a very useful way to think about software systems, and IETF discussions are normally phrased using this kind of language. If you don't use it, people will not know what you're talking about, and your ideas will not be picked up. Steve From nobody Mon Mar 23 20:44:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF511B2C40 for ; Mon, 23 Mar 2015 20:44: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 WFt96ZhubyTH for ; Mon, 23 Mar 2015 20:44:11 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB9B1B2C3E for ; Mon, 23 Mar 2015 20:44:11 -0700 (PDT) Received: by weop45 with SMTP id p45so153349868weo.0 for ; Mon, 23 Mar 2015 20:44:10 -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=JyyvpTPtGVVsR1PbnaASTeNmh70kurOQKYPNol/gKno=; b=O4gOew/5tZG/KUoNX9vQvt8HcbaKKgebelYwr4YuJ2XgzDZIdqeMRDU1yDWCoGFD1p aJfukD6pfYxhXeRl5NqKx7Nkalypeto2Rw9ocL8Fa9iLpwExgFJ+ja49D87SScD5dqww TuF5mz+pOnbySr8M1xgPFqU2aGUSIdPiQ7pAHI9rdzx23dfeU4UBkOw1PcxaDtKMax5Y b6QH2bmSm+yZQVnhSRUmRDRWhDIAwEYtPg+GXHFgkhD97gSOcMfFr8hLpePIfQ/2ahMC UBCnFrc91nqdixg43RlU5Wc+MDr7FLfeM3x7iudlCiOjUyVQXwiooDifXNsXKxe92Qh/ /ZaQ== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr25228315wix.52.1427168650304; Mon, 23 Mar 2015 20:44:10 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 23 Mar 2015 20:44:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 20:44:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Bucy Content-Type: multipart/alternative; boundary=f46d044289e86fa3a40512009896 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 03:44:13 -0000 --f46d044289e86fa3a40512009896 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 5:25 PM, John Bucy wrote: > Based on a quick glance, it doesn't look like > draft-kucherawy-dkim-list-canon-00 addresses encoded headers like rfc2047. > An mta could opt to send a message with unencoded utf8 headers (display > name, subject, etc) to another peer advertising SMTPUTF8 even if none of > the envelope were internationalized addresses. If the recipient then needed > to relay the message on to a site that didn't support SMTPUTF8, it would > have to encode the headers. > You're right, it doesn't. It's only meant to address body modifications that lists might do. In fact it is specifically a body canonicalization. I hadn't done any work on list-sensitive header canonicalization yet. Do you have a suggestion in mind? -MSK --f46d044289e86fa3a40512009896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 23, 2015 at 5:25 PM, John Bucy <jbucy@google.c= om> wrote:
Based on a quick gla= nce, it doesn't look like draft-kucherawy-dkim-list-canon-00 addresses = encoded headers like rfc2047. An mta could opt to send a message with unenc= oded utf8 headers (display name, subject, etc) to another peer advertising = SMTPUTF8 even if none of the envelope were internationalized addresses. If = the recipient then needed to relay the message on to a site that didn't= support SMTPUTF8, it would have to encode the headers.
<= div>
You're right, it doesn't.=C2=A0 It's only me= ant to address body modifications that lists might do.=C2=A0 In fact it is = specifically a body canonicalization.=C2=A0 I hadn't done any work on l= ist-sensitive header canonicalization yet.

Do you have a = suggestion in mind?

-MSK
--f46d044289e86fa3a40512009896-- From nobody Tue Mar 24 05:15:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664D1B2E4E for ; Tue, 24 Mar 2015 05:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ui2eiCXL9eV for ; Tue, 24 Mar 2015 05:15:40 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 86C731B2CB7 for ; Tue, 24 Mar 2015 05:15:40 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 168F484BC for ; Tue, 24 Mar 2015 13:15:37 +0100 (CET) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 24 Mar 2015 13:15:36 +0100 Message-ID: <102A355F80204C6C8F84DAECDA118C2E@fgsr.local> From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local> <87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 13:15:52 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 12:15:43 -0000 On Tuesday, March 24, 2015 1:54 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > Verifiable authenticity of email greatly depends on DMARC's > > success. Because without DMARC's success the authenticity of email > > can only be verified heuristically and not systematically. >=20 > This is an error of logic. *Authenticity* (defined as "did the > message satisfy DMARC From alignment when injected?") of *each* > message *can* be verified independently of other messages, and if From > alignment is verified, the message *is* authentic (modulo black > helicopters with 4096-bit encryption breaking equipment). It's what > to think about non-verifiable mail that becomes unclear. I think we are not talking about the same thing: when I said "depends on = DMARC's success", I meant "depends on DMARC's success as an implemented = technology in the real world", whereas it seems you understood "depends = on a successful DMARC check". So I say it again, now in fully qualified terms: Verifiable authenticity = of email greatly depends on DMARC's success as an implemented technology = in the real world. > Since the "important" mail is direct mail, From alignment will be > preserved until received by the addressee. Therefore list behavior > only affects DMARC verifiability of list traffic, *not* those other > mail flows, as far as I can see. I explain: if mailing-lists configured old-style keep DMARC from being a = success in the real world, then mailing-lists are hindering the extra = notch of trustworthiness that DMARC could bring to important email = communications for end users as a whole. So it's not about individual = messages, as you seem to be talking about, but about the big picture. And it is that big picture which is begging for mailing-lists operators = to abandon their old-style practices and to begin to take ownership in = the Header-From of the email they relay and modify while in-flight = rendering its original DKIM signature invalid. > The "requirement" you propose is not implementable in a software > system alone, whether it is satisfied or not cannot be verified from > the behavior of software alone, and therefore cannot be posited as a > requirement in the sense used in software engineering. I know that DMARC is not the silver bullet. That's way I said it "brings = an extra notch of trustworthiness" to email, I didn't say DMARC brings = final and ultimate trustworthiness. Regards, J.Gomez From nobody Tue Mar 24 08:17:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E41A889C for ; Tue, 24 Mar 2015 08:17:57 -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 I6mXeJoJ6GuH for ; Tue, 24 Mar 2015 08:17:49 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D71A87D2 for ; Tue, 24 Mar 2015 08:17:49 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id F128A1C38CE; Wed, 25 Mar 2015 00:17:47 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D360C120EC9; Wed, 25 Mar 2015 00:17:47 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 00:17:47 +0900 Message-ID: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:17:57 -0000 Murray S. Kucherawy writes: > On Mon, Mar 23, 2015 at 5:25 PM, John Bucy wrote: > > An mta could opt to send a message with unencoded utf8 headers (display > > name, subject, etc) to another peer advertising SMTPUTF8 even if none of > > the envelope were internationalized addresses. If the recipient then needed > > to relay the message on to a site that didn't support SMTPUTF8, it would > > have to encode the headers. > You're right, it doesn't. AFAICS use of the SMTPUTF8 extension is incompatible with DKIM signatures. See sec. 5.3 of RFC 6376. > Do you have a suggestion in mind? Conform to RFC 6376. From nobody Tue Mar 24 08:40:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DBD1A8981 for ; Tue, 24 Mar 2015 08:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB_pfJraorb4 for ; Tue, 24 Mar 2015 08:40:27 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id ED9B31A89A8 for ; Tue, 24 Mar 2015 08:40:21 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 7DB5A564310; Tue, 24 Mar 2015 10:40:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 733D5602C5; Tue, 24 Mar 2015 10:40:21 -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 LiOLaliKN8ys; Tue, 24 Mar 2015 10:40:17 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 30D10602D4; Tue, 24 Mar 2015 10:40:17 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 30D10602D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427211617; bh=+LIG4OzHvtL96Mhtawofw0hbYPk/Vls5w0yNqzlLdnQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=nRoLixQ78CyWsZmqdxhp2VkqdhSjqcwL5k/wv5CFGdD8/4deeMRgwAkFr+xkujK1I eWU1F8ObVq+Hq9tc33imWO3KwIqxlYBYFbUH4Lu+kqgnhI+f4a2eVuf5UCG2M5cXPA 9kFQCqEMKr7Jw/76aaHj5/mRfo4MpjNPJySLv5QU= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1F2F1602CF; Tue, 24 Mar 2015 10:40:17 -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 us6isOurqCMo; Tue, 24 Mar 2015 10:40:17 -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 E835A602CD; Tue, 24 Mar 2015 10:40:16 -0500 (CDT) Date: Tue, 24 Mar 2015 10:40:15 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <1341627120.41703.1427211615945.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: interoperability issues around gateway-transformation Thread-Index: NgSvHT8QcOLLuormY/z3D2dM3KrZnA== Archived-At: Cc: dmarc@ietf.org, "Murray S. Kucherawy" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:40:29 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Murray S. Kucherawy" > Cc: dmarc@ietf.org, "John Bucy" > Sent: Tuesday, March 24, 2015 8:17:47 AM > Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation > > Murray S. Kucherawy writes: > > On Mon, Mar 23, 2015 at 5:25 PM, John Bucy wrote: > > > > An mta could opt to send a message with unencoded utf8 headers (display > > > name, subject, etc) to another peer advertising SMTPUTF8 even if none of > > > the envelope were internationalized addresses. If the recipient then > > > needed > > > to relay the message on to a site that didn't support SMTPUTF8, it would > > > have to encode the headers. > > > You're right, it doesn't. > > AFAICS use of the SMTPUTF8 extension is incompatible with DKIM > signatures. See sec. 5.3 of RFC 6376. > Luckily in RFC6376 there is: "More generally, the Signer MUST sign the message as it is expected to be received by the Verifier rather than in some local or internal form." and RFC6531 says (3.2): "If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers" "If it is not an MSA or is an MSA and does not choose to transform the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message." So in the case above, the MTA should not attempt to convert the message and just bounce it. From nobody Tue Mar 24 09:00:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EF21A9023 for ; Tue, 24 Mar 2015 09:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfOmjY2sYUnI for ; Tue, 24 Mar 2015 08:59:58 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8C93C1B2E59 for ; Tue, 24 Mar 2015 08:59:23 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2OFxMQK015593 for ; Tue, 24 Mar 2015 11:59:22 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2OFxLat003263 for ; Tue, 24 Mar 2015 11:59:21 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: "dmarc@ietf.org" In-reply-to: Your message of Mon, 23 Mar 2015 15:41:37 CDT References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 24 Mar 2015 11:59:21 -0400 Message-ID: <3262.1427212761@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-24 11:59:22 EDT Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:00:00 -0000 Dave, > You make an assumption about user assumptions. Forgive me, but I doubt > you have a reliable, objective, empirical basis for making that > assertion or much that derives from it. In fact there's a reasonable > chance that your assumption is flawed. I have a 24-year-long parade of users worried that their account was compromised because they're receiving bounces for spam they never sent, wondering why their best friend is suddenly sending them ads or malware, or responding to phish messages. In the first two cases, they believe the "From:" header when they shouldn't; in the last case, too often they don't even look at the domain in the From: header. I haven't kept incident stats, so I cannot give you data that we could reliably use to measure the likely effectiveness of one approach or another, but my experience is objective and empirical, in the sense of having been "acquired by means of observation or experimentation". But we're straying from the topic, which is indeed to come up with technical specs that software can obey. Having said that: >> One could argue, I suppose, that once again we're talking >> about the behaviour of software, but the point of all this, >> unless I woefully misunderstand, is to protect the user from >> fraud due to the faked provenance of a message. > > As a very general mission statement -- or an even higher-level motivator > for working in this space -- perhaps, but that has essentially no effect > on design choices here. If "the point of all this" has "essentially no effect on design choices", we have a serious problem. It's all very well do do things right, but we have to make sure we're doing the right thing too. > In practical and operational terms, the point of all this is to allow > filtering engines to make better decisions about possibly-spoofed mail. ... and again, if those decisions result merely in rejecting a message, the user isn't involved, but as soon as those decisions can result in tagging a message for possible consideration by the user (probably via different display by the UI), we can't ignore the user. I agree that this isn't the place to delve deeply into user behaviour and UI design. But we shouldn't ignore the context of our work. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Mar 24 09:14:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D304A1A8F4C for ; Tue, 24 Mar 2015 09:14:25 -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 btGFztuZ6gIz for ; Tue, 24 Mar 2015 09:14:24 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6E71A8F3F for ; Tue, 24 Mar 2015 09:14:24 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 8E4881C3843; Wed, 25 Mar 2015 01:14:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 66658120EC9; Wed, 25 Mar 2015 01:14:23 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <102A355F80204C6C8F84DAECDA118C2E@fgsr.local> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp> <102A355F80204C6C8F84DAECDA118C2E@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 01:14:23 +0900 Message-ID: <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:14:26 -0000 J. Gomez writes: > I think we are not talking about the same thing: when I said > "depends on DMARC's success", I meant "depends on DMARC's success > as an implemented technology in the real world", whereas it seems > you understood "depends on a successful DMARC check". No, we are talking about the same thing. What I am saying is that DMARC is already a "success as an implemented technology in the real world" by any reasonable standard, because it *does* work for exactly the transactional mail flows you worry about. And it is possible to *prove* that it does work by looking at the properties of checks for individual messages. On the other hand, DMARC and similar technologies *cannot* solve the problem of spam and other abuse by those with whom you've had no previous relationship. That's easy to prove too: anybody with access to a DNS server can add DMARC and DKIM records and sign their mail. Mailing lists (among other indirect mail flows) do have problems interacting with DMARC, and it's worth trying to solve those problems. But they are not going to reverse DMARC's success. > I know that DMARC is not the silver bullet. If you know that, I do not understand how you can classify DMARC as anything but a success. I'm an MLM developer; I hate p=reject with a passion. But I can't deny that for the vast majority of mail, DMARC works as advertised, p=reject included. From nobody Tue Mar 24 09:23:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C222A1A903F for ; Tue, 24 Mar 2015 09:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldWoMrcTQBR7 for ; Tue, 24 Mar 2015 09:23:21 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 743221A6F3F for ; Tue, 24 Mar 2015 09:23:21 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2OGNKNu023734 for ; Tue, 24 Mar 2015 12:23:20 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2OGNKRg003988 for ; Tue, 24 Mar 2015 12:23:20 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Mon, 23 Mar 2015 22:13:11 BST References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 24 Mar 2015 12:23:20 -0400 Message-ID: <3987.1427214200@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-24 12:23:20 EDT Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:23:22 -0000 J. Gomez writes: > given that the "traditional practice of mailing lists adding > tags to Subject and footers to the message body" breaks DMARC, [...] > I vote for steam-rolling mailing lists configured old-style > to the history books. Mailing list operators just need to > take ownership in the Header-From for the messages whose DKIM > signature they break, and all is back to working great again! In most cases it would be inappropriate for mailing lists to take ownership of the messages. They are merely the distribution mechanism, and wrecking (IMHO) the From: header to avoid a verification failure seems the wrong way to go in the long run, even if it has had to be adopted as a workaround in the short run. As for subject tags and list trailers, at least the former is really helpful to me as a user (sorry, Dave! ;-) ), as it lets me know that a given message is in the context of a public or semi-public discussion. I'm not against the idea that mailing list software might have to adapt to the new reality (of the need for protection against spoofing), even though there will be a lengthy transition period. But we can also consider whether there are any changes to DKIM which would enable mailing lists not to break, or at least, which would not require changes which negatively affect the user experience for mailing list subscribers. Please forgive me if this has been discussed before (it seems inconceivable to me that it hasn't), but it should be possible to specify a format for header tags such that the tag is not included in the DKIM signature check for the Subject: line. rfc6376 has: Note that Verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. Would it be so awful to change that to: Note that Verifiers may treat unsigned header fields (or unsigned parts of header fields) with extreme skepticism, including refusing to display them to the end user, displaying them with an indication of unreliabiliy, or even ignoring the entire signature if it does not cover certain header fields. So, risking Dave's wrath once again by discussing possible UI approaches to verification information, if a header tag format were specified (for example) to be contained within square brackets, the UI could display the verified part one way, and the tagged-and-ignored part another way. I do freely admit that I don't know the implications of making it possible to sign only part of a given header. And I suspect that my suggestion may belong more on a DKIM discussion list than a DMARC discussion list... Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Mar 24 09:34:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA361A90DE for ; Tue, 24 Mar 2015 09:34:13 -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 JReU4HRUvBZK for ; Tue, 24 Mar 2015 09:34:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049971A90EF for ; Tue, 24 Mar 2015 09:34:03 -0700 (PDT) Received: from [172.20.6.94] (rrcs-71-41-251-196.sw.biz.rr.com [71.41.251.196]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2OGXdQo030912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 09:33:43 -0700 Message-ID: <551191DC.8020606@dcrocker.net> Date: Tue, 24 Mar 2015 11:33:32 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anne Bennett , dmarc@ietf.org References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <3987.1427214200@vindemiatrix.encs.concordia.ca> In-Reply-To: <3987.1427214200@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 24 Mar 2015 09:33:43 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:34:13 -0000 On 3/24/2015 11:23 AM, Anne Bennett wrote: > In most cases it would be inappropriate for mailing lists > to take ownership of the messages. They are merely the > distribution mechanism, and wrecking (IMHO) the From: header > to avoid a verification failure seems the wrong way to go in > the long run, even if it has had to be adopted as a workaround > in the short run. Formally and practically, they are more than mere re-distributors. A mailing list typically defines a 'community' for discussion. At least some of the modifications it does are to assert that community in some visible ways. Mailing lists therefore have the right to make the changes they make. That said, recipients consider the message to be 'from' and 'by' the original author, not the mailing list. > As for subject tags and list trailers, at least the former is > really helpful to me as a user (sorry, Dave! ;-) ), as it lets Huh? I /like/ Subject tags. They help to distinguish list mail from personal mail. > me know that a given message is in the context of a public or > semi-public discussion. Right. > I'm not against the idea that mailing list software might have to > adapt to the new reality (of the need for protection against > spoofing), even though there will be a lengthy transition period. I think the historical challenge has less been a case of philosophical legitimacy and more of inability to gain active, constructive participation of mailing list software maintainers. > rfc6376 has: > > Note that Verifiers may treat unsigned header fields with > extreme skepticism, including refusing to display them to > the end user or even ignoring the signature if it does not > cover certain header fields. > > Would it be so awful to change that to: > > Note that Verifiers may treat unsigned header fields (or > unsigned parts of header fields) with extreme skepticism, > including refusing to display them to the end user, displaying > them with an indication of unreliabiliy, or even ignoring the > entire signature if it does not cover certain header fields. > > So, risking Dave's wrath once again by discussing possible UI > approaches to verification information, if a header tag format > were specified (for example) to be contained within square > brackets, the UI could display the verified part one way, > and the tagged-and-ignored part another way. This is less a case of wrath -- should I be glad of such de facto and automatic intimidation, even when it doesn't work well enough to squelch others' views I disagree with? Hmmm... -- and more a case of efficacy. To make any assertions about preferred or appropriate UI behavior is to require establishing the basis that the behavior will be useful. The problem here is that the empirical basis for efficacy is lacking. So making a recommendation might serve to make the specification writers feel better, but they won't help fight abuse. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 24 09:55:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FFB1A909E for ; Tue, 24 Mar 2015 09:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FePp8-VrktCg for ; Tue, 24 Mar 2015 09:55:50 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A51A9140 for ; Tue, 24 Mar 2015 09:55:42 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2OGtgIC007441 for ; Tue, 24 Mar 2015 12:55:42 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2OGtgoU009156 for ; Tue, 24 Mar 2015 12:55:42 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Tue, 24 Mar 2015 11:33:32 CDT References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <3987.1427214200@vindemiatrix.encs.concordia.ca> <551191DC.8020606@dcrocker.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 24 Mar 2015 12:55:42 -0400 Message-ID: <9155.1427216142@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-24 12:55:42 EDT Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:55:52 -0000 Dave Crocker responds to my suggestion: >> rfc6376 has: [...] >> Would it be so awful to change that to: >> >> Note that Verifiers may treat unsigned header fields (or >> unsigned parts of header fields) with extreme skepticism, >> including refusing to display them to the end user, displaying >> them with an indication of unreliabiliy, or even ignoring the >> entire signature if it does not cover certain header fields. >> >> So, risking Dave's wrath once again by discussing possible UI >> approaches to verification information, if a header tag format >> were specified (for example) to be contained within square >> brackets, the UI could display the verified part one way, >> and the tagged-and-ignored part another way. > To make any assertions about preferred or appropriate UI behavior is to > require establishing the basis that the behavior will be useful. I dispute the idea that the above text makes assertions about "preferred" UI behaviour - rather, it mentions what might be possible (and yes, implies that it could be appropriate), without excluding other approaches. > The problem here is that the empirical basis for efficacy is lacking. True, and I agree that it's not up to us to propose user interface designs. But our work will be used by UI designers; how can we best make sure that we give them the informational tools they need in order to display a given message "appropriately"? Do you propose that since the UI is outside our scope, that we give no consideration at all to the tools that might be needed in order to implement a UI? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Mar 24 11:03:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CFB1AC41C for ; Tue, 24 Mar 2015 11:03: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 FgAjawb0zpm0 for ; Tue, 24 Mar 2015 11:02:59 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 242BE1AC7E7 for ; Tue, 24 Mar 2015 11:02:24 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 0F3AA1C3871; Wed, 25 Mar 2015 03:02:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DEA1E120EC9; Wed, 25 Mar 2015 03:02:22 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <551191DC.8020606@dcrocker.net> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <3987.1427214200@vindemiatrix.encs.concordia.ca> <551191DC.8020606@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 03:02:22 +0900 Message-ID: <877fu6mfyp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, Anne Bennett Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:03:01 -0000 Dave Crocker writes: > A mailing list typically defines a 'community' for discussion. At > least some of the modifications it does are to assert that > community in some visible ways. Sure, but From-munging is not an assertion of community, it's an assertion that there's a war out there, and the community is taking hits from friendly fire. > Mailing lists therefore have the right to make the changes they > make. That's an incomplete statement. They have the right to make the changes as long as they are compatible with community standards. For example, some lists provide advertising space in the footer. Others would have a revolution if you tried. From-munging is just not part of the community standard in most lists I participate in (and I've heard that some Yahoo! and AOL users object violently to the mitigations used to keep their posts from bouncing all over the world). Anne Bennett: > > I'm not against the idea that mailing list software might have to > > adapt to the new reality (of the need for protection against > > spoofing), even though there will be a lengthy transition period. Hardly. It's already done, at least in GNU Mailman: all of the transformations that invalidate DKIM signatures are optional. From-munging was *released* in October 2013 (in 2.1.16 IIRC). That's right, *before* the April DMARC Debacle. We have continued to refine the features (it's now possible in 2.1.18-1 to condition mitigations on a DNS lookup for "p=reject"). The software is not the problem. The list owners and list subscribers are. Back to Dave: > I think the historical challenge has less been a case of > philosophical legitimacy From-munging is hardly open-and-shut "philosophically legitimate." It has its advocates, but it sucks for many users because of the way their MUAs handle it, it arguably violates RFC 5322, and is ugly to boot. Nevertheless, GNU Mailman has a From-Munging option.[1] > and more of inability to gain active, constructive participation of > mailing list software maintainers. Hey, I resent that. You guys use GNU Mailman; you know where to find us if you want participation. Sure, we resist doing what is proposed. The fact is that choices we've been offered suck. Go away (the choice offered by experimental early versions of SPF)? You jest. From-Munging? Yuck -- and guess what, you're no fan, yourself. No subject tags, no footers? Excuse me, but prohibiting a valuable feature is exactly the opposite of a constructive change -- and you don't like this mitigation yourself. Note that these mitigations are now in GNU Mailman, as options. But most list owners don't want them. We've come up with our own (RFC-conforming) mitigations. They suck, too (MUAs are not prepared to deal with them gracefully, or in the case of iOS Apple Mail, at all). It's not the MLM developers you have a problem getting cooperation from. It's our users. Bottom line: making indirect mail flows compatible with DMARC-style spoof-protection is a hard problem. Footnotes: [1] Patch courtesy of Franck Martin. From nobody Tue Mar 24 12:22:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9411A8AA4 for ; Tue, 24 Mar 2015 12:22:35 -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 ZyWtuwjTXT2J for ; Tue, 24 Mar 2015 12:22:33 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1664E1A8A72 for ; Tue, 24 Mar 2015 12:22:33 -0700 (PDT) Received: by wixw10 with SMTP id w10so7204725wix.0 for ; Tue, 24 Mar 2015 12:22:31 -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=AgbDbBNQLwsiIurHbFBWXuWTCcoOkN2cE95Ki217M4s=; b=afErvdoIjdit/IhmfX229kbhSoOrsTxb1Ix/hloxKZGRUcrzlz97ffg4th5dxL4MuJ vTEmYogq30SRcP5uhFnqEIR5u1QCTLjvx9wB629lniu0ru9GEpNZmUdd/baBrXKcRBZp d/U+HiiU+rG0kM/A47Anv+jODoS/CbGWm0p1dD6Uy/PfxaqHbXzOicQ0pgjtgLCpP4Ma xGm8rNQHyNfZEsVxYqbXNm8Po276lVg9aEmp7xlLxV0/BvHt5sGdJdamBMLQ1Y71ks5P krLMX1CvuDrrKPq7aqRd6KPGUljBjGv/dW7MBjTSeSHlK2bVyjb/nHFRxN//W8PDMeTX xqhQ== MIME-Version: 1.0 X-Received: by 10.180.79.65 with SMTP id h1mr31366942wix.59.1427224951877; Tue, 24 Mar 2015 12:22:31 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 12:22:31 -0700 (PDT) In-Reply-To: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 12:22:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=14dae9cc95344574e205120db4bb Archived-At: Cc: "dmarc@ietf.org" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 19:22:35 -0000 --14dae9cc95344574e205120db4bb Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull wrote: > > > An mta could opt to send a message with unencoded utf8 headers (display > > > name, subject, etc) to another peer advertising SMTPUTF8 even if none > of > > > the envelope were internationalized addresses. If the recipient then > needed > > > to relay the message on to a site that didn't support SMTPUTF8, it > would > > > have to encode the headers. > > > You're right, it doesn't. > > AFAICS use of the SMTPUTF8 extension is incompatible with DKIM > signatures. See sec. 5.3 of RFC 6376. > > > Do you have a suggestion in mind? > > Conform to RFC 6376. > OK, but is it folly to consider a header canonicalization that can handle this? DKIM is designed to accommodate incremental improvements, after all. -MSK --14dae9cc95344574e205120db4bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
> &= gt; An mta could opt to send a message with unencoded utf8 headers (display=
=C2=A0> > name, subject, etc) to another peer advertising SMTPUTF8 ev= en if none of
=C2=A0> > the envelope were internationalized addresses. If the recip= ient then needed
=C2=A0> > to relay the message on to a site that didn't support S= MTPUTF8, it would
=C2=A0> > have to encode the headers.

=C2=A0> You're right, it doesn't.

AFAICS use of the SMTPUTF8 extension is incompatible with DKIM
signatures.=C2=A0 See sec. 5.3 of RFC 6376.

=C2=A0> Do you have a suggestion in mind?

Conform to RFC 6376.<wink />

OK, but is it folly to consider a header canonicalization that can handl= e this?=C2=A0 DKIM is designed to accommodate incremental improvements, aft= er all.

-MSK

--14dae9cc95344574e205120db4bb-- From nobody Tue Mar 24 13:18:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBBF1A8AD1 for ; Tue, 24 Mar 2015 13:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJLlGrsuor-p for ; Tue, 24 Mar 2015 13:18:02 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD691A8AB7 for ; Tue, 24 Mar 2015 13:18:02 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 92B338640 for ; Tue, 24 Mar 2015 21:18:00 +0100 (CET) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 24 Mar 2015 21:18:00 +0100 Message-ID: <0F6BB75B1D414285BD4918A18F0D2477@fgsr.local> From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <3987.1427214200@vindemiatrix.encs.concordia.ca> <551191DC.8020606@dcrocker.net> <877fu6mfyp.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 21:18:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:18:05 -0000 On Tuesday, March 24, 2015 7:02 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > From-munging is hardly open-and-shut "philosophically legitimate." It > has its advocates, but it sucks for many users because of the way > their MUAs handle it, it arguably violates RFC 5322, and is ugly to > boot. Well, it seems to me the above paragraph could also be written like = this: MLM taking ownership of the Header-From (a.k.a. "From-munging" in = your terms) has its detractors, but it works fine for many users who = don't have a problem with it, arguably conforms to RFC 5322, and looks = just nice. > Bottom line: making indirect mail flows compatible with DMARC-style > spoof-protection is a hard problem. It's only a hard problem if mailing list operators insist on clinging to = their old-style habits (mailing lists users largely either don't care or = don't understand the difference; and any other indirect email flows = --apart from mailing lists-- are extremely legacy and obsolete). Regards,=20 J.Gomez From nobody Tue Mar 24 13:38:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268291A8ADF for ; Tue, 24 Mar 2015 13:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToJJ6qUNURbx for ; Tue, 24 Mar 2015 13:38:29 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1555C1A8A84 for ; Tue, 24 Mar 2015 13:38:28 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id B452484BC for ; Tue, 24 Mar 2015 21:38:25 +0100 (CET) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 24 Mar 2015 21:38:25 +0100 Message-ID: From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local><87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp><102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 21:38:41 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:38:31 -0000 On Tuesday, March 24, 2015 5:14 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > I think we are not talking about the same thing: when I said > > "depends on DMARC's success", I meant "depends on DMARC's success > > as an implemented technology in the real world", whereas it seems > > you understood "depends on a successful DMARC check". >=20 > No, we are talking about the same thing. What I am saying is that > DMARC is already a "success as an implemented technology in the real > world" by any reasonable standard, because it *does* work for exactly > the transactional mail flows you worry about. I do not agree. As long a major ESPs downgrade p=3Dreject to = p=3Dquarantine or even p=3Dnone on reception of email which fails DMARC = checks from domains whose Owner has published p=3Dreject, DMARC is = little more than a reporting protocol as Vlatko Salaj has already said = in another post to this list. Which is nice, but is not a "success as an = implemented technology in the real world" for DMARC, because DMARC aims = to be more than just a reporting tool. I know for sure I will publish only p=3Dnone for my client's domains, = and use DMARC only as a reporting tool, as long as DMARC's p=3Dreject = cannot be reliably relied on. But I would love to be able to reliably = rely on DMARC's p=3Dreject. In fact, I think that if at the end of all this process we cannot find a = way to make p=3Dreject to be reliably relied on, then p=3Dreject should = be suppressed from the DMARC formal specification, as p=3Dreject would = effectively be equal to p=3Ddo-whatever-who-cares. Regard, J.Gomez From nobody Tue Mar 24 13:39:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E94B1A8AE4 for ; Tue, 24 Mar 2015 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU4MXATzYLYA for ; Tue, 24 Mar 2015 13:39:30 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D441A8AB9 for ; Tue, 24 Mar 2015 13:39:30 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so4025579obc.0 for ; Tue, 24 Mar 2015 13:39:29 -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=I7bNhf9C/sBN+YrzzlEbAFbNq81CR5GHSU3r4xnyUqE=; b=jwcAGl8BhJMX/CicQeBqVSEBNjvQUoLvIwSGU9z6Kv/SruW1k9mY603+/dJOP+vzx6 WZEyQsBFV4ZNyp2Gegjr31J/NImjyxq7U+1CJevg8VZE1W0IeJmDpFmHbpuEbIt1DUJQ 4Sqm7IiDPm8XQDWUHqdflRCNNbv+19XIYu5mwZGRt6FMBXIUZM+i5UVLXKNB7ZZR4F9m 405VK7sMNWFWCeXINbaHRSlQk6RAy4xycIm8t1VdXBbcD4qGy28gA1KGq7FgrhxLx1GG QvNWY2gSQGujarE+bLocID4lL/6GKkOn7iob1VpS0G4Zc0Edo24NYvPe7pVmj6OrK+t1 vD2w== 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=I7bNhf9C/sBN+YrzzlEbAFbNq81CR5GHSU3r4xnyUqE=; b=lt5j6TFSzSgj0Ny3lK9LFTw0BEMgf5eMKzwb2F6FkbBB/bx1rJ+Kesy/tfgO1MHk4S 028CqJSi/0m5OqIAgGmz4BPwW1e57Zv0L5CekuAnlaTcVUowOnaX/t21ukiNO6xt+6D8 gnCsj44Fu3fkDSRO0uSxMrTFNXtL5/wdu2pfKyW64kOP5qijgsUODMxCbTcwwLKNh66r jibXBI+4w6nZE7zTrUUPcmtBSQGu6uf7ob+clNEeo3J0leSUsFppm+WtCqOUBCe2U+nf ZKyQIBqTuEkqBWKCGrmZgGSIJFzqXSHHOoH+zvj33p0l4CTxE8UTnyDphaABOYPZwQro O2Kw== X-Gm-Message-State: ALoCoQnhfhIcw0euzFoOU4YpqCIq6PLsLUzDetasfc0bMAKCmKuNTCYytLjQq8uIPGYOK+wiBhUV MIME-Version: 1.0 X-Received: by 10.202.193.214 with SMTP id r205mr4395859oif.63.1427229569624; Tue, 24 Mar 2015 13:39:29 -0700 (PDT) Received: by 10.202.98.85 with HTTP; Tue, 24 Mar 2015 13:39:29 -0700 (PDT) In-Reply-To: References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 13:39:29 -0700 Message-ID: From: John Bucy To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a113dc58482d1f205120ec7fe Archived-At: Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:39:31 -0000 --001a113dc58482d1f205120ec7fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The scenario I had in mind was: - B advertises SMTPUTF8 but relays to C which does not - A sends a message to B with an unencoded utf8 Subject: invoking the SMTPUTF8 extension - B could opt to encode the Subject: header using rfc2047 to produce a message acceptable to C On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy wrote: > On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull > wrote: > >> > > An mta could opt to send a message with unencoded utf8 headers >> (display >> > > name, subject, etc) to another peer advertising SMTPUTF8 even if >> none of >> > > the envelope were internationalized addresses. If the recipient then >> needed >> > > to relay the message on to a site that didn't support SMTPUTF8, it >> would >> > > have to encode the headers. >> >> > You're right, it doesn't. >> >> AFAICS use of the SMTPUTF8 extension is incompatible with DKIM >> signatures. See sec. 5.3 of RFC 6376. >> >> > Do you have a suggestion in mind? >> >> Conform to RFC 6376. >> > > OK, but is it folly to consider a header canonicalization that can handle > this? DKIM is designed to accommodate incremental improvements, after all. > > -MSK > > --001a113dc58482d1f205120ec7fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
The scenario I had in mind was:
- B advertises SMTPUTF8 but relays to C which does not
- A sends a message to B with an unencoded utf8 Subject: invoking the SMTPUTF8 extension
- B could opt to encode the Subject: header using rfc2047 to produce a message acceptable to C


On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> > An mta could opt to send a message with unencoded utf8 headers (display
 > > name, subject, etc) to another peer advertising SMTPUTF8 even if none of
 > > the envelope were internationalized addresses. If the recipient then needed
 > > to relay the message on to a site that didn't support SMTPUTF8, it would
 > > have to encode the headers.

 > You're right, it doesn't.

AFAICS use of the SMTPUTF8 extension is incompatible with DKIM
signatures.  See sec. 5.3 of RFC 6376.

 > Do you have a suggestion in mind?

Conform to RFC 6376.<wink />

OK, but is it folly to consider a header canonicalization that can handle this?  DKIM is designed to accommodate incremental improvements, after all.

-MSK


--001a113dc58482d1f205120ec7fe-- From nobody Tue Mar 24 13:47:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC61A00EC for ; Tue, 24 Mar 2015 13:47:13 -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_110=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 kPQWubvD36a4 for ; Tue, 24 Mar 2015 13:47:13 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id C37C61A007B for ; Tue, 24 Mar 2015 13:47:12 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id A2A6684BC for ; Tue, 24 Mar 2015 21:47:10 +0100 (CET) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 24 Mar 2015 21:47:09 +0100 Message-ID: <6F28A207601345BBAF012FED7BE612EE@fgsr.local> From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> Date: Tue, 24 Mar 2015 21:47:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:47:13 -0000 On Tuesday, March 24, 2015 4:59 PM [GMT+1=3DCET], Anne Bennett wrote: > > In practical and operational terms, the point of all this is to > > allow filtering engines to make better decisions about > > possibly-spoofed mail.=20 >=20 > ... and again, if those decisions result merely in rejecting a > message, the user isn't involved, but as soon as those decisions > can result in tagging a message for possible consideration by the user > (probably via different display by the UI), we can't ignore the user. >=20 > I agree that this isn't the place to delve deeply into user behaviour > and UI design. But we shouldn't ignore the context of our work. +1 Email is for the users. p=3Dquarantine is a USER PROBLEM. Lets not forget that. Regard, J.Gomez From nobody Tue Mar 24 14:01:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886DB1A1A36 for ; Tue, 24 Mar 2015 14:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk3lzwywoRiT for ; Tue, 24 Mar 2015 14:01:14 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7351A8AF4 for ; Tue, 24 Mar 2015 14:01:05 -0700 (PDT) Received: by wibg7 with SMTP id g7so59801122wib.1 for ; Tue, 24 Mar 2015 14:01: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=OF9Q6o4QB6geZTuEMuuLXUhtt+pNYSbnsxCkPCQgm6c=; b=EPEVcE7p+uu+Ke9tP7w2gjPgbBPTfi69amx/Sfs+h3lwzeHnvL0LKLFYrLLfSc1+NE MifWeAdnWIQflv6LJU+QRuq31HFxJAJxwFe/2aDNTGvp2RySybv+o2Oc06Z7pCfEPDm4 YP+eDNEy3Arr2rFpjQFKbLuHeQdTDjAKCVR82bg1BX97Pb6iyCZd47NisBi9dkpqlpw9 PZVfShRYoEKy+p1Ez1zDPIYou8/bOsUgHTqOO8pp+at/CdXFGgguS07B9iH1h/VHOCGD TePrQkT7hrqg/ice8OlSstpOKrbnVq/F0opPxihz/nxRWnRDEeBZ+zuQeM8CKSrjFizf cBpg== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr11124177wjc.111.1427230864127; Tue, 24 Mar 2015 14:01:04 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 14:01:03 -0700 (PDT) In-Reply-To: References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp> <102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 14:01:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7bacb11eab3ea005120f14ad Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:01:15 -0000 --047d7bacb11eab3ea005120f14ad Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez wrote: > I know for sure I will publish only p=none for my client's domains, and > use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be > reliably relied on. But I would love to be able to reliably rely on DMARC's > p=reject. > I'm not sure I agree with the claim that p=reject is unreliable. It seems to me that it's working as designed, and the results are deterministic. It's not flaky. How receivers use it is the mushy part, but that's really outside of the protocol. Even if DMARC didn't have these mediator problems, there still would be no ultimate compulsion for receivers to do what domain owners ask. It might be a lot more likely that they would comply without reservations, but there would still be some operators that don't. So just to be clear, are you using "reliable" here to talk about how receivers apply it? -MSK --047d7bacb11eab3ea005120f14ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
I know for sure I will publish o= nly p=3Dnone for my client's domains, and use DMARC only as a reporting= tool, as long as DMARC's p=3Dreject cannot be reliably relied on. But = I would love to be able to reliably rely on DMARC's p=3Dreject.

I'm not sure I agree with the claim that p= =3Dreject is unreliable.=C2=A0 It seems to me that it's working as desi= gned, and the results are deterministic.=C2=A0 It's not flaky.=C2=A0 Ho= w receivers use it is the mushy part, but that's really outside of the = protocol.

Even if DMARC didn't have these mediator problems, the= re still would be no ultimate compulsion for receivers to do what domain ow= ners ask.=C2=A0 It might be a lot more likely that they would comply withou= t reservations, but there would still be some operators that don't.
=
So just to be clear, are you using "reliable" here to talk ab= out how receivers apply it?

-MSK
--047d7bacb11eab3ea005120f14ad-- From nobody Tue Mar 24 14:02:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0711A0140 for ; Tue, 24 Mar 2015 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT-77BZHoH9F for ; Tue, 24 Mar 2015 14:02:37 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECA11A8F38 for ; Tue, 24 Mar 2015 14:02:14 -0700 (PDT) Received: by wixw10 with SMTP id w10so9767353wix.0 for ; Tue, 24 Mar 2015 14:02: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=Ol1Jo9lu8yN3X/YlYLB/fUxpSe3hefBGKayW8l+0mHg=; b=F1NWX3GA8PH+Itf75H3Yle5ye3bVZMJBVXD6drnOPHiDM7GugfhOjc2mKu7r7dPHal Nr062NpEiol55Nl3ckPmvpNC6Oz3ACQUoNc6UXsTCcHTeB7zp2sBu2YP4s/HS/u+qGsn DVWV63yFtQW7dxvxNrK0OlpmCLwEoRio0HAlhxSfxnExmkwDZe4BWKSlRCTlGwRAwGHN PavCUvbFa/kqUMBF+Z9LoUijoUn9lW32NXwMu/Zzb4DbvYi0F1Z6kwye4iuMbv8laNSV nbBxFlsCwqXgfrbOOMVLvjbq6Ydo+xhBCh7z+BMeiRo/GISjjSeFOeLlpr96UgG85pn0 +vfg== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr11455967wjc.135.1427230933568; Tue, 24 Mar 2015 14:02:13 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 14:02:13 -0700 (PDT) In-Reply-To: References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 14:02:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Bucy Content-Type: multipart/alternative; boundary=047d7bd6adceced28e05120f1867 Archived-At: Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:02:39 -0000 --047d7bd6adceced28e05120f1867 Content-Type: text/plain; charset=UTF-8 So, maybe a header canonicalization that has as one of its steps conversion of all Subject fields to something RFC2047-compatible? On Tue, Mar 24, 2015 at 1:39 PM, John Bucy wrote: > The scenario I had in mind was: > - B advertises SMTPUTF8 but relays to C which does not > - A sends a message to B with an unencoded utf8 Subject: invoking the > SMTPUTF8 extension > - B could opt to encode the Subject: header using rfc2047 to produce a > message acceptable to C > > > On Tue, Mar 24, 2015 at 12:22 PM, Murray S. Kucherawy > wrote: > >> On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull >> wrote: >> >>> > > An mta could opt to send a message with unencoded utf8 headers >>> (display >>> > > name, subject, etc) to another peer advertising SMTPUTF8 even if >>> none of >>> > > the envelope were internationalized addresses. If the recipient >>> then needed >>> > > to relay the message on to a site that didn't support SMTPUTF8, it >>> would >>> > > have to encode the headers. >>> >>> > You're right, it doesn't. >>> >>> AFAICS use of the SMTPUTF8 extension is incompatible with DKIM >>> signatures. See sec. 5.3 of RFC 6376. >>> >>> > Do you have a suggestion in mind? >>> >>> Conform to RFC 6376. >>> >> >> OK, but is it folly to consider a header canonicalization that can handle >> this? DKIM is designed to accommodate incremental improvements, after all. >> >> -MSK >> >> > --047d7bd6adceced28e05120f1867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, maybe a header canonicalization that has as one of its= steps conversion of all Subject fields to something RFC2047-compatible?

On Tue, Ma= r 24, 2015 at 1:39 PM, John Bucy <jbucy@google.com> wrote:
The scenario I had in= mind was:
- B advertises SMTPUTF8 but relays to C which does= not
- A sends a message to B with an unencoded utf8 Subject: inv= oking the SMTPUTF8 extension
- B could opt to encode the Subject:= header using rfc2047 to produce a message acceptable to C


On Tue, Mar 24, 2015 at 12:22 PM, Murray S= . Kucherawy <superuser@gmail.com> wrote:
On Tue, Mar 24, 2015 at 8:17 AM, St= ephen J. Turnbull <stephen@xemacs.org> wrote:
> > An mta could opt to send a message with unenc= oded utf8 headers (display
=C2=A0> > name, subject, etc) to another peer advertising SMTPUTF8 ev= en if none of
=C2=A0> > the envelope were internationalized addresses. If the recip= ient then needed
=C2=A0> > to relay the message on to a site that didn't support S= MTPUTF8, it would
=C2=A0> > have to encode the headers.

=C2=A0> You're right, it doesn't.

AFAICS use of the SMTPUTF8 extension is incompatible with DKIM
signatures.=C2=A0 See sec. 5.3 of RFC 6376.

=C2=A0> Do you have a suggestion in mind?

Conform to RFC 6376.<wink />

OK, but is it folly to consider a header canonicalization that ca= n handle this?=C2=A0 DKIM is designed to accommodate incremental improvemen= ts, after all.

-MSK



--047d7bd6adceced28e05120f1867-- From nobody Tue Mar 24 14:04:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E661A0404 for ; Tue, 24 Mar 2015 14:04:31 -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_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2RAyH6qNe9S for ; Tue, 24 Mar 2015 14:04:30 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BF31A0140 for ; Tue, 24 Mar 2015 14:04:29 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 17:04:28 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Thread-Index: AQHQYcyPcrrs7iHzJUmAQ3HxMcQrhJ0l3PTJgABaXoCAAYT3gIAA6OlRgACWzQD//+Hir4AAv4WAgAC7WLeAAIDXgIAAe2fSgACFp4CAAAbEJYAAAfkA Date: Tue, 24 Mar 2015 21:04:28 +0000 Message-ID: References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local><87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp><102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.231] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:04:31 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of J. Gomez > Sent: Tuesday, March 24, 2015 4:39 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) >=20 > On Tuesday, March 24, 2015 5:14 PM [GMT+1=3DCET], Stephen J. Turnbull > wrote: >=20 > > J. Gomez writes: > > > > > I think we are not talking about the same thing: when I said > > > "depends on DMARC's success", I meant "depends on DMARC's success > as > > > an implemented technology in the real world", whereas it seems you > > > understood "depends on a successful DMARC check". > > > > No, we are talking about the same thing. What I am saying is that > > DMARC is already a "success as an implemented technology in the real > > world" by any reasonable standard, because it *does* work for exactly > > the transactional mail flows you worry about. >=20 > I do not agree. As long a major ESPs downgrade p=3Dreject to p=3Dquaranti= ne or > even p=3Dnone on reception of email which fails DMARC checks from domains > whose Owner has published p=3Dreject, DMARC is little more than a reporti= ng > protocol as Vlatko Salaj has already said in another post to this list. W= hich is > nice, but is not a "success as an implemented technology in the real worl= d" > for DMARC, because DMARC aims to be more than just a reporting tool. >=20 Mailbox providers/ISPs are going to do what they do. Recognizing local poli= cy is one of the reasons that the large mailbox providers/ISPs decided to v= alidate DMARC and play ball. By and large they get it right (at least in my= experience and I've been doing DMARC since before it was public). Even for= transactional mail from originators which have control over their mail flo= ws, there will always be some small percentage of mail that gets broken bec= ause of certain types of forwarding (beyond mail lists). From my perspectiv= e, when a mailbox provider/ISP chooses to implement local policy over my re= quest (through a published p=3Dreject policy) then they are taking responsi= bility for their decision. To demand more from them is simply unrealistic. = Any organization can publish a standard - the real proof is the extent to w= hich people adopt that standard. > I know for sure I will publish only p=3Dnone for my client's domains, and= use > DMARC only as a reporting tool, as long as DMARC's p=3Dreject cannot be > reliably relied on. But I would love to be able to reliably rely on DMARC= 's > p=3Dreject. >=20 My experience is that the overwhelming majority of time you can reliably re= ly on DMARC's policy implementation - and I'm looking at a corpus of Billio= ns of sent mail. You can check this yourself by looking at the reporting yo= u receive. If mailbox providers would have overridden your p=3Dreject it wi= ll show in the reporting you receive and you can gauge the potential outcom= e yourself. You are making assertions that the data doesn't support. Mailbo= x providers have no incentive to randomly override DMARC with local policy = for non-trivial reasons. The real problem is that once you get past the top= mailbox providers, the remainder of them don't have the resources/expertis= e/large enough data sets to implement local policy overrides in a manner th= at is workable and sustainable. Perhaps someone can make a go of offering t= his as a service - perhaps not. > In fact, I think that if at the end of all this process we cannot find a = way to > make p=3Dreject to be reliably relied on, then p=3Dreject should be suppr= essed > from the DMARC formal specification, as p=3Dreject would effectively be e= qual > to p=3Ddo-whatever-who-cares. >=20 Mike From nobody Tue Mar 24 14:09:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1121A03D5 for ; Tue, 24 Mar 2015 14:08:58 -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, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiuSi4MDIr0y for ; Tue, 24 Mar 2015 14:08:56 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1A61A036F for ; Tue, 24 Mar 2015 14:08:56 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Tue, 24 Mar 2015 17:08:55 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Thread-Index: AQHQYcyPcrrs7iHzJUmAQ3HxMcQrhJ0jKLwAgAFTRoCAAdHyAIAAgUGAgABcxYCAAD8fAIAAh3qAgAIQDgCAAEKTgIAAQWz3gABMWICAAQChhIAAUDvKgAAFE5A= Date: Tue, 24 Mar 2015 21:08:55 +0000 Message-ID: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> In-Reply-To: <6F28A207601345BBAF012FED7BE612EE@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.231] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:08:58 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of J. Gomez > Sent: Tuesday, March 24, 2015 4:47 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) >=20 > On Tuesday, March 24, 2015 4:59 PM [GMT+1=3DCET], Anne Bennett wrote: >=20 > > > In practical and operational terms, the point of all this is to > > > allow filtering engines to make better decisions about > > > possibly-spoofed mail. > > > > ... and again, if those decisions result merely in rejecting a > > message, the user isn't involved, but as soon as those decisions can > > result in tagging a message for possible consideration by the user > > (probably via different display by the UI), we can't ignore the user. > > > > I agree that this isn't the place to delve deeply into user behaviour > > and UI design. But we shouldn't ignore the context of our work. >=20 > +1 >=20 > Email is for the users. p=3Dquarantine is a USER PROBLEM. >=20 No, p=3Dquarantine is a problem WE cause. All these experts and algorithms = can't figure it out so we toss it in quarantine/junk/spam folder and then t= ell the user to figure it out. WE cause the problem. A person who used to b= e active in the email space once told me that the extent to which messages = are placed in quarantine/junk/spam folders is a reflection of how well or p= oorly the systems evaluating the mail work. If it works really well then no= thing should end up in quarantine/junk/spam folders. Mike From nobody Tue Mar 24 14:16:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36211A1A3D for ; Tue, 24 Mar 2015 14:16:25 -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_110=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 95Gw0wq5vVca for ; Tue, 24 Mar 2015 14:16:24 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202171A0371 for ; Tue, 24 Mar 2015 14:16:23 -0700 (PDT) Received: by wibg7 with SMTP id g7so85891853wib.1 for ; Tue, 24 Mar 2015 14:16:21 -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=aUpzAOH6eC2me153lK3dBVUMABqCX/4HiVJh8kgjLSc=; b=Q+2rjDya132rpNcVkqbW3nUVyyqyLcmtfA4Z+bB7KmjJx9VlyIwBj8E2GgQIIg6Jac zApD4l6u3Yi2EGR4olS18gsGZ863HTthOkKAn08wNR3VLgt2J0cucKVBsSPmFsk3gqn/ j2bsXCbX6e81tQkxsWMhbUlThJGjLTB4m/VTRjK7TSK+1dyyBNuJtoJMQLmU9idUYiqR lyCmpfTRQzC4cMGIDPkRSxC/dDbiQZWcDLIm+g2661+4kPe0cGA7gmCC1cMghm7w1l+C NaoRmN2EQtiGhDlKAKlStxG0Z8GJXFeT1wKx6usZpfWQ7FF9SvIhTO+9Ids5Rws/f2bl pynw== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr11834055wjc.4.1427231781852; Tue, 24 Mar 2015 14:16:21 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 14:16:21 -0700 (PDT) In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> Date: Tue, 24 Mar 2015 14:16:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: "MH Michael Hammer (5304)" Content-Type: multipart/alternative; boundary=089e01419d1c5e9f7805120f4b2b Archived-At: Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:16:25 -0000 --089e01419d1c5e9f7805120f4b2b Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 2:08 PM, MH Michael Hammer (5304) wrote: > > No, p=quarantine is a problem WE cause. All these experts and algorithms > can't figure it out so we toss it in quarantine/junk/spam folder and then > tell the user to figure it out. WE cause the problem. A person who used to > be active in the email space once told me that the extent to which messages > are placed in quarantine/junk/spam folders is a reflection of how well or > poorly the systems evaluating the mail work. If it works really well then > nothing should end up in quarantine/junk/spam folders. > > That's not how I characterize the spam folder, at least at the operators where I have mailboxes. It's more like: "We have reason to believe this is spam or otherwise illegitimate. We will silently set it aside and automatically discard it in X days, unless you come looking for something you feel might've been miscategorized and rescue it." That's different from telling the user to figure it out, which I take to mean something more like an ongoing and fairly constant filter training exercise. Of course, this only highlights again that different receivers will treat DMARC's output in whatever way suits them. -MSK --089e01419d1c5e9f7805120f4b2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 2:08 PM, MH Michael Hammer (5304) = <M= Hammer@ag.com> wrote:

No, p=3Dquarantine is a problem WE cause. All these experts and algo= rithms can't figure it out so we toss it in quarantine/junk/spam folder= and then tell the user to figure it out. WE cause the problem. A person wh= o used to be active in the email space once told me that the extent to whic= h messages are placed in quarantine/junk/spam folders is a reflection of ho= w well or poorly the systems evaluating the mail work. If it works really w= ell then nothing should end up in quarantine/junk/spam folders.


That's not how I characterize the = spam folder, at least at the operators where I have mailboxes.=C2=A0 It'= ;s more like: "We have reason to believe this is spam or otherwise ill= egitimate.=C2=A0 We will silently set it aside and automatically discard it= in X days, unless you come looking for something you feel might've bee= n miscategorized and rescue it."

That's differen= t from telling the user to figure it out, which I take to mean something mo= re like an ongoing and fairly constant filter training exercise.

Of course, this only highlights again that different receivers will= treat DMARC's output in whatever way suits them.

-MSK
--089e01419d1c5e9f7805120f4b2b-- From nobody Tue Mar 24 14:19:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2141A0371 for ; Tue, 24 Mar 2015 14:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgGB24Qhj2gD for ; Tue, 24 Mar 2015 14:19:50 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1AA1A19F7 for ; Tue, 24 Mar 2015 14:19:50 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2OLJnr9016651 for ; Tue, 24 Mar 2015 17:19:49 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2OLJniR014593 for ; Tue, 24 Mar 2015 17:19:49 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Tue, 24 Mar 2015 21:08:55 -0000 References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 24 Mar 2015 17:19:49 -0400 Message-ID: <14592.1427231989@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-24 17:19:49 EDT Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:19:52 -0000 Michael Hammer writes: > A person who used to be active in the email space once > told me that the extent to which messages are placed in > quarantine/junk/spam folders is a reflection of how well > or poorly the systems evaluating the mail work. If it works > really well then nothing should end up in quarantine /junk/spam > folders. The number of messages sorted as "not sure" is hardly the best or only measure of how well the system works; to take the above to an extreme, if I reject all mail, does my system work perfectly? ;-) But yes, the ideal situation is where we sort every message correctly and unambiguously. Meanwhile... Even if we grant that "p=quarantine is a problem WE cause", the fact is that until we have a *good* solution for mailing lists, most of us don't dare publish p=reject, which leaves us with p=none, or no DMARC records at all. Which means that (a) many of us cannot benefit from using DMARC under the current circumstances, and (b) many sites don't have the resources to implement it yet, but we still have to deal with their mail. I'm not willing to throw the baby out with the bathwater. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Mar 24 14:26:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB21A909A for ; Tue, 24 Mar 2015 14:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDXptq8vNxNh for ; Tue, 24 Mar 2015 14:26:48 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB671A1AE6 for ; Tue, 24 Mar 2015 14:26:46 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so10512631wib.1 for ; Tue, 24 Mar 2015 14:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gkWolBIs+2PK6BxY5xu5Fh/O6AW5vXyNg0y0oCOqjAE=; b=e3VBcDgCY8ZUeeJk1tYqBhle4+qa+1coDS+S5nTHAIHsUSyWmjZVRsogzhsFjdvU32 scPwPdOtxQD8q+jpGiBIxOrzSqVK/noPI3z3bTUvWtFMecrURxoA0/W+A7CZNV7hki8R C+d8mUZgEt47K9BrLYXHwATn79q26Jz/oEkCgeSqM6qIvQ0nVptcYs4uiOF6FvMd81/w T+bIj960IloSo4sSzPwJ4cZTi+OUyzhu98i2Nqeb/HI3hRK1lbgk1SMJe3GgkwQcJUSv AHW3HcZ8LToIsGNMvkc4zRHfwV45YZd75mgQ7uddKgkGKetRvDerBXUK68lZYp7gTcJl ThjQ== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr31740852wic.94.1427232405382; Tue, 24 Mar 2015 14:26:45 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 14:26:45 -0700 (PDT) In-Reply-To: <14592.1427231989@vindemiatrix.encs.concordia.ca> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <14592.1427231989@vindemiatrix.encs.concordia.ca> Date: Tue, 24 Mar 2015 14:26:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=001a11c381ce88eda705120f7093 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:26:49 -0000 --001a11c381ce88eda705120f7093 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett wrote: > But yes, the ideal situation is where we sort every message > correctly and unambiguously. Meanwhile... > > Even if we grant that "p=quarantine is a problem WE cause", > the fact is that until we have a *good* solution for mailing > lists, most of us don't dare publish p=reject, which leaves us > with p=none, or no DMARC records at all. Which means that (a) > many of us cannot benefit from using DMARC under the current > circumstances, and (b) many sites don't have the resources to > implement it yet, but we still have to deal with their mail. > I'm not willing to throw the baby out with the bathwater. +1. To be a bit flippant about it: Now that we have everyone's attention, possibly moreso than ever before, maybe it's possible to come up with a compromise that all corners of the email ecosystem can accept. But that doesn't mean we need to settle for creating schisms in that ecosystem. Entrenching is not the answer. -MSK --001a11c381ce88eda705120f7093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett <anne@= encs.concordia.ca> wrote:
But yes, the ideal sit= uation is where we sort every message
correctly and unambiguously.=C2=A0 Meanwhile...

Even if we grant that "p=3Dquarantine is a problem WE cause",
the fact is that until we have a *good* solution for mailing
lists, most of us don't dare publish p=3Dreject, which leaves us
with p=3Dnone, or no DMARC records at all.=C2=A0 Which means that (a)
many of us cannot benefit from using DMARC under the current
circumstances, and (b) many sites don't have the resources to
implement it yet, but we still have to deal with their mail.
I'm not willing to throw the baby out with the bathwater.
<= div>
+1.=C2=A0 To be a bit flippant about it: Now that we hav= e everyone's attention, possibly moreso than ever before, maybe it'= s possible to come up with a compromise that all corners of the email ecosy= stem can accept.

But that doesn't mean we need to settle for cre= ating schisms in that ecosystem.=C2=A0 Entrenching is not the answer.

-MSK
--001a11c381ce88eda705120f7093-- From nobody Tue Mar 24 14:32:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AE31A1A1D for ; Tue, 24 Mar 2015 14:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61VfiUU0OZUN for ; Tue, 24 Mar 2015 14:32:03 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 728211A0404 for ; Tue, 24 Mar 2015 14:32:03 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 44178803BB for ; Tue, 24 Mar 2015 14:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1427232723; bh=3S28wiVUR/EM6qQJ6OtI4jhA/NAvIGko9QSXJpasitY=; h=Subject:From:In-Reply-To:Date:References:To:From; b=dz3fUggyIdbBwIyvCL34yjharVbMM6eCUEF9u7kLozU9wee+cSP+fRex5r89Nmkl/ c3SJ1yC7B1X2E3cDhUm6BtT1IqfYjX8wBJWErSMXjpyaDIzot9pjOOq4N9NEDTph9W CTdzrGjZE0vU4sAVZmfmnCgBTTdda5mS9DjrOYxY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <14592.1427231989@vindemiatrix.encs.concordia.ca> Date: Tue, 24 Mar 2015 14:32:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5876FB0C-2570-447D-8694-F39E06FBA64A@wordtothewise.com> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <14592.1427231989@vindemiatrix.encs.concordia.ca> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:32:07 -0000 On Mar 24, 2015, at 2:19 PM, Anne Bennett wrote: > > Michael Hammer writes: > >> A person who used to be active in the email space once >> told me that the extent to which messages are placed in >> quarantine/junk/spam folders is a reflection of how well >> or poorly the systems evaluating the mail work. If it works >> really well then nothing should end up in quarantine /junk/spam >> folders. > > The number of messages sorted as "not sure" is hardly the > best or only measure of how well the system works; to take > the above to an extreme, if I reject all mail, does my system > work perfectly? ;-) > > But yes, the ideal situation is where we sort every message > correctly and unambiguously. Meanwhile... > > Even if we grant that "p=quarantine is a problem WE cause", > the fact is that until we have a *good* solution for mailing > lists, most of us don't dare publish p=reject, which leaves us > with p=none, or no DMARC records at all. Which means that (a) > many of us cannot benefit from using DMARC under the current > circumstances, and (b) many sites don't have the resources to > implement it yet, but we still have to deal with their mail. > I'm not willing to throw the baby out with the bathwater. Mailing lists are only an issue if the domain owner of the email addresses of the participants have published a DMARC p=reject record, despite having actual users who are legitimate source of email that fails authentication. That's a small enough set of domains at the moment (I can think of about five) that there are several obvious solutions for mailing lists - a blacklist of DMARC records to treat specially would be the simplest, though something more nuanced might be better. Cheers, Steve From nobody Tue Mar 24 14:41:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC81A8BBF for ; Tue, 24 Mar 2015 14:41:27 -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 Dd8rFIF1J3ZK for ; Tue, 24 Mar 2015 14:41:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64CD61A8ADF for ; Tue, 24 Mar 2015 14:41:26 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2OLfMNW014324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 14:41:25 -0700 Message-ID: <5511D9FB.3000008@dcrocker.net> Date: Tue, 24 Mar 2015 16:41:15 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <3987.1427214200@vindemiatrix.encs.concordia.ca> <551191DC.8020606@dcrocker.net> <877fu6mfyp.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <877fu6mfyp.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 24 Mar 2015 14:41:26 -0700 (PDT) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:41:28 -0000 On 3/24/2015 1:02 PM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > A mailing list typically defines a 'community' for discussion. At > > least some of the modifications it does are to assert that > > community in some visible ways. > > Sure, but From-munging is not an assertion of community, it's an > assertion that there's a war out there, and the community is taking > hits from friendly fire. Your 'but' suggests that your comment counters mine, but I said 'some' not all and I didn't mention the From field. Nor did I intend to count >From munging as an exemplar. > > Mailing lists therefore have the right to make the changes they > > make. > > That's an incomplete statement. They have the right to make the > changes as long as they are compatible with community standards. There is a very long list of additional qualifiers and requirements one might choose to include. However I think they distract from the point I was making, which really merely reflects what is in the Email Architecture RFC: When an intermediary is re-posting a message, it owns the message it is re-posting and has the right to do what it wants. That's a system architecture "right", not a "social' right. > Back to Dave: > > > I think the historical challenge has less been a case of > > philosophical legitimacy > > From-munging is hardly open-and-shut "philosophically legitimate." So it's probably good that I wasn't talking about that. > It > has its advocates, but it sucks for many users because of the way > their MUAs handle it, it arguably violates RFC 5322, and is ugly to > boot. Nevertheless, GNU Mailman has a From-Munging option.[1] There are three operational problems with From munging: 1. The recipient sees a different string than they are used to, for identifying the author of the message. That invites confusion. 2. The recipient's filtering engine will misbehave if it keys off of author's name; a related problem is that message threading software will misbehave. 3. From munging teaches spoofers how to bypass DMARC protections. > > and more of inability to gain active, constructive participation of > > mailing list software maintainers. > > Hey, I resent that. You guys use GNU Mailman; you know where to find > us if you want participation. I was making an historical comment. Many years ago. Ancient Internet. Most of you folk probably weren't born yet. (just kidding.) (maybe.) > It's not the MLM developers you have a problem getting cooperation > from. It's our users. We need to stop worrying about users. They are simply a distraction. Or maybe... > Bottom line: making indirect mail flows compatible with DMARC-style > spoof-protection is a hard problem. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 24 14:56:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D531AC41F for ; Tue, 24 Mar 2015 14:56:08 -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 UpwL9C7dcHl0 for ; Tue, 24 Mar 2015 14:56:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABE31A1A4A for ; Tue, 24 Mar 2015 14:56:07 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2OLtmfm015663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 14:55:52 -0700 Message-ID: <5511DD5D.7060703@dcrocker.net> Date: Tue, 24 Mar 2015 16:55:41 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anne Bennett , "dmarc@ietf.org" References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> In-Reply-To: <3262.1427212761@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 24 Mar 2015 14:55:52 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:56:08 -0000 On 3/24/2015 10:59 AM, Anne Bennett wrote: > > Dave, > >> You make an assumption about user assumptions. Forgive me, but I doubt >> you have a reliable, objective, empirical basis for making that >> assertion or much that derives from it. In fact there's a reasonable >> chance that your assumption is flawed. > > I have a 24-year-long parade of users worried that their account was > compromised because they're receiving bounces for spam they never > sent, Forgive me (yet again) but that wasn't the issue. Yes there's a problem. Long-standing, real and serious. However the issue on the table is an assertion of efficacy by presenting certain kinds of information to end-users. And it's that assertion that is (highly) problematic. Which is why I urge everyone to bypass it. > But we're straying from the topic, which is indeed to come up with > technical specs that software can obey. Having said that: > >>> One could argue, I suppose, that once again we're talking >>> about the behaviour of software, but the point of all this, >>> unless I woefully misunderstand, is to protect the user from >>> fraud due to the faked provenance of a message. >> >> As a very general mission statement -- or an even higher-level motivator >> for working in this space -- perhaps, but that has essentially no effect >> on design choices here. > If "the point of all this" has "essentially no effect on design > choices", we have a serious problem. It's all very well do do > things right, but we have to make sure we're doing the right > thing too. Protecting users does not automatically or necessarily entail presenting spoofing/validity information to those users. >> In practical and operational terms, the point of all this is to allow >> filtering engines to make better decisions about possibly-spoofed mail. > > ... and again, if those decisions result merely in rejecting a > message, the user isn't involved, but as soon as those decisions > can result in tagging a message for possible consideration by the user > (probably via different display by the UI), we can't ignore the user. The presumption that 'tagging a message for possible consideration by the user' is in any way relevant or helpful is problematic. Highly problematic. > I agree that this isn't the place to delve deeply into user behaviour > and UI design. But we shouldn't ignore the context of our work. Any consideration here, which leads to assumptions or expectations of things being presented to end users for their consideration, is a pure distraction -- at its best. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 24 14:57:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7A11A1B6D for ; Tue, 24 Mar 2015 14:57:40 -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, 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 PgNRMvIUhVNY for ; Tue, 24 Mar 2015 14:57:39 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id E85BB1A1AE3 for ; Tue, 24 Mar 2015 14:57:38 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 791265644C0; Tue, 24 Mar 2015 16:57:38 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5F30BA0443; Tue, 24 Mar 2015 16:57:38 -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 fKP35MRz6NB1; Tue, 24 Mar 2015 16:57:38 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DA762A04D3; Tue, 24 Mar 2015 16:57:37 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com DA762A04D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427234258; bh=MU7khS/JHFxN9oqjoeJK3wJxvg4tyEeAYxtn31Pk1fk=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=S4rpcaghrF5nfD1XMxuKYEAtWqU2n1UKq/6WLz+fjn8P2KkWRTZ80fEMEq3ftO9lZ /Q5N0CvAmMinxep3ov3sxQVFCCJTs7Pqc2Bnqd2HUCyFGXvyj1maWw3xOznendTKbk M1V5O6B81CinIvKkguqEW2eBUn3oGI7+8WBXKbLo= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BBCCFA04D0; Tue, 24 Mar 2015 16:57:37 -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 f6wwSkVdFiFK; Tue, 24 Mar 2015 16:57:37 -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 62BEEA04B0; Tue, 24 Mar 2015 16:57:37 -0500 (CDT) Date: Tue, 24 Mar 2015 16:57:37 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <2145910335.53500.1427234257144.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53499_1948796276.1427234257143" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: interoperability issues around gateway-transformation Thread-Index: c6DS9Y/PP24doR+9ZwzWM5q24C+LQw== Archived-At: Cc: dmarc@ietf.org, "Stephen J. Turnbull" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:57:40 -0000 ------=_Part_53499_1948796276.1427234257143 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > So, maybe a header canonicalization that has as one of its steps conversion > of all Subject fields to something RFC2047-compatible? > On Tue, Mar 24, 2015 at 1:39 PM, John Bucy < jbucy@google.com > wrote: > > The scenario I had in mind was: > > > - B advertises SMTPUTF8 but relays to C which does not > > > - A sends a message to B with an unencoded utf8 Subject: invoking the > > SMTPUTF8 extension > > > - B could opt to encode the Subject: header using rfc2047 to produce a > > message acceptable to C > No, the EAI RFC is clear, if the MTA (B) cannot send it as is, you MUST bounce it. remember EAI does not offer any downgrade capability at the MTA level (by design). ------=_Part_53499_1948796276.1427234257143 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>

So, maybe a header canonicalization t= hat has as one of its steps conversion of all Subject fields to something R= FC2047-compatible?

On Tue, Mar 24, 2015 at 1:39 PM, John Bucy <= ;jbucy@google.com= > wrote:
= The scenario I had in mind was:
- B advertises SMTPUTF8 but r= elays to C which does not
- A sends a message to B with an unenco= ded utf8 Subject: invoking the SMTPUTF8 extension
- B could opt t= o encode the Subject: header using rfc2047 to produce a message acceptable = to C

N= o, the EAI RFC is clear, if the MTA (B) cannot send it as is, you MUST boun= ce it.

remember EAI does not offer any downgrade c= apability at the MTA level (by design).

------=_Part_53499_1948796276.1427234257143-- From nobody Tue Mar 24 15:01:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E451A1B6D for ; Tue, 24 Mar 2015 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.188 X-Spam-Level: * X-Spam-Status: No, score=1.188 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4ESGg1ghb7D for ; Tue, 24 Mar 2015 15:01:17 -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 5FA381A1B83 for ; Tue, 24 Mar 2015 15:01:15 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id t2OM17nw054547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 24 Mar 2015 15:01:13 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com t2OM17nw054547 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1427234473; bh=rDAknjoiPaFy9TpTJUxB8YlaAjjJ9IQYaJh91pzzibI=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PkechKc+976Ql6QYZmLZPPlu8erzXrDjlRrXv6YJPVrTDglYro2Eb2ruQcs8MeZPQ WR7YYwu0zcIhZSahTnpHu62jJhFxsxviGFtn+Na8OLirDtoynGxKykmMmk6BQ8FbYs +yQWSttXCTNtKDslDIwr6GuZY53LuwT5jKT1B6MA= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <5511DEA5.3010106@crash.com> Date: Tue, 24 Mar 2015 15:01:09 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local><87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp><102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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]); Tue, 24 Mar 2015 15:01:13 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 22:01:18 -0000 On 03/24/2015 01:38 PM, J. Gomez wrote: > I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a "success as an implemented technology in the real world" for DMARC, because DMARC aims to be more than just a reporting tool. DMARC is not some declaration of the divine right of domain owners to exercise absolute control over any message where their domain appears. DMARC is a protocol that enables domain owners/senders and receivers to *collaborate* in detecting and eliminating fraudulent messages that claim to originate from a given domain. There is implicit and explicit give-and-take in that relationship. Policy expressions from domain owners ("p=reject") are requests - ones that are followed in most cases - but no receiver is offering an unreserved, 100% guarantee that they won't act otherwise when they feel doing so is in the best interest of their users. The fact that receivers can and will do what they think best, even in the face of a given policy request, runs throughout the DMARC specification. > In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares. Again, in my experience, receivers do honor policy assertions in an overwhelming majority of cases. The reporting mechanisms in DMARC are there to help domain owners/senders improve the authentication rates of their legitimate mailflows - so the receivers can block more fraudulent messages, more reliably. Without the support for so-called "blocking policies," you have eliminated the reason for receivers to pay for complex, expensive DMARC filtering and reporting. --Steve. From nobody Tue Mar 24 18:46:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959BB1A6FF6 for ; Tue, 24 Mar 2015 18:46:53 -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 1vxW2RcTOBP3 for ; Tue, 24 Mar 2015 18:46:52 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5E1A6FF0 for ; Tue, 24 Mar 2015 18:46:51 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 490901C38B7; Wed, 25 Mar 2015 10:46:50 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 23310120EC9; Wed, 25 Mar 2015 10:46:50 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 10:46:50 +0900 Message-ID: <87y4mllugl.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 25 Mar 2015 01:46:53 -0000 Murray S. Kucherawy writes: > On Tue, Mar 24, 2015 at 8:17 AM, Stephen J. Turnbull > wrote: > > AFAICS use of the SMTPUTF8 extension is incompatible with DKIM > > signatures. See sec. 5.3 of RFC 6376. > > > > > Do you have a suggestion in mind? > > > > Conform to RFC 6376. > > OK, but is it folly to consider a header canonicalization that can > handle this? DKIM is designed to accommodate incremental > improvements, after all. Sec. 5.3 isn't, though. :-( From nobody Tue Mar 24 18:52:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0151A6F32 for ; Tue, 24 Mar 2015 18:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.201 X-Spam-Level: X-Spam-Status: No, score=-100.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, 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 cM-Y6B7XqhtV for ; Tue, 24 Mar 2015 18:52:54 -0700 (PDT) Received: from ntbbs.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6461E1A00F6 for ; Tue, 24 Mar 2015 18:52:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4032; t=1427248364; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xIp+N4qZ8L932QSUjN3oV5JleB4=; b=Kl/uH/qrJt9ZzAuobLxJ 49x+qaGOpIWR8bG+bjEVhIUed6yKm6ZFIS6AJRNEQE4dWJo8cX8HdcyVA8AKjioD KIomOxqXmSclfwYo/SR6VzPSoRGBUjXlyFBP8E+pJHBymTOYLAKsYAJrNxxNCkk1 N/XhgMt2XycRoy12BG5EtrI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 24 Mar 2015 20:52:44 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 958399905.22758.1912; Tue, 24 Mar 2015 20:52:43 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4032; t=1427248165; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yY/CKkA sWKoIO6nMkgmbL1M7yxR3CCPrj/8M+cRpOAs=; b=SWxvJi81X9d/XXw1+TXsJtf hgrx0gsbvB9bEZ5jhNZ91EsD72sVBWmV6SbykLlFUOsp8MR3ESy064hX2oFixzta L4HzIjL/ronHJyQFPsjhcLe+yFzuG5HKaRKVyLLNrceppFBoZso+PdJZ5GJb1iMR lvI1dgCSADX0BxgK5jgA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 24 Mar 2015 21:49:25 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3845668847.9.11872; Tue, 24 Mar 2015 21:49:25 -0400 Message-ID: <551214E6.4030906@isdg.net> Date: Tue, 24 Mar 2015 21:52:38 -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: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local><87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp><102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 01:52:57 -0000 For nearly 10+ years we have discussed the same basic design issues. Nothing has changed other than the fact it is DMARC, as it is currently written as the replacement protocol for a DKIM POLICY SSP/ADSP framework, is very lacking intentionally. We don't have enough of the advocates we once had, pushing the COMPLETE DKIM POLICY FRAMEWORK concept. Either they got tired walked away, they saw can't beat a dead horse or realize the people in "IETF control" were pushing other ideas that were not necessarily wrong, but they PUT barriers up to support the AUTHOR domain framework. We will not move forward in a major way until the 3rd party SIGNATURE authorization methodology is worked out. It was a thorn on the side then and it continues to be a thorn on the side today. We have quite a few RFCs related to DKIM signature methodologies and we never did properly resolved it (3rd party signers) because the key folks running the show were pushing a 3rd party TRUST methodology. They were militarily adamant about making sure the AUTHOR domain would not be dictating anything, hence the DKIM myth the AUTHOR DOMAIN was not related to the DKIM SIGNER AUTHENTICATION and AUTHORIZATION. That SEPARATION was impossible to ACHIEVE because the AUTHOR was a minimal hash binding requirement. But today, the TRUST part has gone no where, i.e. VBR was the closest thing to a DKIM TRUST model (we support it, do you?). It was AUTHOR POLICY that has prevailed but DMARC crippled it by sticking with the same problems ADSP had. Add 3rd party POLICY extensions and we will begin to get sensible software solutions again. We done it with ADSP/ATPS. So can large boys too with DMARC/ATPS. Add ATPS support or similar and we will begin to move forward with a framework for proper SOFTWARE CHANGE at the MLM. Wasting too much time again. Just update ATPS for DMARC and get MURRY to support the idea and maybe we will get others to get it a try. But if he is going to continue to block it, talk negative about it, well, we have a technical marketing problem that is not representative of a good technical, plug and play, easier solution for DKIM SIGNATURE AUTHORIZATION PROTOCOL. -- HLS On 3/24/2015 4:38 PM, J. Gomez wrote: > On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote: > >> J. Gomez writes: >> >>> I think we are not talking about the same thing: when I said >>> "depends on DMARC's success", I meant "depends on DMARC's success >>> as an implemented technology in the real world", whereas it seems >>> you understood "depends on a successful DMARC check". >> >> No, we are talking about the same thing. What I am saying is that >> DMARC is already a "success as an implemented technology in the real >> world" by any reasonable standard, because it *does* work for exactly >> the transactional mail flows you worry about. > > I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a "success as an implemented technology in the real world" for DMARC, because DMARC aims to be more than just a reporting tool. > > I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. > > In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares. > > Regard, > J.Gomez > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Tue Mar 24 21:11:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83091ACD85 for ; Tue, 24 Mar 2015 21:11: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 iw9NARJULsU4 for ; Tue, 24 Mar 2015 21:11:55 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5996E1ACD8A for ; Tue, 24 Mar 2015 21:11:55 -0700 (PDT) Received: by wixw10 with SMTP id w10so20538617wix.0 for ; Tue, 24 Mar 2015 21:11:54 -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=bvtXtNe5oQa4WTthfkKI1EXmZJeVQDMDKt+oce2G9Vg=; b=DrJxnaocyHpowa6FiDWDyP+tRvpq5qY8jXOw55lcYA1/cvekMZKHQM3bYpP9vIqzzK 9a8/aTom4zSAXGO8mtSaajGfiwvVRci74yNcpBtZwhJyIAN7K6gT0p+fmRXMjXOb0fEl n0pyg0WNELXnmNru4CW8vTYcyKkrywuE75i+EdGCZgruof6OjGDfhtd83rVgFad2g70H d+2K3Ja8d3WTG3jwRELCySHdQDAOef+vZoNvFO0M/r48elLRCkhBf8yl5xekq49fIF7h NRbx4N8zosXjybwrN7CCyfaaT5F0tlYEzoABHU21jdEpZi3/FjalyfdDF6fg6CAiZve/ 8Adg== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr14100024wjc.4.1427256714160; Tue, 24 Mar 2015 21:11:54 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 21:11:54 -0700 (PDT) In-Reply-To: <87y4mllugl.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4mllugl.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 24 Mar 2015 21:11:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=089e01419d1c736ff405121519bd Archived-At: Cc: "dmarc@ietf.org" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 25 Mar 2015 04:11:56 -0000 --089e01419d1c736ff405121519bd Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 6:46 PM, Stephen J. Turnbull wrote: > > OK, but is it folly to consider a header canonicalization that can > > handle this? DKIM is designed to accommodate incremental > > improvements, after all. > > Sec. 5.3 isn't, though. :-( > As I read 5.3, it says you need to make sure what you sign is what the verifier will receive. It seems to me a signer that gets 8-bit header fields can RFC2047-ize them before signing, presuming the MTA will make the same conversion before putting the signed message out on the wire. -MSK --089e01419d1c736ff405121519bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 6:46 PM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
=C2=A0= > OK, but is it folly to consider a header canonicalization that can
=C2=A0> handle this?=C2=A0 DKIM is designed to accommodate incremental =C2=A0> improvements, after all.

Sec. 5.3 isn't, though. :-(

As I read 5.3, it s= ays you need to make sure what you sign is what the verifier will receive.= =C2=A0 It seems to me a signer that gets 8-bit header fields can RFC2047-iz= e them before signing, presuming the MTA will make the same conversion befo= re putting the signed message out on the wire.

-MSK
--089e01419d1c736ff405121519bd-- From nobody Tue Mar 24 21:24:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5701ACD94 for ; Tue, 24 Mar 2015 21:24:52 -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 6BGTlrylP5Zt for ; Tue, 24 Mar 2015 21:24:50 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 938E41ACD93 for ; Tue, 24 Mar 2015 21:24:50 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 6E2CF1C38D6; Wed, 25 Mar 2015 13:24:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4891B120EC9; Wed, 25 Mar 2015 13:24:49 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <0F6BB75B1D414285BD4918A18F0D2477@fgsr.local> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <3987.1427214200@vindemiatrix.encs.concordia.ca> <551191DC.8020606@dcrocker.net> <877fu6mfyp.fsf@uwakimon.sk.tsukuba.ac.jp> <0F6BB75B1D414285BD4918A18F0D2477@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 13:24:49 +0900 Message-ID: <87r3sdln5a.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 04:24:52 -0000 J. Gomez writes: > On Tuesday, March 24, 2015 7:02 PM [GMT+1=CET], Stephen J. Turnbull wrote: > > > From-munging is hardly open-and-shut "philosophically legitimate." It > > has its advocates, but it sucks for many users because of the way > > their MUAs handle it, it arguably violates RFC 5322, and is ugly to > > boot. > > Well, it seems to me the above paragraph could also be written like > this: MLM taking ownership of the Header-From > (a.k.a. "From-munging" in your terms) has its detractors, but it > works fine for many users who don't have a problem with it, > arguably conforms to RFC 5322, and looks just nice. OK, well, we'll just have to agree to disagree. From nobody Tue Mar 24 21:29:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F291ACD91 for ; Tue, 24 Mar 2015 21:29:43 -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 vdD7i8CnXwZb for ; Tue, 24 Mar 2015 21:29:42 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 547181ACD8A for ; Tue, 24 Mar 2015 21:29:42 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id C99151C38D6; Wed, 25 Mar 2015 13:29:41 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B9952120EC9; Wed, 25 Mar 2015 13:29:41 +0900 (JST) From: "Stephen J. Turnbull" To: Steve Atkins In-Reply-To: <5876FB0C-2570-447D-8694-F39E06FBA64A@wordtothewise.com> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <14592.1427231989@vindemiatrix.encs.concordia.ca> <5876FB0C-2570-447D-8694-F39E06FBA64A@wordtothewise.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 13:29:41 +0900 Message-ID: <87pp7xlmx6.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 04:29:43 -0000 Steve Atkins writes: > Mailing lists are only an issue if the domain owner of the > email addresses of the participants have published a > DMARC p=reject record, despite having actual users who > are legitimate source of email that fails authentication. False. Mailing lists only have an obvious problem if p=reject is published, but DMARC doesn't say that you can't differentiate between aligned mail and unaligned mail, only that you can't differentiate between a failed signature verification and no signature at all. Sites can and do assign negative spam points to verified signatures, so there is a (smaller, but still real) problem for MLs even if nobody publishes p=reject. From nobody Tue Mar 24 23:42:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C411ACDD2 for ; Tue, 24 Mar 2015 23:42:30 -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 WZ8cVGHj2y3x for ; Tue, 24 Mar 2015 23:42:28 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BEBA11A0270 for ; Tue, 24 Mar 2015 23:42:28 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id ECDF11C38EC; Wed, 25 Mar 2015 15:42:26 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D45F0120EC9; Wed, 25 Mar 2015 15:42:26 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <87bnjimnl0.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4mllugl.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 25 Mar 2015 15:42:26 +0900 Message-ID: <87lhillgrx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , John Bucy Subject: Re: [dmarc-ietf] interoperability issues around gateway-transformation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 25 Mar 2015 06:42:30 -0000 Murray S. Kucherawy writes: > As I read 5.3, it says you need to make sure what you sign is what > the verifier will receive. It seems to me a signer that gets 8-bit > header fields can RFC2047-ize them before signing, presuming the > MTA will make the same conversion before putting the signed message > out on the wire. I'm not sure what you're trying to say here. If the outgoing MTA has SMTPUTF8 enabled, then it has the option of not encoding them and leaving them as "raw" UTF-8. But if is encounters an MTA that doesn't support SMTPUTF8, it must encode or bounce. In an SMTPUTF8-enabled environment, whether the header is encoded or not is nondeterminis- tic. So that presumption is invalid. The signer really has to force RFC 2047 encoding, and so may as well do it itself. From nobody Wed Mar 25 12:17:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9004F1ABD38 for ; Wed, 25 Mar 2015 12:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.598 X-Spam-Level: ** X-Spam-Status: No, score=2.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL8htWEPD4z8 for ; Wed, 25 Mar 2015 12:17:15 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id C7AFC1A8A68 for ; Wed, 25 Mar 2015 12:17:10 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id A1A10876F for ; Wed, 25 Mar 2015 20:17:08 +0100 (CET) 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; Wed, 25 Mar 2015 20:17:08 +0100 Message-ID: From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> Date: Wed, 25 Mar 2015 20:17:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 19:17:17 -0000 On Tuesday, March 24, 2015 10:08 PM [GMT+1=3DCET], MH Michael Hammer = (5304) wrote: > > On Tuesday, March 24, 2015 4:59 PM [GMT+1=3DCET], Anne Bennett = wrote: > >=20 > > > ... and again, if those decisions result merely in rejecting a > > > message, the user isn't involved, but as soon as those decisions > > > can result in tagging a message for possible consideration by the > > > user (probably via different display by the UI), we can't ignore > > > the user.=20 > > >=20 > > > I agree that this isn't the place to delve deeply into user > > > behaviour and UI design. But we shouldn't ignore the context of > > > our work.=20 > >=20 > > +1 > >=20 > > Email is for the users. p=3Dquarantine is a USER PROBLEM. > >=20 >=20 > No, p=3Dquarantine is a problem WE cause. Yes, but a problem that ultimately the user gets directly planted before = his eyes, and which the user has to roll up his sleeves to deal with as = well/bad as he can possibly manage. Translation: p=3Dquarantine has vey high support costs. As I understand it, in the beginning of the coming up with DMARC, = p=3Dquarantine was designed as a stepping stone in the journey towards = p=3Dreject. In that view, the high support costs of p=3Dquarantine were = tolerable because p=3Dquarantine was meant to be a temporary situation = for the sender domain Owner. Now that p=3Dreject is a dead end for all = practical purposes, p=3Dquarantine has less and less utility. Only = p=3Dnone is safe to use unless you do not have real people as users. We must work hard to find a solution which makes p=3Dreject a viable = setting which can be reliably relied on. Regards, J.Gomez From nobody Wed Mar 25 12:30:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2F51B2A02 for ; Wed, 25 Mar 2015 12:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM8NVDYiVJaS for ; Wed, 25 Mar 2015 12:30:09 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDAB1A8A76 for ; Wed, 25 Mar 2015 12:30:09 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 354F0876F for ; Wed, 25 Mar 2015 20:30:06 +0100 (CET) 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; Wed, 25 Mar 2015 20:30:05 +0100 Message-ID: From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <14592.1427231989@vindemiatrix.encs.concordia.ca> <5876FB0C-2570-447D-8694-F39E06FBA64A@wordtothewise.com> Date: Wed, 25 Mar 2015 20:30:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 19:30:10 -0000 On Tuesday, March 24, 2015 10:32 PM [GMT+1=3DCET], Steve Atkins wrote: > Mailing lists are only an issue if the domain owner of the > email addresses of the participants have published a > DMARC p=3Dreject record, despite having actual users who > are legitimate source of email that fails authentication. >=20 > That's a small enough set of domains at the moment (I can think > of about five) that there are several obvious solutions for mailing > lists - a blacklist of DMARC records to treat specially would be > the simplest, though something more nuanced might be better. That "blacklist of DMARC records [with p=3Dreject] to treat specially" = I'm afraid is a solution which will not scale. You say there are now = "about five" of such domains. Well, about five big enough for everyone = to notice them, but surely there are many more which are small enough to = fly under our radar. It would take just some more data breaches and we might get to a = "blacklist for DMARC records with p=3Dreject" in the form of: "*" ;-) Regards, J.Gomez From nobody Wed Mar 25 12:58:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0261A89AD for ; Wed, 25 Mar 2015 12:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.998 X-Spam-Level: * X-Spam-Status: No, score=1.998 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsncTeN41CVH for ; Wed, 25 Mar 2015 12:58:16 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5A51AD06C for ; Wed, 25 Mar 2015 12:58:15 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id D61D6876F for ; Wed, 25 Mar 2015 20:58:10 +0100 (CET) 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; Wed, 25 Mar 2015 20:58:10 +0100 Message-ID: <0AC29004CB4D430A82F4D9375297A255@fgsr.local> From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local><87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp><102A355F80204C6C8F84DAECDA118C2E@fgsr.local><87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 25 Mar 2015 20:58:23 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 19:58:17 -0000 Hi, Murray. (Aside: Your email client is sending messages in "multipart/alternative" = format, but then its "text/plain" section has the quoting broken... = Could you fix that, please? I had to manually add ">>" below to = differentiate your text from mine, I hope I didn't gaffe it...) ---- Original Message ---- From: Murray S. Kucherawy To: J. G=C3=B3mez Cc: dmarc@ietf.org Sent: Tuesday, March 24, 2015 10:01 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez wrote: >=20 >> I know for sure I will publish only p=3Dnone for my client's domains, >> and use DMARC only as a reporting tool, as long as DMARC's p=3Dreject >> cannot be reliably relied on. But I would love to be able to reliably >> rely on DMARC's p=3Dreject. =20 >=20 > I'm not sure I agree with the claim that p=3Dreject is unreliable. It > seems to me that it's working as designed, and the results are > deterministic. It's not flaky. How receivers use it is the mushy > part, but that's really outside of the protocol. =20 The set (DMARC + p=3Dreject) is unreliable, in the current situation, = because it fails to describe the legitimate and real scenario of mailing = lists. > Even if DMARC didn't have these mediator problems, there still would > be no ultimate compulsion for receivers to do what domain owners ask. > It might be a lot more likely that they would comply without > reservations, but there would still be some operators that don't. =20 >=20 > So just to be clear, are you using "reliable" here to talk about how > receivers apply it?=20 No. It is "unreliable" for Receivers to apply it. Sure, for the Sender = p=3Dreject is perfectly reliable, if he happens to have all his ducks = neatly in a row. But the Receiver cannot know if the Sender has all his = ducks neatly in a row when said Sender publishes p=3Dreject. Question = that the Receiver asks to himself: Is the Sender aware of p=3Dreject = drawbacks and can therefore the Receiver rely on the Sender's declared = p=3Dreject? Answer to that question: The Receiver has no way to know, = therefore p=3Dreject is unreliable from the point of view of the = Receiver, irrespective of what the Receiver ultimately decides to do = with the Sender's declared p=3Dreject. Regards, J.Gomez From nobody Wed Mar 25 14:04:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38571A8AAF for ; Wed, 25 Mar 2015 14:04:36 -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 LRX6Cn3RnPHK for ; Wed, 25 Mar 2015 14:04:35 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6398A1A8AB3 for ; Wed, 25 Mar 2015 14:04:35 -0700 (PDT) Received: by wgs2 with SMTP id 2so42302977wgs.1 for ; Wed, 25 Mar 2015 14:04:34 -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=v4unDgnNl4IsdGBHvsXIbsh6neaq3xBHqb3tdcRQIlQ=; b=FF+ogF6LGiuIpP0oIbI/06DF+pF7ftvMlQTZrTdAFdGFb2/t5o5TuAqUN16vol8ycA uv0God9L1qVb0VqLBZ1FMHCXrjuJc0PSoVI/5fDD+G8rdD+/inhcdxaKmpkZSN4K2Iv3 mhMmEw8SKa0uRzy7foaay80ST7+W1ShA2EhG+5+zZbrYIKUU2zMsUim5REKOL0Bv7qGq /VSfwFxihOTUzBOEVUbjCzqGJAh4HjxD2fyHZKQuSkJSKs1y8hsSMMPgzk5iYsQphNF5 exRqm+6roueJvJdQUirlRjVQm9qCaqTQEod0XDrYY0rvJfviYbRG12P+dyruWd26bfAT bSpw== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr21850454wjc.135.1427317474052; Wed, 25 Mar 2015 14:04:34 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Wed, 25 Mar 2015 14:04:33 -0700 (PDT) In-Reply-To: <0AC29004CB4D430A82F4D9375297A255@fgsr.local> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp> <102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> <0AC29004CB4D430A82F4D9375297A255@fgsr.local> Date: Wed, 25 Mar 2015 14:04:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7bd6adce05d2640512233ffb Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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: Wed, 25 Mar 2015 21:04:36 -0000 --047d7bd6adce05d2640512233ffb Content-Type: text/plain; charset=UTF-8 On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez wrote: > No. It is "unreliable" for Receivers to apply it. Sure, for the Sender > p=reject is perfectly reliable, if he happens to have all his ducks neatly > in a row. But the Receiver cannot know if the Sender has all his ducks > neatly in a row when said Sender publishes p=reject. Question that the > Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can > therefore the Receiver rely on the Sender's declared p=reject? Answer to > that question: The Receiver has no way to know, therefore p=reject is > unreliable from the point of view of the Receiver, irrespective of what the > Receiver ultimately decides to do with the Sender's declared p=reject. > I think you're actually saying exactly what I thought you meant. Thanks for confirming. I just wanted to be clear for context. -MSK --047d7bd6adce05d2640512233ffb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez <jgomez@sery= rich.com> wrote:
No. It is "unreliable"= ; for Receivers to apply it. Sure, for the Sender p=3Dreject is perfectly r= eliable, if he happens to have all his ducks neatly in a row. But the Recei= ver cannot know if the Sender has all his ducks neatly in a row when said S= ender publishes p=3Dreject. Question that the Receiver asks to himself: Is = the Sender aware of p=3Dreject drawbacks and can therefore the Receiver rel= y on the Sender's declared p=3Dreject? Answer to that question: The Rec= eiver has no way to know, therefore p=3Dreject is unreliable from the point= of view of the Receiver, irrespective of what the Receiver ultimately deci= des to do with the Sender's declared p=3Dreject.
<= br>
I think you're actually saying exactly what I thought you= meant.=C2=A0 Thanks for confirming.=C2=A0 I just wanted to be clear for co= ntext.

-MSK
--047d7bd6adce05d2640512233ffb-- From nobody Wed Mar 25 19:08:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197F51B2B10 for ; Wed, 25 Mar 2015 19:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.303 X-Spam-Level: X-Spam-Status: No, score=-98.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=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 2OZqnSsSJUNw for ; Wed, 25 Mar 2015 19:08:49 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 818C71B2A5C for ; Wed, 25 Mar 2015 19:08:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4032; t=1427335721; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=f6dARq8GkaciWFyPwo09IEP+sOQ=; b=fxmyY9bZaYuIFmOgKZox 7l8COghRQEswxxnCNz7rdcui9A4BXCSmjiVjjW8scyjvRh4G0sNPV3fjQO+VynvY W/z4emW6VgZQvpHMWGZ3rO1AvfeBUhqBFwTkVCyI/Sztsh0KyOZqvq0LX5p+NSAf ZOZJnC2uIUuVxtEoT74PsiM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 25 Mar 2015 21:08:41 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1045756018.1.2600; Wed, 25 Mar 2015 21:08:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4032; t=1427335520; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KA04OB3 nOLk7vy8IVBTyfABzC+WsJPC9H6VxwHwpe3Y=; b=fVaRhTfzc1NhYL1f1iQ6Cet JfRNg+fPcaIDQ0kB32ilLwQXTRzNgxWgI2nV9yRhcMkkDZSp8x5P4s5DcSvw2CU9 aelOhgRU33tDh6WJTwfb3GEo0b+m2DkMr4Ih1SawLSLoEAJDyW0MdtUvHLvtiD5S cK3aqNUBartrpW7Znqr4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 25 Mar 2015 22:05:20 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3933022941.9.5768; Wed, 25 Mar 2015 22:05:19 -0400 Message-ID: <55136A23.8080306@isdg.net> Date: Wed, 25 Mar 2015 22:08:35 -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: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 02:08:52 -0000 Mr. Gomez, Traditionally, many in the IETF and the mail industry had an aversion towards strong deterministic transport (system) level filtering ideas. This is burned into RFC2821/5321: 7. Security Considerations 7.1 Mail Security and Spoofing This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. The text different between 2821 and 5321 is that the "user" is no longer "ignorant." Many preferred to pass the buck to the user for making decisions on what is considered accepted mail. The DMA, the "Spammer" world, good or bad, want you to ACCEPT the mail to pass to the user. CAN-SPAM also plays a role here too in the area of User Vendor contracts. So in general, whenever we had new strong deterministic rejection protocols, we had the friction of dealing with "ACCEPT/SEPARATE" or "Quarantine" ideas embedded as well as means to reduce the potential false positive nature of rejection policies. Case in point with SPF. SPF had a strong REJECTION concept with RFC4408 and with the latest spec RFC7202, it was relaxed with allowing for quarantining ideas (mail separation). RFC7208 made RFC4408 more costly by adding more complexity for an "ACCEPT/SEPARATE" mode of operation for failed SPF messages as opposed to just REJECTING failed SPF messages. Part of the problem is that the idea of quarantine does presumed a backend mail storage design that mail separation was even possible. It is not an universal concept to have this multiple mail folders idea, ability and/or MUA/UI infrastructure for end-users. So in that vain, it does come with a high support and also high implementation cost to include Mail Quarantine functionality into a specification. REJECTION is a must lower design implementation cost. In theory, rejection or quarantine, both must provide the same end of result of protecting users from harm and also the domain from being exploited. If you are going to quarantine mail instead of rejecting it, then you need to make sure the USER does not get the mail directly in the natural in-box, including the POP3 mail stream -- it must not be part of the pick up. -- HLS On 3/25/2015 3:17 PM, J. Gomez wrote: > On Tuesday, March 24, 2015 10:08 PM [GMT+1=CET], MH Michael Hammer (5304) wrote: > >>> On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote: >>> >>>> ... and again, if those decisions result merely in rejecting a >>>> message, the user isn't involved, but as soon as those decisions >>>> can result in tagging a message for possible consideration by the >>>> user (probably via different display by the UI), we can't ignore >>>> the user. >>>> >>>> I agree that this isn't the place to delve deeply into user >>>> behaviour and UI design. But we shouldn't ignore the context of >>>> our work. >>> >>> +1 >>> >>> Email is for the users. p=quarantine is a USER PROBLEM. >>> >> >> No, p=quarantine is a problem WE cause. > > Yes, but a problem that ultimately the user gets directly planted before his eyes, and which the user has to roll up his sleeves to deal with as well/bad as he can possibly manage. > > Translation: p=quarantine has vey high support costs. > > As I understand it, in the beginning of the coming up with DMARC, p=quarantine was designed as a stepping stone in the journey towards p=reject. In that view, the high support costs of p=quarantine were tolerable because p=quarantine was meant to be a temporary situation for the sender domain Owner. Now that p=reject is a dead end for all practical purposes, p=quarantine has less and less utility. Only p=none is safe to use unless you do not have real people as users. > > We must work hard to find a solution which makes p=reject a viable setting which can be reliably relied on. > > Regards, > J.Gomez From nobody Wed Mar 25 20:08:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C9C1A700C for ; Wed, 25 Mar 2015 20:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.809 X-Spam-Level: * X-Spam-Status: No, score=1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, 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 TAt5yiHWKoWM for ; Wed, 25 Mar 2015 20:08:47 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F41A0169 for ; Wed, 25 Mar 2015 20:08:46 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id C8F901C38D9; Thu, 26 Mar 2015 12:08:45 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A7857120EC9; Thu, 26 Mar 2015 12:08:45 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <0AC29004CB4D430A82F4D9375297A255@fgsr.local> References: <20150322202500.37229.qmail@ary.lan> <5E5C3A995E284B9CBBF78B561D56B416@fgsr.local> <87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp> <11B0614056784A5F816F99A3C1E46B13@fgsr.local> <87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp> <102A355F80204C6C8F84DAECDA118C2E@fgsr.local> <87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp> <0AC29004CB4D430A82F4D9375297A255@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 26 Mar 2015 12:08:45 +0900 Message-ID: <87a8z0laki.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 03:08:49 -0000 J. Gomez writes: > >> But I would love to be able to reliably rely on DMARC's > >> p=reject. Even if you can in practice, you can't get to 100.0%. Even at ducks-in-a-row sites like (which is a financial institution and uses that domain for transactional mailflows), has at least once used his/her "p=reject" address to post to a mailing list I subscribe to (which didn't implement DMARC). These things happen. It's possible that the rate of occurance is low enough that you would be happy to set your receiving MTA to reject that post because it failed alignment with the "p=reject" domain. But I might not, preferring to rely on a filter that weights "reject legitimate" (eg, "reject existing correspondent") far more negatively than yours does. Of course it's up to you what you do. I'm just saying that the protocol needs to deal with extreme preferences like the ones I (hypothetically) attribute to myself. > The set (DMARC + p=reject) is unreliable, in the current situation, > because it fails to describe the legitimate and real scenario of > mailing lists. Technically, it does describe them: author domains "should not" use p=reject if it authorizes indirect mailflows From its mailboxes. AOL and Yahoo! were abusing p=reject according to the draft of April 2014. The reason I bring this up is that I find it hard to imagine a world in which, even after that experience, non-transactional mailflows currently covered by p=none would have all of their third party relays registered with a third-party authorization protocol. On the other hand botnets mean that draft-kucherawy-dkim-delegate and draft-levine-dkim-conditional can be massively exploited if ordinary users at those sites are allowed to use those mechanisms without oversight by the author domain. So I suspect that a registry of third parties is an essential precondition for p=reject to be compatible with open-subscription mailing lists. AFAICS, that means that any such protocol is going to be unreliable in the face of a security breach like those at AOL and Yahoo!. Of course you could imagine a world where everybody implements DMARC and p=none doesn't exist. Then Mediators must register or their messages won't be delivered, period. But to me, that's not email. :-( From nobody Thu Mar 26 12:51:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5E61B2AC5 for ; Thu, 26 Mar 2015 12:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJENdF2lAEhn for ; Thu, 26 Mar 2015 12:51:49 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1491B2E29 for ; Thu, 26 Mar 2015 12:51:34 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id AE23986B4 for ; Thu, 26 Mar 2015 20:51:33 +0100 (CET) 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, 26 Mar 2015 20:51:33 +0100 Message-ID: From: "J. Gomez" To: References: <20150322202500.37229.qmail@ary.lan><5E5C3A995E284B9CBBF78B561D56B416@fgsr.local><87egogntdq.fsf@uwakimon.sk.tsukuba.ac.jp><11B0614056784A5F816F99A3C1E46B13@fgsr.local><87vbhrmczm.fsf@uwakimon.sk.tsukuba.ac.jp><102A355F80204C6C8F84DAECDA118C2E@fgsr.local><87a8z2mkyo.fsf@uwakimon.sk.tsukuba.ac.jp><0AC29004CB4D430A82F4D9375297A255@fgsr.local> <87a8z0laki.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 26 Mar 2015 20:51:45 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 19:51:51 -0000 On Thursday, March 26, 2015 4:08 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > > > But I would love to be able to reliably rely on DMARC's > > > > p=3Dreject. >=20 > Even if you can in practice, you can't get to 100.0%. Even at > ducks-in-a-row sites like > (which is a financial institution and uses that domain for > transactional mailflows), has at least > once used his/her "p=3Dreject" address to post to a mailing list I > subscribe to (which didn't implement DMARC). These things happen. Yes, but then in that DMARC rejection which you describe above the = Receiver can blame it on the Sender, who did not put his ducks neatly in = a row as he should have done. The question is: who bears the cost of DMARC's p=3Dreject "false = positives"? As a Receiver, I will be blind and will not obey to Sender's = p=3Dreject unless I can blame on said Sender the rejection --derived = form the Sender's declared DMARC of p=3Dreject-- of legitimate email. > > The set (DMARC + p=3Dreject) is unreliable, in the current = situation, > > because it fails to describe the legitimate and real scenario of > > mailing lists. >=20 > Technically, it does describe them: author domains "should not" use > p=3Dreject if it authorizes indirect mailflows From its mailboxes. = AOL > and Yahoo! were abusing p=3Dreject according to the draft of April = 2014. That Yahoo and AOL are "abusing p=3Dreject" is a way to see the case. = Another way to see it, is that DMARC's p=3Dreject fails to describe real = email usage, and therefore is unreliable (i.e., cannot be relied on). Regards, J.Gomez From nobody Thu Mar 26 13:21:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9001B2E7D for ; Thu, 26 Mar 2015 13:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT5f-dr_jmKi for ; Thu, 26 Mar 2015 13:21:38 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id AD8811B2E7C for ; Thu, 26 Mar 2015 13:21:38 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 0AFB886B4 for ; Thu, 26 Mar 2015 21:21:37 +0100 (CET) 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, 26 Mar 2015 21:21:36 +0100 Message-ID: <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> Date: Thu, 26 Mar 2015 21:21:48 +0100 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: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 20:21:39 -0000 On Thursday, March 26, 2015 3:08 AM [GMT+1=3DCET], Hector Santos wrote: > SPF had a strong REJECTION concept with RFC4408 and with the latest > spec RFC7202, it was relaxed with allowing for quarantining ideas > (mail separation). RFC7208 made RFC4408 more costly by adding more > complexity for an "ACCEPT/SEPARATE" mode of operation for failed SPF > messages as opposed to just REJECTING failed SPF messages. >=20 > Part of the problem is that the idea of quarantine does presumed a > backend mail storage design that mail separation was even possible. > It is not an universal concept to have this multiple mail folders > idea, ability and/or MUA/UI infrastructure for end-users. So in that > vain, it does come with a high support and also high implementation > cost to include Mail Quarantine functionality into a specification. > REJECTION is a must lower design implementation cost. +1. For Google/Hotmail/big-ESP, the support costs are already accounted for = in their cost structure. For small or "boutique" Email Service = Providers, support costs are very important and can grow very fast: an = user has a problem with suspect or missing email?, we go on-site, we = hand-hold them, we give face, we remote into their system and get to = deal with the mess, we do whatever until the troubled user finds = peace... If DMARC is going to increase support costs for small email operators, I = may as well migrate all my clients to Google Apps or Office 365 and be = done with costly email. That is why, in my view, DMARC's p=3Dreject has to either be reliable to = be relied on, or be suppressed from DMARC's formal specification if it = is going to mainly be equal to p=3Ddo-whatever. Regards, J.Gomez From nobody Thu Mar 26 14:37:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3933B1B2F5B for ; Thu, 26 Mar 2015 14:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_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 JLx73VrTDSni for ; Thu, 26 Mar 2015 14:37:03 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id BFC801B2B56 for ; Thu, 26 Mar 2015 14:37:02 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 032E956411E; Thu, 26 Mar 2015 16:37:02 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DE6DFA02F9; Thu, 26 Mar 2015 16:37:01 -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 MrA53jlBZS4r; Thu, 26 Mar 2015 16:37:01 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 602FDA0455; Thu, 26 Mar 2015 16:37:01 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 602FDA0455 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427405821; bh=NB5drncLmsMCEavEoXCm5reHL+oK5KUbiiG4E9BKMvk=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Wok6OQubPk/tLJqiNbSEPEn+/YfFrDDuJyjuc3vyN+ZBXN95310Air7EH0NpeVEj6 0hBZzMQUGUZPXSY7yuH2Tv/aJlTCm+mcVBnRFSS+imOZKNxQ26PM9GYy6vKjU8TkZ/ hPVgeBWh5/F5auWF3jP0x2h+QcKZj88SiMEJms7I= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2CDA4A044A; Thu, 26 Mar 2015 16:37:01 -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 75EShe4dGSkZ; Thu, 26 Mar 2015 16:37:01 -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 E0BDDA02F9; Thu, 26 Mar 2015 16:37:00 -0500 (CDT) Date: Thu, 26 Mar 2015 16:37:00 -0500 (CDT) From: Franck Martin To: "J. Gomez" Message-ID: <1597566326.102415.1427405820388.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: Next steps for RFC 7489 (DMARC) Thread-Index: sdZDcAtgv5QX3LJR4N9hhNOhfS6dTA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 21:37:04 -0000 ----- Original Message ----- > From: "J. Gomez" > That is why, in my view, DMARC's p=reject has to either be reliable to be > relied on, or be suppressed from DMARC's formal specification if it is going > to mainly be equal to p=do-whatever. > when you see a p=reject and DMARC tells you, you should bounce the email, then just bounce it. Why? 1) there are reports to tell the sender why you bounced the email. And it should get the bounce too. If it is not what the sender wants, he has all the tools to assess if it was important for the receiver to receive this message or not and what can the sender do to change that. 2) Mailing lists should be able to differentiate between an Hard bounce and a Soft bounce (by now). http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml is 7 years old now. If you do anything else, it is because you want to be nice to the sender. (pulling leg here) From nobody Thu Mar 26 15:23:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A2E1A016C for ; Thu, 26 Mar 2015 15:23:11 -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 1fNFWhlkue0Z for ; Thu, 26 Mar 2015 15:23:10 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477421A0104 for ; Thu, 26 Mar 2015 15:23:10 -0700 (PDT) Received: by wgra20 with SMTP id a20so79901034wgr.3 for ; Thu, 26 Mar 2015 15:23:09 -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=FVqu3CgHasBHxSRdoiMXfP4xy6ZJn9RZbv4DLH3pSkg=; b=XSIAPtTZw7e6Hav348vTUR679MTrrdufdD4Ad6CNIRzG2h02bbzR/puDe6qwETwo+8 DdXDmXeblp7O10tdHL2PiGJKpoBRkwSDqOba3VgHItZRD9U7ziGTwhds5iSfa2FalTtj ogrR5erabBGtM4m/BqCXuo3+rIsr+uaRbVpbhsa43AymuwYKaV7ENNvgsY2Hsygt6Xrl 1ji0eEhanr4Z/fsB62YYKO5s3RM+0DXU7pYjxiu5BhbpBrBU1dpjhv3cPQ/sE0QPb60v NYG1DJG8nFM/IGhQvVFdUTsEX6aKR00XcSH7molKRx7PP0gO4BAQjR7+9Div/5CwD1oK aGzA== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr32043736wjc.4.1427408589071; Thu, 26 Mar 2015 15:23:09 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Thu, 26 Mar 2015 15:23:08 -0700 (PDT) In-Reply-To: <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> Date: Thu, 26 Mar 2015 15:23:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=089e01419d1ce6ac4605123875d7 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 22:23:11 -0000 --089e01419d1ce6ac4605123875d7 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez wrote: > If DMARC is going to increase support costs for small email operators, I > may as well migrate all my clients to Google Apps or Office 365 and be done > with costly email. > > That is why, in my view, DMARC's p=reject has to either be reliable to be > relied on, or be suppressed from DMARC's formal specification if it is > going to mainly be equal to p=do-whatever. > Can anyone point to a single instance of a sender-receiver policy protocol that was "reliable" by this definition, enough that receivers would blindly agree to do whatever the sender asked/suggested/demanded? I can't think of any. Some, many, or most of them were supposed to be, but it has never turned out that way. I don't know why DMARC is being held to a different standard. -MSK --089e01419d1ce6ac4605123875d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
If DMARC is going to increase su= pport costs for small email operators, I may as well migrate all my clients= to Google Apps or Office 365 and be done with costly email.

That is why, in my view, DMARC's p=3Dreject has to either be reliable t= o be relied on, or be suppressed from DMARC's formal specification if i= t is going to mainly be equal to p=3Ddo-whatever.

=
Can anyone point to a single instance of a sender-receiver polic= y protocol that was "reliable" by this definition, enough that re= ceivers would blindly agree to do whatever the sender asked/suggested/deman= ded?

I can't think of any.=C2=A0 Some, many, or most = of them were supposed to be, but it has never turned out that way.=C2=A0 I = don't know why DMARC is being held to a different standard.

-MSK
--089e01419d1ce6ac4605123875d7-- From nobody Thu Mar 26 16:12:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA11A1A78 for ; Thu, 26 Mar 2015 16:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61lHfE1epmZ4 for ; Thu, 26 Mar 2015 16:12:17 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 816131A1A6E for ; Thu, 26 Mar 2015 16:12:17 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2QNCE0N015822; Thu, 26 Mar 2015 19:12:14 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2QNCDeF002084; Thu, 26 Mar 2015 19:12:13 -0400 Message-Id: <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Murray S. Kucherawy" From: Michael Jack Assels In-reply-to: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636! 8@fgsr.local> Comments: In-reply-to "Murray S. Kucherawy" message dated "Thu, 26 Mar 2015 15:23:08 -0700." Date: Thu, 26 Mar 2015 19:12:13 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-26 19:12:14 EDT Archived-At: Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 23:12:19 -0000 On Thu, 26 Mar 2015 15:23:08 PDT, "Murray S. Kucherawy" wrote: > On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez wrote: > > > If DMARC is going to increase support costs for small email operators, I > > may as well migrate all my clients to Google Apps or Office 365 and be done > > with costly email. > > > > That is why, in my view, DMARC's p=reject has to either be reliable to be > > relied on, or be suppressed from DMARC's formal specification if it is > > going to mainly be equal to p=do-whatever. > > Can anyone point to a single instance of a sender-receiver policy protocol > that was "reliable" by this definition, enough that receivers would blindly > agree to do whatever the sender asked/suggested/demanded? > > I can't think of any. Some, many, or most of them were supposed to be, but > it has never turned out that way. I don't know why DMARC is being held to > a different standard. Isn't DMARC holding itself to a different standard? What's a receiver supposed to do with unaligned mail whose "From:" domain specifies p=reject? Clearly, the domain owner is explicitly asking that the message be rejected. If DMARC intends that this be merely one of many factors to consider, then doesn't it boil down to nothing more than p=do-whatever? Yes, I know that receivers can and will do as they please, but some receivers would be pleased as punch to cooperate in a scheme that gave solid proof of a message's illegitimacy in every case where it was asserted. The problem is that publishing p=reject effectively asserts that almost all submissions to mailing lists by users in the domain are illegitimate, and I'm afraid the real world doesn't believe that to be the case. That's not to say that DMARC should change anything about itself. It's just recognition that making it a great success will depend on someone finding a way to let mailing lists collaborate with DMARC without alienating their list users, owners or managers. I'd love to announce that I've found the way, but I'm as befuddled as anyone else. MJA From nobody Thu Mar 26 16:22:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD801A1AD3 for ; Thu, 26 Mar 2015 16:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] 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 20N62yhMuea2 for ; Thu, 26 Mar 2015 16:22:48 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id EB1D41A1A7C for ; Thu, 26 Mar 2015 16:22:47 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 7EFB056419B; Thu, 26 Mar 2015 18:22:45 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 64B07A043E; Thu, 26 Mar 2015 18:22: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 C1L4P41FlhKU; Thu, 26 Mar 2015 18:22:45 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 12B00A0455; Thu, 26 Mar 2015 18:22:45 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 12B00A0455 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427412165; bh=iIZyO4DSPose4j3K56V4P6/6BzGblS3Kmd0fI4T9hBo=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Bj9x2takBhy58ZwU3T2e/9jRbgorb2UJg1GoXpb+DPZ5D9diD4L20ZIRH9+Hk4FjD ZwyyI8BdIlnEK1xWhtAQPbSrvyUr06muTdQ04cZP1XOR+27eFj1hwXauqV7VKJo+X9 +U/n53mJJh4jjJWtLuuWUjiCEw0OigDMyrDByRSs= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D4F9BA044A; Thu, 26 Mar 2015 18:22:44 -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 gJMH0dXzISi1; Thu, 26 Mar 2015 18:22:44 -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 AFE74A043E; Thu, 26 Mar 2015 18:22:44 -0500 (CDT) Date: Thu, 26 Mar 2015 18:22:44 -0500 (CDT) From: Franck Martin To: Michael Jack Assels Message-ID: <749714311.104610.1427412164449.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636!8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: Next steps for RFC 7489 (DMARC) Thread-Index: QCs395A5GYk/qEAy7YRFIAuT0zubqQ== Archived-At: Cc: dmarc@ietf.org, "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 23:22:49 -0000 ----- Original Message ----- > From: "Michael Jack Assels" > To: "Murray S. Kucherawy" > Cc: dmarc@ietf.org, "J. Gomez" > Sent: Thursday, March 26, 2015 4:12:13 PM > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > On Thu, 26 Mar 2015 15:23:08 PDT, > "Murray S. Kucherawy" wrote: > > > On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez wrote: > > > > That's not to say that DMARC should change anything about itself. It's > just recognition that making it a great success will depend on someone > finding a way to let mailing lists collaborate with DMARC without > alienating their list users, owners or managers. > You can't please everyone at the moment, and there are solutions to please various subsets of your lists. I'm on various mailings lists, some friendly to DMARC, some not, with email with a domain with p=reject, or not... What I learn for all the combinations: It does not change much, people still ignore my posts :P From nobody Thu Mar 26 16:38:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7F1A6F38 for ; Thu, 26 Mar 2015 16:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn5lxeqDXKy2 for ; Thu, 26 Mar 2015 16:38:15 -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 F06001A6EE8 for ; Thu, 26 Mar 2015 16:38:14 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id t2QNc6u0075234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 26 Mar 2015 16:38:11 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com t2QNc6u0075234 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1427413091; bh=XASukVeQ8zB5J0m3GZ95slbn2rWGOtoLNVMlJkLcpwg=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WKLQ3U/D1ENQneT5dE0C9HIBK6iPEidiKsueddzzpcOCn74wlK2nhDidwr+A6zlnn bGvL7VokZZA/RwSc68x1Ya3EzAPz2mtcrgPLqgPkb0Vtx6yZ3tTjo0EHqncdcCpqUO rppdy5OcA3mwN/wFA1RX74UAhai44zm9wdhKL5Qo= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <55149860.5010808@crash.com> Date: Thu, 26 Mar 2015 16:38:08 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150318200459.23F9B18020A@rfc-editor.org> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636!8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <749714311.104610.1427412164449.JavaMail.zimbra@peachymango.org> In-Reply-To: <749714311.104610.1427412164449.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=windows-1252 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]); Thu, 26 Mar 2015 16:38:11 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 23:38:19 -0000 On 03/26/2015 04:22 PM, Franck Martin wrote: > > What I learn for all the combinations: It does not change much, people > still ignore my posts :P Franck, that's waaaay outside the charter of this working group... From nobody Thu Mar 26 16:46:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2EC1A7113 for ; Thu, 26 Mar 2015 16:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P5a26lt6591 for ; Thu, 26 Mar 2015 16:46:12 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5C21A702C for ; Thu, 26 Mar 2015 16:46:11 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id A3E2E563FF7; Thu, 26 Mar 2015 18:46:10 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 90EA0A0298; Thu, 26 Mar 2015 18:46:10 -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 pb7F9ToLUQR9; Thu, 26 Mar 2015 18:46:10 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5D68FA0455; Thu, 26 Mar 2015 18:46:10 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 5D68FA0455 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427413570; bh=rJuRTQuQGaRYtejtkFU5UIE1RaElyUUzljL9sRUvjFw=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Psts4nVoAQuIeawXFt5Rg+mN3Gb7b9DU0Q9lIyDNVicQh8TcqkKAN7eNvWEyjGqbF gI2kWUIgg5AsuJi2YNNKsW0oQagSK9GoFG24+1oFBkQaFlvp4HzjJb7sS50mq9zrcJ VfICKJ502ka9vjqZ6pg+FllUXQTMlKcbTPeBaJA8= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3CE98A044A; Thu, 26 Mar 2015 18:46:10 -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 GolGXdYPtZqT; Thu, 26 Mar 2015 18:46:10 -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 1E306A0298; Thu, 26 Mar 2015 18:46:10 -0500 (CDT) Date: Thu, 26 Mar 2015 18:46:09 -0500 (CDT) From: Franck Martin To: Steven M Jones Message-ID: <1739803029.105054.1427413569886.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <5B31A0C36E5D408A9A535511EACB636!8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <749714311.104610.1427412164449.JavaMail.zimbra@peachymango.org> <55149860.5010808@crash.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: Next steps for RFC 7489 (DMARC) Thread-Index: xrlJJ7hC2LoBlGYcCMdbGvLYvHglFA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (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, 26 Mar 2015 23:46:14 -0000 ----- Original Message ----- > From: "Steven M Jones" > To: dmarc@ietf.org > Sent: Thursday, March 26, 2015 4:38:08 PM > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > On 03/26/2015 04:22 PM, Franck Martin wrote: > > > > What I learn for all the combinations: It does not change much, people > > still ignore my posts :P > > Franck, that's waaaay outside the charter of this working group... > We were there a few posts back already... Can people please review the last version of https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ and comment? This document still needs some improvemments and its completion is a milestone to progress further. Thanks. From nobody Thu Mar 26 22:28:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471131A89C6 for ; Thu, 26 Mar 2015 22:28:22 -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 TIdhEziP7qzI for ; Thu, 26 Mar 2015 22:28:20 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6ED1A89B1 for ; Thu, 26 Mar 2015 22:28:19 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id B531C1C3898; Fri, 27 Mar 2015 14:28:18 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8F36B120EC9; Fri, 27 Mar 2015 14:28:18 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1597566326.102415.1427405820388.JavaMail.zimbra@peachymango.org> References: <20150318200459.23F9B18020A@rfc-editor.org> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> <1597566326.102415.1427405820388.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 27 Mar 2015 14:28:18 +0900 Message-ID: <87wq23j9fx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 05:28:22 -0000 Franck Martin writes: > 2) Mailing lists should be able to differentiate between an Hard > bounce and a Soft bounce (by now). > http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > is 7 years old now. They can, but the problem that caused collateral damage to subscribers is hard bounces, and "p=reject" is a hard bounce. Perhaps you mean discriminating between "technical hard bounces" and "policy hard bounces", but even there (a) I don't understand why you think there's a difference in the way the ML should treat them, and (b) many receiving sites deliberately conceal policy bounces, and especially the reason for them. From nobody Thu Mar 26 23:22:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516C1A8731 for ; Thu, 26 Mar 2015 23:22:07 -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 tY39gZafJUFQ for ; Thu, 26 Mar 2015 23:22:05 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 351191A0398 for ; Thu, 26 Mar 2015 23:22:05 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 697C61C381B; Fri, 27 Mar 2015 15:22:04 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4F1AF120EC9; Fri, 27 Mar 2015 15:22:04 +0900 (JST) From: "Stephen J. Turnbull" To: Michael Jack Assels In-Reply-To: <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636! 8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 27 Mar 2015 15:22:04 +0900 Message-ID: <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 06:22:08 -0000 Michael Jack Assels writes: > > I can't think of any. Some, many, or most of them were supposed > > to be, but it has never turned out that way. I don't know why > > DMARC is being held to a different standard. > > Isn't DMARC holding itself to a different standard? That's a reasonable interpretation given the choice of mood ("reject" is a command), but in the end it's untenable. As Murray says, "policy frameworks" have been tried before, and they just don't work for "generic" email, although they work very well (as indeed DMARC does) for several important, but restricted, mail flows. The problem with "generic" email is that the incentives of Author Domains which provide mailboxes for personal use are poorly aligned with the incentives of their mailboxes' users. Specifically, Author Domains consider spam-fighting priority one, and consider mailing lists and other indirect flows at best neutral, and often on net a nuisance, while their users want to participate freely in indirect flows (leaving the costs of spam-fighting up to the Author Domains). > What's a receiver supposed to do with unaligned mail whose "From:" > domain specifies p=reject? Whatever they want to. If they think they can do filtering better than the sender, they may choose to ignore it, and there's nothing that can be done about it. Furthermore, I don't see why anyone other than the receiver's mailbox users should care what the receiver chooses to do. > Clearly, the domain owner is explicitly asking that the message be > rejected. No, they are not, not in the case of AOL and Yahoo!. Representatives of both domains have thanked MLM developers for providing mitigations so that messages that in the normal (until DMARC) course of events would fail From alignment can be delivered to DMARC-participating receiving domains which (since DMARC) would reject them. Thus, Yahoo! and AOL are clearly taking the position that they would like those messages to be delivered. Hector, J. Gomez, Franck, and others take the position that the world has changed due to spam and phishing, and therefore "what *was* normal" is now irrelevant. The new norm is conform to DMARC and other dictatorial sender policy frameworks or you're part of the problem. I disagree. Spamming and phishing are the problem, traditional practices of mailing lists are not. > If DMARC intends that this be merely one of many factors to > consider, then doesn't it boil down to nothing more than > p=do-whatever? No, there is valuable information in the policy. As far as I can see, the semantics of "p=reject" are We have a serious spoofing problem. It is so serious compared to the potential damage due to rejecting legitimate messages that we accept all responsibility for nondelivery and collateral damage if you choose to reject. In the case of direct mail flows, the potential damage due to rejection of legitimate mail is very low, and the potential damage from accepting spoofed mail is extremely high. If you know that a mail flow is direct, as a receiver you'd be crazy not to reject, and as a sender you'd be crazy not to accept the responsibility for receivers rejecting. In the case of indirect flows, receivers may (or may not) want to prefer their judgment to that of the author domain, because often the expected damage from accepting is much lower, and the expected damage from rejecting much higher. > Yes, I know that receivers can and will do as they please, but some > receivers would be pleased as punch to cooperate in a scheme that > gave solid proof of a message's illegitimacy in every case where it > was asserted. Murray's point is that "proof of illegitimacy" is probably a pipe dream, as shown by past experience with "policy frameworks".[1] Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows in daily use by financial institutions and in other transactional mail flows. Footnotes: [1] Hector is right that they haven't really been tried, but I don't think the chance that they'll be tried in the future is high, because the reasons they've been hard to implement in the past remain true. The big problem is that policy frameworks proposed so far "work" only if you define "legitimacy" tautologically: if it gets past the policy framework, it's legit, else not. That's not what my users want, though. They want to receive the mail they want to receive, and otherwise not, and no policy framework so far has shown promise of implementing that. From nobody Thu Mar 26 23:23:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509331A1A7B for ; Thu, 26 Mar 2015 23:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_GREY=0.424] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX2AVI6BajKS for ; Thu, 26 Mar 2015 23:23:32 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1F91A0398 for ; Thu, 26 Mar 2015 23:23:32 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 2207C564208; Fri, 27 Mar 2015 01:23:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 13321A029E; Fri, 27 Mar 2015 01:23:32 -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 uuhiKGITAwrV; Fri, 27 Mar 2015 01:23:31 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6CDC6A0471; Fri, 27 Mar 2015 01:23:31 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 6CDC6A0471 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1427437411; bh=jZO6Nt9DfdbmSkgIr+/+D88ib5upRiUMhgHYBLXDHe4=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=q1kEmIbYtSSrR0X+SGNrLCbh1Q8eERba60yA8ygWZZ2hPiuglH8LLNlfAESJLeX89 tvoAnhBOVFj5JX7FoFuPjpf9v5Gmutg8IgSkAOpxCWilXm8jjBTRMlic9vCz5wZg9V LZYAFRSu/frYgDCIEIXI5QM2x5+OYbDDSuxq0q00= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4ED21A0346; Fri, 27 Mar 2015 01:23:31 -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 L-8_roocuNNN; Fri, 27 Mar 2015 01:23:31 -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 2B9D0A029E; Fri, 27 Mar 2015 01:23:31 -0500 (CDT) Date: Fri, 27 Mar 2015 01:23:30 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <1777464568.107555.1427437410883.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> <1597566326.102415.1427405820388.JavaMail.zimbra@peachymango.org> <87wq23j9fx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF36 (Mac)/8.0.5_GA_5839) Thread-Topic: Next steps for RFC 7489 (DMARC) Thread-Index: rOhXV3ENEsJpBS5Iwhng7Tny9d2peQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 06:23:34 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Thursday, March 26, 2015 10:28:18 PM > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > Franck Martin writes: > > > 2) Mailing lists should be able to differentiate between an Hard > > bounce and a Soft bounce (by now). > > http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > > is 7 years old now. > > They can, but the problem that caused collateral damage to subscribers > is hard bounces, and "p=reject" is a hard bounce. Perhaps you mean > discriminating between "technical hard bounces" and "policy hard > bounces", but even there (a) I don't understand why you think there's > a difference in the way the ML should treat them, and (b) many > receiving sites deliberately conceal policy bounces, and especially > the reason for them. There is: Temporary Failure: SMTP Status code 4xx (mainly): try again in a few minutes or on a different MX/IP Permanent Failure: SMTP Status code 5xx (mainly): don't try again, get the user to fix it and: Hard Bounce: "no such mailbox/user/email address here" (SMTP enhanced status code, like 5.1.1), usually a permanent failure Soft Bounce: "there may be a valid mailbox/user/email address here, but we are not accepting this email" (SMTP enhanced status code like 5.7.1), a permanent or temporary failure Before the SMTP enhanced error codes existed, you had to parse the text portion of the error message and tried to figure out what it meant. You still kind of do it today. http://help.campaignmonitor.com/topic.aspx?t=26#soft-vs-hard https://sendgrid.com/blog/email-bounce-management/ http://www.boogietools.com/Products/Linux/BounceStudioAPI/Email-Bounce-Boogie-Bounce-API-Categories.asp I admit, it is a bit of rocket science here, and if you can't deliver email reliably after several repeated soft bounces, then you should mark the email address as bounced and get the user to re-confirm it. Your mileage may vary. Also there is the notion of bouncing vs rejecting which I prefer to call asynchronous bounce vs synchronous bounce, because even when you reject, an email (bounce) is usually created to be placed in the mailbox of the sender to inform him/her the email was not sent. as for DMARC: http://tools.ietf.org/html/rfc7489#section-10.3 and AFAIK, the text portion of the current implementations I know of gives a hint, it is because of DMARC. I know mailman 3.0 has a better bounce management system, and I think it will be a separate library, which would be awesome, because it can be included in other open source projects. So when the mailing list recognize the bounce is due to DMARC, then it could either ignore the bounce, or mark that against the original sender rather than the receiver. No more collateral damage. From nobody Thu Mar 26 23:59:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7001A8AB0 for ; Thu, 26 Mar 2015 23:59:07 -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 WiLscbDEDtfJ for ; Thu, 26 Mar 2015 23:59:04 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800D71A8A7C for ; Thu, 26 Mar 2015 23:59:04 -0700 (PDT) Received: by wiaa2 with SMTP id a2so18455106wia.0 for ; Thu, 26 Mar 2015 23:59:03 -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=/kvJG4yZGBERHyuFWMG1fEWwNlsToTWycbxPVwqyzFg=; b=tT1Hkqq86vNsLsSlS5IeqAvVUzD65J7UeAkJIv6BkENIrZn1Cj+Lm0tvyzwAtbUVAC qCQbGWys6L6uUN0e/3SxysAyQPePg7+OqvbNXBW4+VCtZY1oNgQapXXiIr5SjIAeIZCV zO5qg3MPkHH5pGgikhoAieQG3vnjIqRBrBuzrH7mDTAllBThek8XQS5znGaopYC3Rklk zCPDzspHUyg/wRRxC/iLMLuhylnfTKDbcUMbJCn60p9Uo6bBFTVbTNaccZZA5cQaYARn AFp8qft/hF/YLkqYcJhxN8aorGR4RjoxNiDJXWSGz1HQkINlKXk3KjK3GXLl4Xjt7002 RpqQ== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr34744716wjc.4.1427439543260; Thu, 26 Mar 2015 23:59:03 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Thu, 26 Mar 2015 23:59:02 -0700 (PDT) In-Reply-To: <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 26 Mar 2015 23:59:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=089e01419d1cea1aad05123faac9 Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 06:59:07 -0000 --089e01419d1cea1aad05123faac9 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull wrote: > Murray's point is that "proof of illegitimacy" is probably a pipe > dream, as shown by past experience with "policy frameworks".[1] > Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows > in daily use by financial institutions and in other transactional mail > flows. > Put another way, you only really know something when DMARC, DKIM, SPF, etc. produce a passing result. (Due credit to Dave for this observation.) All of them have false negatives with respect to anything that's not a direct mail flow, so "fail" results don't tell you anything conclusive if you plan to accept any sort of mail that isn't direct. What Hector characterizes as a watering down of SPF with the publication of RFC7208 was merely this fact put into text, even though it's been true since RFC4408. > Footnotes: > [1] Hector is right that they haven't really been tried, but I don't > think the chance that they'll be tried in the future is high, because > the reasons they've been hard to implement in the past remain true. > I agree. And although Hector likes to ascribe considerable power and influence to me, I'm not the one standing in the way of their success. I would happily embrace any such solution that stood a chance of working. I, and others, simply ask some basic questions about scalability of such solutions, their complexity, and their ability to be "gamed", and then they never go anywhere because there simply aren't any good answers to those questions. Thinking I might be wrong, and since the same people insist I am, I published RFC6541 (ATPS) as an experimental draft to try to tackle the third-party problem, and made a free version of it available via open source. That was over three years ago. There has been exactly one site (one person, rather) that tried it besides me and reported back about its effectiveness. Though Doug will shortly claim that ATPS saw no uptake because it is "flawed", I also had a grand total of zero operators report that they were using it in any modified form or asking me to add this or that to it before they would deploy it to production. It wasn't just an idea, it was a reality, but nobody came to play. Policy and third-party solutions haven't failed because of some cabal keeping them from seeing the light of day, unless by "cabal" you mean "group of people who agree that this won't work." These are hard problems, and the last thing any of us should want to do is foist yet another blob onto the global email infrastructure that has not been properly vetted. If an idea doesn't stand up to scrutiny or gets no uptake, or can't even get consensus in a small working group, what prayer does it have for success on the greater Internet? I want to make things better, not worse. There are those among you that disagree, I know. Does anyone have actual data (not theory, not passion, but data) that any of the policy or third-party solutions we've discussed before can work, work just about everywhere, and work at scale? If the answer to that is "no" (or, as usual, silence), then I suggest this (still!) isn't a productive use of our precious time or energy. -MSK --089e01419d1cea1aad05123faac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull <s= tephen@xemacs.org> wrote:
Murray's point is = that "proof of illegitimacy" is probably a pipe
dream, as shown by past experience with "policy frameworks".[1] Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows
in daily use by financial institutions and in other transactional mail
flows.

Put another way, you only really= know something when DMARC, DKIM, SPF, etc. produce a passing result.=C2=A0= (Due credit to Dave for this observation.)=C2=A0 All of them have false ne= gatives with respect to anything that's not a direct mail flow, so &quo= t;fail" results don't tell you anything conclusive if you plan to = accept any sort of mail that isn't direct.=C2=A0 What Hector characteri= zes as a watering down of SPF with the publication of RFC7208 was merely th= is fact put into text, even though it's been true since RFC4408.
=C2= =A0
Footnotes:
[1]=C2=A0 Hector is right that they haven't really been tried, but I do= n't
think the chance that they'll be tried in the future is high, because the reasons they've been hard to implement in the past remain true.
=

I agree.=C2=A0 And although Hector likes t= o ascribe considerable power and influence to me, I'm not the one stand= ing in the way of their success.=C2=A0 I would happily embrace any such sol= ution that stood a chance of working.=C2=A0 I, and others, simply ask some = basic questions about scalability of such solutions, their complexity, and = their ability to be "gamed", and then they never go anywhere beca= use there simply aren't any good answers to those questions.=C2=A0 Thin= king I might be wrong, and since the same people insist I am, I published R= FC6541 (ATPS) as an experimental draft to try to tackle the third-party pro= blem, and made a free version of it available via open source.=C2=A0 That w= as over three years ago.=C2=A0 There has been exactly one site (one person,= rather) that tried it besides me and reported back about its effectiveness= .=C2=A0 Though Doug will shortly claim that ATPS saw no uptake because it i= s "flawed", I also had a grand total of zero operators report tha= t they were using it in any modified form or asking me to add this or that = to it before they would deploy it to production.=C2=A0 It wasn't just a= n idea, it was a reality, but nobody came to play.

Policy= and third-party solutions haven't failed because of some cabal keeping= them from seeing the light of day, unless by "cabal" you mean &q= uot;group of people who agree that this won't work."

=
These are hard problems, and the last thing any of us should want to d= o is foist yet another blob onto the global email infrastructure that has n= ot been properly vetted.=C2=A0 If an idea doesn't stand up to scrutiny = or gets no uptake, or can't even get consensus in a small working group= , what prayer does it have for success on the greater Internet?=C2=A0 I wan= t to make things better, not worse.

There are those among= you that disagree, I know.=C2=A0 Does anyone have actual data (not theory,= not passion, but data) that any of the policy or third-party solutions we&= #39;ve discussed before can work, work just about everywhere, and work at s= cale?=C2=A0 If the answer to that is "no" (or, as usual, silence)= , then I suggest this (still!) isn't a productive use of our precious t= ime or energy.

-MSK
--089e01419d1cea1aad05123faac9-- From nobody Fri Mar 27 00:02:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2E1A8A7C for ; Fri, 27 Mar 2015 00:02:10 -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 jg8b9oLX5r7Q for ; Fri, 27 Mar 2015 00:02:09 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B261A8AF3 for ; Fri, 27 Mar 2015 00:02:09 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so18508101wib.1 for ; Fri, 27 Mar 2015 00:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5pCYUKP8OhQ/AhvrZnKgJf71mCp3VDMJy055zoyb95o=; b=eF+ZpIeiHdfImO8HE7i8zlSH/yV5AWmJDpeqM79ixhySN6V7Kz98vq7EP52okzq9cc 9B43d9295bY50Jsit/g4+SnbzdOw7WpPrOTLoMCJPOQfBTk39VQcQY2ulpjHs3wmot2a TTl2hWOjuIj6WsNgZKTHU1O7QMVhUZfp2p1QaVu9ew19vCnBv/yeO85MKYSVPBcmghPd xwcTCN4I1ZLqE17Bq6i/aqETGGcH33tOwXVNZgs7kuKAE8HCDmHdZDv5odby9DuRz1Fb mlD2ptrMrMzrgwkJ9ik1SiMyto4+t4sbvTJjCYI9LpzC8w59KYqkrCz47OjSxtDNJhl3 22gw== MIME-Version: 1.0 X-Received: by 10.180.187.67 with SMTP id fq3mr31491742wic.59.1427439728279; Fri, 27 Mar 2015 00:02:08 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Fri, 27 Mar 2015 00:02:08 -0700 (PDT) In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Fri, 27 Mar 2015 00:02:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=001a11c38070f1479705123fb528 Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 07:02:11 -0000 --001a11c38070f1479705123fb528 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy wrote: > There are those among you that disagree, I know. Does anyone have actual > data (not theory, not passion, but data) that any of the policy or > third-party solutions we've discussed before can work, work just about > everywhere, and work at scale? If the answer to that is "no" (or, as > usual, silence), then I suggest this (still!) isn't a productive use of our > precious time or energy. > ...by which I mean we should really not spend any more time re-hashing the past, and instead focus on figuring out the future. I'm all for learning from our past mistakes, but I think we've gotten all the blood we're going to get out of that particular stone. -MSK --001a11c38070f1479705123fb528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
There are those among you that disagree, I know.= =C2=A0 Does anyone have actual data (not theory, not passion, but data) tha= t any of the policy or third-party solutions we've discussed before can= work, work just about everywhere, and work at scale?=C2=A0 If the answer t= o that is "no" (or, as usual, silence), then I suggest this (stil= l!) isn't a productive use of our precious time or energy.

...by which I mean we= should really not spend any more time re-hashing the past, and instead foc= us on figuring out the future.=C2=A0 I'm all for learning from our past= mistakes, but I think we've gotten all the blood we're going to ge= t out of that particular stone.

-MSK
--001a11c38070f1479705123fb528-- From nobody Fri Mar 27 00:48:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D561A9096 for ; Fri, 27 Mar 2015 00:48:50 -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 QlIBnJwejLpQ for ; Fri, 27 Mar 2015 00:48:48 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9303C1A1B27 for ; Fri, 27 Mar 2015 00:48:48 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9107F1C389C; Fri, 27 Mar 2015 16:40:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6BEA3120EC9; Fri, 27 Mar 2015 16:40:23 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 27 Mar 2015 16:40:23 +0900 Message-ID: <87pp7ukhw8.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 07:48:50 -0000 Murray S. Kucherawy writes: > Does anyone have actual data (not theory, not passion, but data) > that any of the policy or third-party solutions we've discussed > before can work, work just about everywhere, and work at scale? Speaking only for myself, at this stage I would accept *theory* that it *can work*, with the caveat that it must be accompanied by an analysis of all possible failure modes, and preferably with (theoretical :-) mitigations for the failures. I haven't seen anything like that, just handwaving about "if we implement the policy framework, spam will go away and the mailing lists will have to come to heel (ie, register with the author domains for 3rd party auth)." Again speaking for myself, I think it's inappropriate to ask for data about working at scale at this point (although that's a bridge that eentually needs to be crossed). From nobody Fri Mar 27 00:48:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574D51A1B27 for ; Fri, 27 Mar 2015 00:48:51 -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 ffByODbHIF8g for ; Fri, 27 Mar 2015 00:48:48 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 930C71A908E for ; Fri, 27 Mar 2015 00:48:48 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 87EDD1C3893; Fri, 27 Mar 2015 16:30:25 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 708F1120EC9; Fri, 27 Mar 2015 16:30:25 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1777464568.107555.1427437410883.JavaMail.zimbra@peachymango.org> References: <20150318200459.23F9B18020A@rfc-editor.org> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB6368@fgsr.local> <1597566326.102415.1427405820388.JavaMail.zimbra@peachymango.org> <87wq23j9fx.fsf@uwakimon.sk.tsukuba.ac.jp> <1777464568.107555.1427437410883.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 27 Mar 2015 16:30:25 +0900 Message-ID: <87r3sakicu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 07:48:51 -0000 Franck Martin writes: > Hard Bounce: "no such mailbox/user/email address here" (SMTP > enhanced status code, like 5.1.1), usually a permanent failure > Soft Bounce: "there may be a valid mailbox/user/email address here, > but we are not accepting this email" (SMTP enhanced status code > like 5.7.1), a permanent or temporary failure That's not the terminology we use around Mailman: a "hard bounce" is exactly a "permanent failure". I'll keep it in mind that you at least use the term differently here. Nor is the "soft bounce" as you define it useful if it is permanent (5.x.x). Even if the site admits it's a policy bounce, you have to parse the error text in hope of determining whether there's something wrong with the message (the next message might go through, even from the same author), or if the receiver doesn't like the mailing list (messages aren't going to go through period) or doesn't like the author (the next message might or might not go through, depending on the author). And usually it's useless for the purpose, so has to be passed on to the site admin for forensic analysis. And even that doesn't help with sites that deliberately don't use appropriate codes. I don't really see that (from a protocol standpoint) we're any better off than we were before the enhanced status codes for the purpose of determining whether to stop mail to or unsubscribe a bouncing address. From nobody Fri Mar 27 06:49:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74D51ACDDB for ; Fri, 27 Mar 2015 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5Okn8VCyS1z for ; Fri, 27 Mar 2015 06:49:34 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6186D1A8907 for ; Fri, 27 Mar 2015 06:49:34 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2RDnWv8006227; Fri, 27 Mar 2015 09:49:32 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2RDnWR4007660; Fri, 27 Mar 2015 09:49:32 -0400 Message-Id: <201503271349.t2RDnWR4007660@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Stephen J. Turnbull" From: Michael Jack Assels In-reply-to: <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636! ! 8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> Comments: In-reply-to "Stephen J. Turnbull" message dated "Fri, 27 Mar 2015 15:22:04 +0900." Date: Fri, 27 Mar 2015 09:49:32 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-27 09:49:32 EDT Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 13:49:37 -0000 On Fri, 27 Mar 2015 15:22:04 +0900, "Stephen J. Turnbull" wrote: > Michael Jack Assels writes: > > > What's a receiver supposed to do with unaligned mail whose "From:" > > domain specifies p=reject? > > Whatever they want to. If they think they can do filtering better > than the sender, they may choose to ignore it, and there's nothing > that can be done about it. Furthermore, I don't see why anyone other > than the receiver's mailbox users should care what the receiver > chooses to do. Right, but that leaves DMARC as just another factor to consider when calculating a spam score. Actually, it's a little better than that; it comes pretty close to the desired "really reliably reliable" for direct mail flows. > > Clearly, the domain owner is explicitly asking that the message be > > rejected. > > No, they are not, not in the case of AOL and Yahoo!. Representatives > of both domains have thanked MLM developers for providing mitigations > so that messages that in the normal (until DMARC) course of events > would fail From alignment can be delivered to DMARC-participating > receiving domains which (since DMARC) would reject them. Thus, Yahoo! > and AOL are clearly taking the position that they would like those > messages to be delivered. As I read it, that means AOL and Yahoo are taking the position that DMARC's p=reject is The Right Thing To Do, while accepting that it's going to give wrong answers for indirect mail flows, and that it's up to MLM developers (and other producers of indirect flows) to deal with it. > Hector, J. Gomez, Franck, and others take the position that the world > has changed due to spam and phishing, and therefore "what *was* > normal" is now irrelevant. The new norm is conform to DMARC and other > dictatorial sender policy frameworks or you're part of the problem. > > I disagree. Spamming and phishing are the problem, traditional > practices of mailing lists are not. > > > If DMARC intends that this be merely one of many factors to > > consider, then doesn't it boil down to nothing more than > > p=do-whatever? > > No, there is valuable information in the policy. As far as I can see, > the semantics of "p=reject" are > > We have a serious spoofing problem. It is so serious compared to > the potential damage due to rejecting legitimate messages that we > accept all responsibility for nondelivery and collateral damage if > you choose to reject. I can accept that that may be what p=reject means, but I can't take seriously the idea that domain owners with p=reject really do take all responsibility for nondelivery of legitimate messages. When one of my users bangs on my door demanding to know why her message message wasn't delivered, can I really refer her to a giant ESP for an explanation? I don't think so. I'd be happier to interpret "p=reject" as meaning Spoofing is a serious problem. With a very high degree of certainty, we assert that the message you're handling is not legitimate direct mail. Please take this into account when deciding whether to accept or reject the message. This is worth a lot, despite the fact that it leaves the receiver with two tasks: Determining the message is direct or indirect, and if indirect, determining whether it's legitimate. > > Yes, I know that receivers can and will do as they please, but some > > receivers would be pleased as punch to cooperate in a scheme that > > gave solid proof of a message's illegitimacy in every case where it > > was asserted. > > Murray's point is that "proof of illegitimacy" is probably a pipe > dream, as shown by past experience with "policy frameworks".[1] > Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows > in daily use by financial institutions and in other transactional mail > flows. I agree that absolute proof of illegitimacy for arbitrary messages is hopeless, but DMARC actually provides a decision procedure for legitimacy of in the restricted area of direct mail flows (assuming that mail from compromised accounts is "legitimate"). For DMARC participants, legitimacy and illegitimacy are equally easy to prove for transactional mail flows, and equally hard to prove for indirect flows. MJA From nobody Fri Mar 27 12:07:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1731A8852 for ; Fri, 27 Mar 2015 12:07:58 -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 hxvyHPfBzwAy for ; Fri, 27 Mar 2015 12:07:53 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1D1A8793 for ; Fri, 27 Mar 2015 12:07:53 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CED351C387A; Sat, 28 Mar 2015 04:07:51 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A68F7120EC9; Sat, 28 Mar 2015 04:07:51 +0900 (JST) From: "Stephen J. Turnbull" To: Michael Jack Assels In-Reply-To: <201503271349.t2RDnWR4007660@shadrach.encs.concordia.ca> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636! ! 8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> <201503271349.t2RDnWR4007660@shadrach.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 28 Mar 2015 04:07:51 +0900 Message-ID: <87lhiijm2g.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 19:07:58 -0000 Michael Jack Assels writes: > As I read it, that means AOL and Yahoo are taking the position that > DMARC's p=reject is The Right Thing To Do, while accepting that it's > going to give wrong answers for indirect mail flows, and that it's up > to MLM developers (and other producers of indirect flows) to deal with > it. First, I don't think that interpretation is tenable, because their explanations to us are along the lines of "we know that we're a little out of line, but we have no choice." Second, the relevant producers of indirect mail flows are not the MLMs. They generally produce a direct mail flow, albeit unaligned. It's the mailbox provider's own users who produce indirect mail flows, by posting to the mailing lists. > > No, there is valuable information in the policy. As far as I can see, > > the semantics of "p=reject" are > > > > We have a serious spoofing problem. It is so serious compared to > > the potential damage due to rejecting legitimate messages that we > > accept all responsibility for nondelivery and collateral damage if > > you choose to reject. > > I can accept that that may be what p=reject means, but I can't take > seriously the idea that domain owners with p=reject really do take > all responsibility for nondelivery of legitimate messages. When > one of my users bangs on my door demanding to know why her message > message wasn't delivered, can I really refer her to a giant ESP for > an explanation? I don't think so. No, of course you can't, because they'll tell her that's not what they intended, and that it wouldn't be a problem if the third party behaved well. However, you can tell her that the giant provider told the receiver not to accept her messages. That's what DMARC actually says, and that's why I phrase it "accept reponsibility". > I'd be happier to interpret "p=reject" as meaning > > Spoofing is a serious problem. With a very high degree of certainty, > we assert that the message you're handling is not legitimate direct > mail. Please take this into account when deciding whether to accept > or reject the message. There's only one problem with that interpretation, and that is that you don't need DMARC p=reject to make it: it's a logical deduction from the mere fact of lack of From alignment. > For DMARC participants, legitimacy and illegitimacy are equally > easy to prove for transactional mail flows, and equally hard to > prove for indirect flows. That's actually false. There are many indirect flows that don't cause signatures to be invalidated, such as Unix-style .forwards and GNU Mailman mailing lists configured with no subject tag, no header, and no footer. And that's where the shoe pinches for mailing lists: the absolutist advocates of sender policy blame the victim and say we should stop our traditional value-added practices so that posters from p=reject domains can have their posts delivered. From nobody Fri Mar 27 13:12:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B123E1A1B1D for ; Fri, 27 Mar 2015 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.598 X-Spam-Level: ** X-Spam-Status: No, score=2.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3kySPd6rkPZ for ; Fri, 27 Mar 2015 13:12:12 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 387891ABD37 for ; Fri, 27 Mar 2015 13:12:11 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id C440B8642 for ; Fri, 27 Mar 2015 21:12:09 +0100 (CET) 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, 27 Mar 2015 21:12:09 +0100 Message-ID: <467390B0CBE546D5B01DC76198C6A263@fgsr.local> From: "J. Gomez" To: References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636! 8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> Date: Fri, 27 Mar 2015 21:12:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 20:12:14 -0000 On Friday, March 27, 2015 12:12 AM [GMT+1=3DCET], Michael Jack Assels = wrote: > On Thu, 26 Mar 2015 15:23:08 PDT, > "Murray S. Kucherawy" wrote: >=20 > > On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez > > wrote:=20 > >=20 > > > That is why, in my view, DMARC's p=3Dreject has to either be > > > reliable to be relied on, or be suppressed from DMARC's formal > > > specification if it is going to mainly be equal to = p=3Ddo-whatever. > >=20 > > Can anyone point to a single instance of a sender-receiver policy > > protocol that was "reliable" by this definition, enough that > > receivers would blindly agree to do whatever the sender > > asked/suggested/demanded?=20 > >=20 > > I can't think of any. Some, many, or most of them were supposed to > > be, but it has never turned out that way. I don't know why DMARC > > is being held to a different standard. >=20 > Isn't DMARC holding itself to a different standard? What's a receiver > supposed to do with unaligned mail whose "From:" domain specifies > p=3Dreject? Clearly, the domain owner is explicitly asking that the > message be rejected. If DMARC intends that this be merely one of > many factors to consider, then doesn't it boil down to nothing more > than p=3Ddo-whatever? +1. As it currently is, p=3Dreject already means p=3Dquarantine or p=3Dnone, = so "do-whatever". We could try to add some extra --and defaulted to be empty/none-- = qualifier to the DMARC TXT record in order to optionally, at the = Sender's will, upgrade the plain old p=3Dreject to mean = "reject-and-yes-i-mean-it-always-dammit-i-dont-indulge-in-indirect-email-= flows", so that Receivers can get that extra info from the Sender and = therefore be able to guess, with more certainty, that said Sender does = indeed has all his ducks neatly in a row when he publishes p=3Dreject; = but the proposal to do so has already seen very negative reception, = repeatedly, so I will not insist on it anymore. > Yes, I know that receivers can and will do as they please, but some > receivers would be pleased as punch to cooperate in a scheme that gave > solid proof of a message's illegitimacy in every case where it was > asserted. The problem is that publishing p=3Dreject effectively > asserts that almost all submissions to mailing lists by users in the > domain are illegitimate, and I'm afraid the real world doesn't > believe that to be the case. +1. Some argue p=3Dreject is fine as it stands and that the problem is just = that Yahoo and AOL are abusing it. But the real world is as it is, and = at the end of the day after all has been said it does not matter if the = real world is abusive or not, we still have to interoperate with it. Regards, J.Gomez From nobody Fri Mar 27 13:50:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D801AD2DF for ; Fri, 27 Mar 2015 13:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.697 X-Spam-Level: * X-Spam-Status: No, score=1.697 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, 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 81LSM-YxKoE6 for ; Fri, 27 Mar 2015 13:50:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58521AC41D for ; Fri, 27 Mar 2015 13:50:37 -0700 (PDT) Received: from kitterma-e6430.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 F15A1C4014D for ; Fri, 27 Mar 2015 15:50:34 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427489436; bh=IiIIN2gFDuHD/HKleYLXH0SS2uQH9goDCKJLpBfIN5E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GqSJ93O6k7Xk1Vq1MIgLYLgv/Mup6dvWNPTjTENSl86LKMoWB+XkAIT//sU0IYiRM FLWCJdZTtvvQ21ydJP2bFuRuznExdO2mbOAbRcboDr4IO3TW99RaO/IA1bCaPz46xs daZGO6ixg5mI/pp/TpyWaJQaGzjV568yrAZt7/7c= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 27 Mar 2015 16:50:35 -0400 Message-ID: <13862271.Z4xXk81MNq@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-48-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <467390B0CBE546D5B01DC76198C6A263@fgsr.local> References: <20150318200459.23F9B18020A@rfc-editor.org> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <467390B0CBE546D5B01DC76198C6A263@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 20:50:40 -0000 On Friday, March 27, 2015 09:12:19 PM J. Gomez wrote: > > Isn't DMARC holding itself to a different standard? What's a receiver > > supposed to do with unaligned mail whose "From:" domain specifies > > p=reject? Clearly, the domain owner is explicitly asking that the > > message be rejected. If DMARC intends that this be merely one of > > many factors to consider, then doesn't it boil down to nothing more > > than p=do-whatever? > > +1. > > As it currently is, p=reject already means p=quarantine or p=none, so > "do-whatever". > > We could try to add some extra --and defaulted to be empty/none-- qualifier > to the DMARC TXT record in order to optionally, at the Sender's will, > upgrade the plain old p=reject to mean > "reject-and-yes-i-mean-it-always-dammit-i-dont-indulge-in-indirect-email-fl > ows", so that Receivers can get that extra info from the Sender and > therefore be able to guess, with more certainty, that said Sender does > indeed has all his ducks neatly in a row when he publishes p=reject; but > the proposal to do so has already seen very negative reception, repeatedly, > so I will not insist on it anymore. Looked into this once before for SPF (which despite the hand wringing here has been through a lot of these same policy considerations before). There's no point in adding a "I really mean it" flag since nothing prevents a sender from adding it even if they don't. Eventually enough domains that perhaps shouldn't publish the "I really mean it flag" the receivers want a "NO, I REALLY, REALLY mean it" flag. Pretty soon it's added flags all the way down. In the data I see, I see some receivers overriding p=reject and using p=quarantine for some set of the mail they think is indirect. Mostly though the policy applied is p=reject for a domain that publishes that policy. Scott K From nobody Fri Mar 27 17:49:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45AC1A06FD for ; Fri, 27 Mar 2015 17:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d1EX2sSR2Xl for ; Fri, 27 Mar 2015 17:49:43 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 952961A06E9 for ; Fri, 27 Mar 2015 17:49:43 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t2S0ngR1013615; Fri, 27 Mar 2015 20:49:42 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t2S0ng2l012456; Fri, 27 Mar 2015 20:49:42 -0400 Message-Id: <201503280049.t2S0ng2l012456@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Stephen J. Turnbull" From: Michael Jack Assels In-reply-to: <87lhiijm2g.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <5B31A0C36E5D408A9A535511EACB636! ! ! 8@fgsr.local> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> <201503271349.t2RDnWR4007660@shadrach.encs.concordia.ca> <87lhiijm2g.fsf@uwakimon.sk.tsukuba.ac.jp> Comments: In-reply-to "Stephen J. Turnbull" message dated "Sat, 28 Mar 2015 04:07:51 +0900." Date: Fri, 27 Mar 2015 20:49:42 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-03-27 20:49:42 EDT Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 00:49:46 -0000 On Sat, 28 Mar 2015 04:07:51 +0900, "Stephen J. Turnbull" wrote: > Michael Jack Assels writes: > > > As I read it, that means AOL and Yahoo are taking the position that > > DMARC's p=reject is The Right Thing To Do, while accepting that it's > > going to give wrong answers for indirect mail flows, and that it's up > > to MLM developers (and other producers of indirect flows) to deal with > > it. > > First, I don't think that interpretation is tenable, because their > explanations to us are along the lines of "we know that we're a little > out of line, but we have no choice." So it's more like "p=reject is The Wrong Thing To Do, and it's up to you to deal with it"? :-) > Second, the relevant producers of indirect mail flows are not the > MLMs. They generally produce a direct mail flow, albeit unaligned. > It's the mailbox provider's own users who produce indirect mail flows, > by posting to the mailing lists. You're right. "Producers" was certainly the wrong word. I should have said "players" or "participants" -- entities involved in indirect flows. > > > We have a serious spoofing problem. It is so serious compared to > > > the potential damage due to rejecting legitimate messages that we > > > accept all responsibility for nondelivery and collateral damage if > > > you choose to reject. > > > > I can accept that that may be what p=reject means, but I can't take > > seriously the idea that domain owners with p=reject really do take > > all responsibility for nondelivery of legitimate messages. When > > one of my users bangs on my door demanding to know why her message > > message wasn't delivered, can I really refer her to a giant ESP for > > an explanation? I don't think so. > > No, of course you can't, because they'll tell her that's not what they > intended, and that it wouldn't be a problem if the third party behaved > well. However, you can tell her that the giant provider told the > receiver not to accept her messages. That's what DMARC actually says, > and that's why I phrase it "accept reponsibility". Actually, there's some ambiguity of emphasis in Section 6.3 of RFC7489: p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. [...] Possible values are as follows: [...] reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. A "policy to be enacted by the Receiver at the request of the Domain Owner" sounds compulsory, while "[t]he Domain Owner wishes for Mail Receivers to reject email" sounds optional. I'm pretty sure my boss will go with "optional" for mail that we receive. > > I'd be happier to interpret "p=reject" as meaning > > > > Spoofing is a serious problem. With a very high degree of certainty, > > we assert that the message you're handling is not legitimate direct > > mail. Please take this into account when deciding whether to accept > > or reject the message. > > There's only one problem with that interpretation, and that is that > you don't need DMARC p=reject to make it: it's a logical deduction > from the mere fact of lack of From alignment. That's right. The Domain Owner's policy becomes a consideration if, and only if, there's a lack of From alignment. Otherwise everybody's happy. But notice that the hypothetical Domain Owner who makes me happy (a) is only certain that the message is not legitimate *direct* mail, and (b) is asking me to take that into account. In an earlier message, you wrote that a receiver would have to be crazy not to reject a direct message that had no From alignment, and I'm just sane enough to agree. What I don't like is the idea that DMARC-failed *indirect* mail should be rejected solely on the From Domain Owner's say-so. I'm willing to consider rejection as a default option if other factors don't indicate the message's legitimacy, but please leave me the freedom to consider other factors without falling into the "RFC-ignorant" category. (Is this message a mailing list post? Is the SMTP client one of the SPF-authorized mailers for the mailing list's domain? Does the list appear in my database of legitimate mailing lists?) > > For DMARC participants, legitimacy and illegitimacy are equally > > easy to prove for transactional mail flows, and equally hard to > > prove for indirect flows. > > That's actually false. There are many indirect flows that don't cause > signatures to be invalidated, such as Unix-style .forwards and GNU > Mailman mailing lists configured with no subject tag, no header, and > no footer. I didn't mean that you can't prove legitimacy or illegitimacy for any indirect flows, only that there doesn't exist a reliable method of proving either in all cases, the point being that there are plenty of cases of DMARC-failing legitimate indirect mail to match the DMARC-failing illegitimate indirect mail. > And that's where the shoe pinches for mailing lists: the absolutist > advocates of sender policy blame the victim and say we should stop our > traditional value-added practices so that posters from p=reject > domains can have their posts delivered. Amen! MJA From nobody Mon Mar 30 01:46:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5944B1A9244 for ; Mon, 30 Mar 2015 01:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MgrYkadN0VE for ; Mon, 30 Mar 2015 01:46:16 -0700 (PDT) Received: from ntbbs.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BC16A1ACD05 for ; Mon, 30 Mar 2015 01:46:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6406; t=1427705165; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IH7fdhw9nvmoXA9jsuD0hzCos4Q=; b=LFsGTY3G75ralh5d9WJx RxN3KCuG9nGyk+w1GKB9GuliHU5jOFwcBwMGIknkN8oxCp6tDof3HbGimyKhchcq ljym2M+JSqeJGQlc3n/pVQC/tVFGM0rtRNhA3XsXY5pusGqrSJydjYHRgS3rYeWm Nl05kiB+mRPp8iMITpMaVe8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 30 Mar 2015 03:46:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1415194778.15001.5300; Mon, 30 Mar 2015 03:46:03 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6406; t=1427704959; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hfaf/cP k+uSsDo/pC+JmALMh3pgmos0rIIR80WbcfY8=; b=DayYpnLPT1O4FezRFGEUmWC kaVq7lqAWkHwr73cwIACik2v7LcNqISmkKgWSuP5qtiaxlqAFrENU2Pj5UosB6il Q2CR3LbrYvgXFU/4CKFMMRCaTczJtJ5WbX/CqdaxhAWKSaDk413jG2azjSVJKgkg 5s2vePlcdM43BN7urJR8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 30 Mar 2015 04:42:39 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 7494785.9.12212; Mon, 30 Mar 2015 04:42:38 -0400 Message-ID: <55190D49.40608@isdg.net> Date: Mon, 30 Mar 2015 04:46:01 -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: "Murray S. Kucherawy" References: <20150318200459.23F9B18020A@rfc-editor.org> <550CAFEE.8060706@dcrocker.net> <550D6A2D.7050500@gmail.com> <87vbhunw0v.fsf@uwakimon.sk.tsukuba.ac.jp> <550E10C5.1070509@dcrocker.net> <55100395.4060003@dcrocker.net> <30834.1427141274@vindemiatrix.encs.concordia.ca> <55107A81.6000702@dcrocker.net> <3262.1427212761@vindemiatrix.encs.concordia.ca> <6F28A207601345BBAF012FED7BE612EE@fgsr.local> <55136A23.8080306@isdg.net> <201503262312.t2QNCDeF002084@shadrach.encs.concordia.ca> <87twx7j6yb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , Michael Jack Assels Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 08:46:20 -0000 Murray, Thanks for your comments. The key difference today is that we have finally achieved the long term engineering considerations of: 1) Getting domains to publish DNS policy records, 2) Receivers performing the DNS policy record lookup, 3) Receivers honoring the mail handling. We did not have this with ADSP when ATPS was first introduced as an extended ADSP add-on. ADSP, the DKIM WG proposed standard track item, was in conflict with what we reestablished today as "indirect mail flows" and the key cogs of the DKIM WG was focused on eliminating the Author Domain Identity (ADID) from the specification and making 3rd party Trust Signers (SDID) the key focus identity for DKIM evaluation. ADSP was being abandoned and you help kill it by eventually replacing it with DMARC. If you redid ATPS as an add-on DMARC, I suspect we will have a higher interest in its exploration. The marketing and need would be much higher than before. It will certainly push forward our own update efforts (Replaced ADSP with DMARC and I would like believe other mail product and EPS vendors, including MLS developers would also would update DMARC to support a new SDID (Signer Domain Identity) optional parameter in the DNS policy record lookup: DMARC = DKIM_POLICY_DMARC(ADID [,SDID]) We are already doing the lookup as a function of ADID. We established that. Thats the difference today than yesteryears. Now we just proposing to make it flexible for the 3rd party signature condition when the ADID != SDID. We also long established, which I believe all the trust advocates agreed, that resigners are good. They are needed when the original authenticity is lost, i.e MLM. Will the vendors support it? Who knows? But the market is different today and that is all I am saying, you can't judge the lack of interest before because ADSP was being abandoned. DMARC is not being abandoned. It now needs to be completed with that 3rd party component. I suggest a simple update of ATPS to anchor off DMARC and see if we will get the exploration. You will get two immediate packages to support it. Yours and mine. If in the mean time, you come up with something better, great. I don't see it because it will always need to be verifiable with the 1st party again, but now we will be able to explore all the scalability issues. I personally don't think the the non-ESP domains will need to worry about that. Perhaps the biggest challenge for the larger ESP is how to best register the domains. But thats an implementation issue, perhaps using a Web site with other business decisions such as free or fee-based. Let the each market vendor decide that. In the mean time, we need the 3rd party Authorization extension for DMARC. Thanks -- HLS On 3/27/2015 2:59 AM, Murray S. Kucherawy wrote: > On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull > > wrote: > > Murray's point is that "proof of illegitimacy" is probably a pipe > dream, as shown by past experience with "policy frameworks".[1] > Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows > in daily use by financial institutions and in other transactional mail > flows. > > > Put another way, you only really know something when DMARC, DKIM, SPF, > etc. produce a passing result. (Due credit to Dave for this > observation.) All of them have false negatives with respect to > anything that's not a direct mail flow, so "fail" results don't tell > you anything conclusive if you plan to accept any sort of mail that > isn't direct. What Hector characterizes as a watering down of SPF > with the publication of RFC7208 was merely this fact put into text, > even though it's been true since RFC4408. > > Footnotes: > [1] Hector is right that they haven't really been tried, but I don't > think the chance that they'll be tried in the future is high, because > the reasons they've been hard to implement in the past remain true. > > > I agree. And although Hector likes to ascribe considerable power and > influence to me, I'm not the one standing in the way of their > success. I would happily embrace any such solution that stood a > chance of working. I, and others, simply ask some basic questions > about scalability of such solutions, their complexity, and their > ability to be "gamed", and then they never go anywhere because there > simply aren't any good answers to those questions. Thinking I might > be wrong, and since the same people insist I am, I published RFC6541 > (ATPS) as an experimental draft to try to tackle the third-party > problem, and made a free version of it available via open source. > That was over three years ago. There has been exactly one site (one > person, rather) that tried it besides me and reported back about its > effectiveness. Though Doug will shortly claim that ATPS saw no uptake > because it is "flawed", I also had a grand total of zero operators > report that they were using it in any modified form or asking me to > add this or that to it before they would deploy it to production. It > wasn't just an idea, it was a reality, but nobody came to play. > > Policy and third-party solutions haven't failed because of some cabal > keeping them from seeing the light of day, unless by "cabal" you mean > "group of people who agree that this won't work." > > These are hard problems, and the last thing any of us should want to > do is foist yet another blob onto the global email infrastructure that > has not been properly vetted. If an idea doesn't stand up to scrutiny > or gets no uptake, or can't even get consensus in a small working > group, what prayer does it have for success on the greater Internet? > I want to make things better, not worse. > > There are those among you that disagree, I know. Does anyone have > actual data (not theory, not passion, but data) that any of the policy > or third-party solutions we've discussed before can work, work just > about everywhere, and work at scale? If the answer to that is "no" > (or, as usual, silence), then I suggest this (still!) isn't a > productive use of our precious time or energy. > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- HLS From nobody Mon Mar 30 11:35:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BF91AC3B4 for ; Mon, 30 Mar 2015 11:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dafEncqFaqY for ; Mon, 30 Mar 2015 11:35:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FFB1AC3B5 for ; Mon, 30 Mar 2015 11:35:01 -0700 (PDT) Received: from kitterma-e6430.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 02073C4044B for ; Mon, 30 Mar 2015 13:35:00 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427740500; bh=7V95vP34K2CnrAbrY4OzDBAWbgl253lQfZC2EAIoK3s=; h=From:To:Subject:Date:From; b=h5/XHMJvxoCJ0rB8squRcM3X9yVdYkRldpS5sqolEeLuk6yKiX1AxZxqcWFVMzS1I eOnI8DNKqW9F+zYCDW/fKftRfOlu+TTt+HfFjrkEb5iPpqItMYzfWZSMWTQJ8r7Ryt c7Chl62WdnsMxldO4axwNt8cNViSTWDxOGxQb6dE= From: Scott Kitterman To: "dmarc@ietf.org" Date: Mon, 30 Mar 2015 14:35:01 -0400 Message-ID: <8161668.HfpJrFpWJf@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-48-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 Mar 2015 18:35:06 -0000 I just ran across this one today in a third party non-spam email: Return-Path: ... DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=email.mindbodyonline.com; h=from:to:reply-to:subject:mime-version:content-type; s=smtpapi; ... Received: from o2.email.mindbodyonline.com (o2.email.mindbodyonline.com [74.63.194.59]) ... From: "$CUSTOMER_FRIENDLY_NAME" To: $DELIVERY_ADDRESS Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS> I know we've discussed this kind of thing before, but it's the first time I've noticed it in the wild (not that I've been looking really hard). They don't have a DMARC record published, so this may be in response to some other driver, but it works for DMARC: SPF passes and aligns DKIM passes and aligns. Since they are using their own 5322.From, there's no issue with third party DMARC records. Scott K From nobody Mon Mar 30 12:01:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3895E1A916F for ; Mon, 30 Mar 2015 12:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUz3IQloppty for ; Mon, 30 Mar 2015 12:01:52 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5221AD0AE for ; Mon, 30 Mar 2015 12:01:08 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1BE9A803BB for ; Mon, 30 Mar 2015 12:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1427742068; bh=1x6+nNt05bc6HhYJGT2UVt8VdktaEcmTVT7fBqyWzNs=; h=Subject:From:In-Reply-To:Date:References:To:From; b=T+y9p1LqTl8zahti15IsLRjhnKorBi3IsYRMl63CPpmSWMuiYpfpF6DrPuz8DMRtb ECqd434EXOWJvR5xbiyiQBMjzXuzn62Nl5PW76ajKUIRkQYzpzu+jIbKksrYo23OTP BWjqRdXZD1Jagmnyd3LjebS1RDlmgkhUzX69walA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <8161668.HfpJrFpWJf@kitterma-e6430> Date: Mon, 30 Mar 2015 12:01:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D6EB2C5-8776-4B78-9D48-37BE6B7E971F@wordtothewise.com> References: <8161668.HfpJrFpWJf@kitterma-e6430> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 Mar 2015 19:01:53 -0000 On Mar 30, 2015, at 11:35 AM, Scott Kitterman = wrote: > I just ran across this one today in a third party non-spam email: >=20 > Return-Path: = > ... > DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed;=20 > d=3Demail.mindbodyonline.com;=20 > h=3Dfrom:to:reply-to:subject:mime-version:content-type; = s=3Dsmtpapi; > ... > Received: from o2.email.mindbodyonline.com = (o2.email.mindbodyonline.com=20 > [74.63.194.59]) > ... > From: "$CUSTOMER_FRIENDLY_NAME" > To: $DELIVERY_ADDRESS > Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS> >=20 > I know we've discussed this kind of thing before, but it's the first = time I've=20 > noticed it in the wild (not that I've been looking really hard). They = don't=20 > have a DMARC record published, so this may be in response to some = other=20 > driver, but it works for DMARC: >=20 > SPF passes and aligns > DKIM passes and aligns. >=20 > Since they are using their own 5322.From, there's no issue with third = party=20 > DMARC records. It's the standard sendgrid setup. It's not particularly difficult to make DKIM and SPF work if you have = full control over the domain name you're sending from (and some control over the delivery path). Cheers, Steve= From nobody Mon Mar 30 13:01:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD21A872C for ; Mon, 30 Mar 2015 13:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAfKK7_8-pno for ; Mon, 30 Mar 2015 13:00:50 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EF95D1ACCEB for ; Mon, 30 Mar 2015 13:00:44 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 797CD1C3855; Tue, 31 Mar 2015 05:00:43 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5768A120EC9; Tue, 31 Mar 2015 05:00:43 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <8161668.HfpJrFpWJf@kitterma-e6430> References: <8161668.HfpJrFpWJf@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 31 Mar 2015 05:00:43 +0900 Message-ID: <877ftyjlw4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 Mar 2015 20:00:51 -0000 Scott Kitterman writes: > From: "$CUSTOMER_FRIENDLY_NAME" > To: $DELIVERY_ADDRESS > Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS> This won't work for a lot of mailing lists, though, because Reply-To is munged to point to the list, and it is frequently a requirement of such lists that $CUSTOMER_ADDRESS *not* be in Reply-To. And although it gets the mail past DMARC, ISTR that in many cases (eg, invoicing services) the client (ie, the billing firm) wants its address in From, so it flunks the user requirements here, too. I suspect that if this becomes common, it will play havoc with recipient contact lists, too. > but it works for DMARC: Sure, but that's the tail wagging the dog. The point of DMARC is so that people can put their addresses in From and be believed, not that there are kludges to get your content past DMARC. From nobody Mon Mar 30 13:50:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E901A8896 for ; Mon, 30 Mar 2015 13:50:29 -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 axb0w6lku9j6 for ; Mon, 30 Mar 2015 13:50:28 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B3E1A03A2 for ; Mon, 30 Mar 2015 13:50:24 -0700 (PDT) Received: from kitterma-e6430.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 C7013C4001A for ; Mon, 30 Mar 2015 15:50:23 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427748623; bh=eFroc6HTfpQjvdPIH/8eE3HBZL3aX0gLwFDpw27FISw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eO/E9tbXhJr4YVKUgtPAKow0DUejaJmZiW7iW4OeikXWnak0NSvu/Rx2Edn3n311F W7DxreppNlLxPho3fkS//PKQJDCEiQ2p8Mjwwbyz6vBrwoPiyuXPNnAK+ySMFzA3u/ ERikOj8ufPwjBftCAu3WB4w6dmV7cynXGh3wKwSQ= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 30 Mar 2015 16:50:24 -0400 Message-ID: <1704877.BgSjq7ehEz@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-48-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <877ftyjlw4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8161668.HfpJrFpWJf@kitterma-e6430> <877ftyjlw4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 Mar 2015 20:50:30 -0000 On Tuesday, March 31, 2015 05:00:43 AM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > From: "$CUSTOMER_FRIENDLY_NAME" > > To: $DELIVERY_ADDRESS > > Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS> > > This won't work for a lot of mailing lists, though, because Reply-To > is munged to point to the list, and it is frequently a requirement of > such lists that $CUSTOMER_ADDRESS *not* be in Reply-To. > > And although it gets the mail past DMARC, ISTR that in many cases (eg, > invoicing services) the client (ie, the billing firm) wants its > address in From, so it flunks the user requirements here, too. > > I suspect that if this becomes common, it will play havoc with > recipient contact lists, too. > > > but it works for DMARC: > Sure, but that's the tail wagging the dog. The point of DMARC is so > that people can put their addresses in From and be believed, not that > there are kludges to get your content past DMARC. I know this isn't any kind of solution for mailing lists. It is something in use that works (FSVO works) for third party origination. Presentation differs among MUAs, so it's hard to draw generalizations about how well that set of identities are presented to end users. Scott K From nobody Mon Mar 30 21:16:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790FD1B2A7B for ; Mon, 30 Mar 2015 21:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg_BdJbZXB3v for ; Mon, 30 Mar 2015 21:16:08 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A18D61B2A7A for ; Mon, 30 Mar 2015 21:16:08 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 165C51C389D; Tue, 31 Mar 2015 13:16:07 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EF495120EC9; Tue, 31 Mar 2015 13:16:06 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <1704877.BgSjq7ehEz@kitterma-e6430> References: <8161668.HfpJrFpWJf@kitterma-e6430> <877ftyjlw4.fsf@uwakimon.sk.tsukuba.ac.jp> <1704877.BgSjq7ehEz@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 31 Mar 2015 13:16:06 +0900 Message-ID: <874mp1kdix.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 04:16:10 -0000 Scott Kitterman writes: > On Tuesday, March 31, 2015 05:00:43 AM Stephen J. Turnbull wrote: > > Sure, but that's the tail wagging the dog. The point of DMARC is so > > that people can put their addresses in From and be believed, not that > > there are kludges to get your content past DMARC. > Presentation differs among MUAs, so it's hard to draw > generalizations about how well that set of identities are presented > to end users. I am not concerned here with presentation. This is about requirements by the *originator*. Some originators think having their domain name in From: matters, and life will be a lot easier for sysadmins if we can find a way to let them put it there and still get the benefits of DMARC. (Or maybe I'm just sensitized to unreasonable user requirements having just spent a couple messages trying to get Dr. Stallman to Learn to Stop Worrying and Love Git.) From nobody Tue Mar 31 04:50:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508761A9111 for ; Tue, 31 Mar 2015 04:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 Se2rw2LuVxGo for ; Tue, 31 Mar 2015 04:50:02 -0700 (PDT) Received: from listserv.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 35D7D1A9114 for ; Tue, 31 Mar 2015 04:50:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1704; t=1427802597; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=fs+hM4ab5Z3bU4FCYZ8bN8iePB8=; b=Qp5ZgkYikYjC19w+JVAQ wyQf8D7QRQMhBlqmE4TQE0KyRypKHHHjVvwZrOUnH/LBtl4Y/JI/l89iusnXfF91 TV7zjKZdm0OOwfidfTsFu7K7lb8KLVkcsFEAMH3Ak5DnUiB2FHCLpFd32X+7rdYd dUb+5VcCaQ5Q0tcnxkK85B4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 31 Mar 2015 06:49:57 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1512626310.21354.5380; Tue, 31 Mar 2015 06:49:56 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1704; t=1427802387; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=eSWNlTQ ykqNPrE0LHthwhJY67DgshjEnFWDPiZKsl4Q=; b=SEEeYI+BdCR3oAZwmUYrEfL pWadxajjK4tpxd3nwRH6OVWlb8oW1hSpIS5p+ifbY2Pgq7a12Go8MRux7vfq5bHN ql6SS/RliEncCZu5CsUVX2TajQ7kDHAcUQtHJq9RMPR2UwAh6z42iN/LYsth4LW4 2gju0JqjwrbHT7MRZ0Ks= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 31 Mar 2015 07:46:27 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 104923160.9.2544; Tue, 31 Mar 2015 07:46:26 -0400 Message-ID: <551A89E1.3020205@isdg.net> Date: Tue, 31 Mar 2015 07:49: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: Scott Kitterman , "dmarc@ietf.org" References: <8161668.HfpJrFpWJf@kitterma-e6430> In-Reply-To: <8161668.HfpJrFpWJf@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 11:50:05 -0000 Don't quite get it, Scott. There is no DMARC record so the transaction would be "DMARC indeterminate" -- no DKIM signing policy. If it did have a DMARC record, in order for this transaction to DMARC pass, it would require relaxed alignments for SPF and DKIM: adkim=r aspf=r Correct? subdomains has more inherent "trust" than having completely different main domains. The problem of course, DMARC excludes this legitimate 3rd party signer possibility in its protocol. -- HLS On 3/30/2015 2:35 PM, Scott Kitterman wrote: > I just ran across this one today in a third party non-spam email: > > Return-Path: > ... > DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; > d=email.mindbodyonline.com; > h=from:to:reply-to:subject:mime-version:content-type; s=smtpapi; > ... > Received: from o2.email.mindbodyonline.com (o2.email.mindbodyonline.com > [74.63.194.59]) > ... > From: "$CUSTOMER_FRIENDLY_NAME" > To: $DELIVERY_ADDRESS > Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS> > > I know we've discussed this kind of thing before, but it's the first time I've > noticed it in the wild (not that I've been looking really hard). They don't > have a DMARC record published, so this may be in response to some other > driver, but it works for DMARC: > > SPF passes and aligns > DKIM passes and aligns. > > Since they are using their own 5322.From, there's no issue with third party > DMARC records. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Tue Mar 31 09:46:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836961A036A for ; Tue, 31 Mar 2015 09:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 Hkpy_tVXVMnl for ; Tue, 31 Mar 2015 09:46:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D811A03AA for ; Tue, 31 Mar 2015 09:46:33 -0700 (PDT) Received: from [100.101.153.25] (30.sub-70-208-150.myvzw.com [70.208.150.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 13507C40020; Tue, 31 Mar 2015 11:46:32 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427820392; bh=dgc7uqs79N0GCHMg/G5uvrejI8BVL4/8FJbOH4PX4ew=; h=In-Reply-To:References:Subject:From:Date:To:From; b=sTis0tNZ4aeW7gC4AKIs4qIK1ZjkI88y09NCMmviDlrzo7RRHv6TzWHxDx6+RQ/hy GJ7SnAy9zbmgb02yiaxeLBTyptuxeZpE3XRS8Xo00/8HBAVDok+6ZKpmERkf2c38r8 mWBz9jWFEel3XmkbMqsgQSrFTgQSr/WXAVWUCijw= User-Agent: K-9 Mail for Android In-Reply-To: <551A89E1.3020205@isdg.net> References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 31 Mar 2015 12:45:29 -0400 To: "dmarc@ietf.org" Message-ID: <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:46:34 -0000 On March 31, 2015 7:49:53 AM EDT, Hector Santos wrote: >Don't quite get it, Scott. There is no DMARC record so the >transaction would be "DMARC indeterminate" -- no DKIM signing policy. I think it's called none, but the point is that as a third party sender, their setup can't get entangled with customer first party sender setup which might have DMARC. >If it did have a DMARC record, in order for this transaction to DMARC >pass, it would require relaxed alignments for SPF and DKIM: > > adkim=r > aspf=r > >Correct? Which is the default. >subdomains has more inherent "trust" than having completely different >main domains. The problem of course, DMARC excludes this legitimate >3rd party signer possibility in its protocol. I've yet to see a proposal to include it which is both executable and doesn't defeat the purpose of DMARC. I agree it's a problem, but one that so far doesn't have an appropriate technical solution. Scott K From nobody Tue Mar 31 10:40:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2911A3B9C for ; Tue, 31 Mar 2015 10:40:23 -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 zfZj-zCX0xHC for ; Tue, 31 Mar 2015 10:40:21 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 32A841A1F02 for ; Tue, 31 Mar 2015 10:40:21 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 0EEA48907 for ; Tue, 31 Mar 2015 19:40:18 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 31 Mar 2015 19:40:17 +0200 Message-ID: <4D62F546336B4732A7B1CE73590A9450@fgsr.local> From: "J. Gomez" To: References: <8161668.HfpJrFpWJf@kitterma-e6430> <551A89E1.3020205@isdg.net> <09F1AF6F-2DE4-42DC-B18E-3324F0B9B4C4@kitterman.com> Date: Tue, 31 Mar 2015 19:40:20 +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: Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:40:23 -0000 On Tuesday, March 31, 2015 6:45 PM [GMT+1=3DCET], Scott Kitterman wrote: > I've yet to see a proposal to include it which is both executable and > doesn't defeat the purpose of DMARC. I agree it's a problem, but one > that so far doesn't have an appropriate technical solution.=20 What we don't have is a "socially appropriate" technical solution. But a = "technically appropriate" technical solution yes there is: "Every = resender[*] who invalidates the original Author's DKIM signature must = take ownership of the Header-From and re-sign the message". Simple. = Easy. But socially unacceptable (for now, at least) because of the = expectations of several legacy mail usages. =20 [*] Given that said resenders are mostly non-human, but computer = systems, they can be trivially programmed to behave in such a DMARC = compatible way. Regards, J.Gomez From nobody Tue Mar 31 13:01:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A401ACE76 for ; Tue, 31 Mar 2015 13:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 tUaLl6vVug2v for ; Tue, 31 Mar 2015 13:01:17 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D361ACE63 for ; Tue, 31 Mar 2015 13:01:17 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so39961610wib.1 for ; Tue, 31 Mar 2015 13:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8tvlacroQWT8tB0WXviDS7bgr4nUhif1PMBnzCdEHfA=; b=jHLvqQ+2nblKtA6Ett5YhwXnfBiMcmXFt2+xfXxiG7V4+ax/D360CPFnax1rvKdb2d meupwvdEs1/8V7BR4BYmfT8IXRaK3hnawrf8NV74kNQXjT/IfMOoql+4hK5ePoOjnfy4 JqODrV20WsWKoRUTPXBZpxDQNtaU0MzKcSFzddIsBUnWhKiStg4XmTNCqOGPmiLPTwr9 6DQwd3IXckTqkRc6to2fv22faCFEM7msJS/b4MFeAFGXWpdhXy070LFnepSMu7VwDLrb BFXqsw0f9MCWAXF+fROplm8N6sMTQx9x/p91dNXm/zq6yRex+W7pi9cZrTby2ZBwPM/6 v5fg== MIME-Version: 1.0 X-Received: by 10.180.187.67 with SMTP id fq3mr8450504wic.59.1427832075878; Tue, 31 Mar 2015 13:01:15 -0700 (PDT) Received: by 10.27.92.17 with HTTP; Tue, 31 Mar 2015 13:01:15 -0700 (PDT) In-Reply-To: <341743611.12421.1427120848801.JavaMail.zimbra@peachymango.org> References: <905729822.12380.1427120800921.JavaMail.zimbra@peachymango.org> <341743611.12421.1427120848801.JavaMail.zimbra@peachymango.org> Date: Tue, 31 Mar 2015 13:01:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a11c38070ae86d705129b0f22 Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 20:01:20 -0000 --001a11c38070ae86d705129b0f22 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin wrote: > Looking better... > > Special thanks to Elizabeth for improving the document after I integrated > (all?) previous comments. Please see this revision and post > comments/reviews against it. > It sure seems better. :-) A few comments on this version: Section 1 and the Abstract use an impersonal writing style (this document does this, this section does that) while in Section 2 it changes to using "we". I suggest sticking with the former style. OLD: What do we mean by "interoperability issues"? We say that DMARC introduces interoperability issues or problems, when conformance to the DMARC specification leads an implementation to reject a message that is both compliant with the architecture as specified in [RFC5598 ] and would have been viewed as legitimate in the eyes of the intended recipient. Therefore, we can already conclude that DMARC poses no interoperability problems when legitimate messages properly validate through its specified processes. The rest of this section delves into how legitimate messages may get rejected. NEW: Interoperability issues are introduced when conformance to the DMARC specification leads an implementation to reject a message that is both compliant with the architecture as specified in [RFC5598] and would have been viewed as legitimate in the eyes of the intended recipient. Therefore, it can already be concluded that DMARC poses no interoperability problems when legitimate messages properly validate through its specified processes. The rest of this section delves into how legitimate messages can be rejected. ...etc. The last paragraph of Section 2.1 opens with a run-on sentence. Also, since that chapter is entirely about SPF, all of the [RFC7208] references can be omitted; they make an already-long sentence rather cluttered. Also, this paragraph (and I think the one before it as well) talk about alignment being defined as the two identifiers sharing the same Organizational Domain, but in fact that depends on whether relaxed or strict mode is active, right? It also has this: Even when an SPF record exists for the domain in RFC5322 .From, SPF will not authenticate it unless it is also the domain SPF checks. I'm confused. When is the SPF record for the RFC5322.From domain ever checked? Shouldn't that be the DMARC policy, not the SPF policy? In Section 2.3, the "RFC6376 [RFC6376]" is redundant and can be cleaned up. What does "Furthermore, the use of the length flag is by no means universal." mean? Does that mean not everyone uses it, or not all software implements it? "DKIM has two canonicalizations: simple and relaxed." ...is true for both the header and the body. "The relaxed canonicalization used to be computing intensive and may not have been preferred in the early deployment of DKIM." It's still true that relaxed requires more processing than strict, but I've never heard that used as a basis for not using it. It's not a heavyweight process. Section 3.1.1: "marked by an inherent difficulty in modifying" -- It's not modifying that's hard, it's establishing alignment that's hard. A pure syntax point: All the entries in that bullet list end in periods, but are not capitalized; either make them phrases (drop the period) or make them sentences (capitalize) Section 3.1.2.1: Should "8-bit mail" be "8-bit MIME"? I don't know what a "mail section" is. Also, I think RFC6376 has some discussion about this. Might be useful to refer to it. Section 3.1.2.2: "In addition, group syntax will remove the ability for the DMARC mechanism to find an Organizational Domain that aligns with any authenticated domain identifier from SPF or DKIM." Is that strictly true? Didn't we say in DMARC (I forget now) that a receiver could evaluate all such domains? Or am I thinking of the wrong problem? Section 3.1.3 talks about application of SIEVE, but wouldn't that sort of thing happen after SPF and DKIM have already been evaluated? Section 3.2.3, same earlier syntax point about the bullet list. Also, RFC6377 contains a more detailed description of the third-party bounce problem and how it can be destructive. Would it be worth pointing out that the typical MLM changes are not only common, but perfectly valid within the context of email? Or that declaring those things as no-longer-permitted is not likely to succeed? Section 3.2.4: "acquired companies domains" should be "acquired company's domains". Also "To: header" should be "RFC5322.To header field". Section 3.2.5 should mention that whether a boundary filter introduces an interop problem depends on where the DKIM and SPF evaluations are done. If they're inside a modifying filter, there's a problem, but not otherwise. Section 4: "proper handling multiple DKIM signatures" should be "proper handling of multiple DKIM signatures" Also Section 4: What are "the DMARC headers"? Section 4.1: Should we list potential side effects of each of these? Changing the From: to something aligned affects what the end user will see as the author, for example. Section 4.2: "email headers" should be "email header fields", "preferring preserving" should be "preferring to preserve" Section 4.3: Another "header" that should be "header field", and "yet-another" shouldn't have a hyphen. Section 4.4.1.2: "email headers" to "email header fields" Section 4.4.1.3: "at the appreciation of the postmaster"? I'm not familiar with that expression. Perhaps "at the discretion of the mail administrator"? Section 4.5.1: "depending if" -> "depending on whether". Also the bullet starting "Finally" is (a) comma-spliced, and (b) not the final item in the list. And the reference to RFC7372 is correct, but it might be worth saying that it's not widely deployed yet. Section 4.6: Misspelling of "alignment". More generally, I'm confused by what this section is saying. How is the message store involved in DMARC? That's it for this pass. -MSK --001a11c38070ae86d705129b0f22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin <fr= anck@peachymango.org> wrote:
= Looking better...

Special thanks to Elizabeth for improving the document after I integrated (= all?) previous comments. Please see this revision and post comments/reviews= against it.

It sure seems better.=C2= =A0 :-)

A few comments on this version:

Section 1 and the Abstract use an impersonal writing style (this document = does this, this section does that) while in Section 2 it changes to using &= quot;we".=C2=A0 I suggest sticking with the former style.

OLD:

   What do we mean by "interoperability issues&=
quot;?  We say that DMARC
   introduces interoperability issues or problems, when conformance to
   the DMARC specification leads an implementation to reject a message
   that is both compliant with the architecture as specified in
   [RFC5598] and would have been=
 viewed as legitimate in the eyes of the
   intended recipient.  Therefore, we can already conclude that DMARC
   poses no interoperability problems when legitimate messages properly
   validate through its specified processes.  The rest of this section
   delves into how legitimate messages may get rejected.

=
NEW:

Int=
eroperability issues are introduced when conformance to the DMARC
specif=
ication leads an implementation to reject a message that is both
complia=
nt with the architecture as specified in [RFC5598] and would
have been v=
iewed as legitimate in the eyes of the intended recipient.
Therefore, it=
 can already be concluded that DMARC poses no interoperability
problems =
when legitimate messages properly validate through its specified
process=
es.  The rest of this section delves into how legitimate messages can
be=
 rejected.

...e=
tc.

The =
last paragraph of Section 2.1 opens with a run-on sentence.  Also, since th=
at chapter is entirely about SPF, all of the [RFC7208] references can be om=
itted; they make an already-long sentence rather cluttered.

<=
/pre>
Also, this paragraph (a=
nd I think the one before it as well) talk about alignment being defined as=
 the two identifiers sharing the same Organizational Domain, but in fact th=
at depends on whether relaxed or strict mode is active, right?

It also has this:

   Even when an SPF record exists for the domain in RFC5322.From,=
 SPF
   will not authenticate it unless it is also the domain SPF checks.

I'=
;m confused.  When is the SPF record for the RFC5322.From domain ever check=
ed? Shouldn't that be the DMARC policy, not the SPF policy?
In Section 2.3, the &qu=
ot;RFC6376 [RFC6376]" is redundant and can be cleaned up.
What does &=
quot;Furthermore, the use of the length flag is by no means universal."=
; mean?  Does that mean not everyone uses it, or not all software implement=
s it?

=
"DKIM has two canonicalizations: simple and relaxed." ...is true =
for both the header and the body.

"The relaxed canonicalization=
 used to be computing intensive and may not have been preferred in the earl=
y deployment of DKIM." It's still true that relaxed requires more =
processing than strict, but I've never heard that used as a basis for n=
ot using it.  It's not a heavyweight process.

=
Section 3.1.1:
"marked by an inherent difficulty in modifying" -- It's not=
 modifying that's hard, it's establishing alignment that's hard=
.
A pure syntax point: All the entries in that bullet list end in periods,=
 but are not capitalized; either make them phrases (drop the period) or mak=
e them sentences (capitalize)

Section 3.1.2.1:

Should "8-bit mail" be "8-b=
it MIME"?  I don't know what a "mail section" is.
A=
lso, I think RFC6376 has some discussion about this.  Might be useful to re=
fer to it.

Section 3.1.2.=
2:

"In addition, group syntax will remove the ability for t=
he DMARC mechanism to find an Organizational Domain that aligns with any au=
thenticated domain identifier from SPF or DKIM."  Is that strictly tru=
e?  Didn't we say in DMARC (I forget now) that a receiver could evaluat=
e all such domains?  Or am I thinking of the wrong problem?

<=
/pre>
Section 3.=
1.3 talks about application of SIEVE, but wouldn't that sort of thing h=
appen after SPF and DKIM have already been evaluated?

<=
pre>Section 3.2.3, s=
ame earlier syntax point about the bullet list.  Also, RFC6377 contains a m=
ore detailed description of the third-party bounce problem and how it can b=
e destructive.

Would it be worth pointing out that the typical MLM cha=
nges are not only common, but perfectly valid within the context of email? =
 Or that declaring those things as no-longer-permitted is not likely to suc=
ceed?
Section 3.2.4: "acquired companies domains" should be &quo=
t;acquired company's domains".  Also "To: header" should=
 be "RFC5322.To header field".

Section 3.2.5 should mention =
that whether a boundary filter introduces an interop problem depends on whe=
re the DKIM and SPF evaluations are done.  If they're inside a modifyin=
g filter, there's a problem, but not otherwise.

Section 4: "p=
roper handling multiple DKIM signatures" should be "proper handli=
ng of multiple DKIM signatures"

Also Section 4: What are "=
the DMARC headers"?

Section 4.1: Should we list potential side ef=
fects of each of these?  Changing the From: to something aligned affects wh=
at the end user will see as the author, for example.

Section 4.2: &quo=
t;email headers" should be "email header fields", "pref=
erring preserving" should be "preferring to preserve"
S=
ection 4.3: Another "header" that should be "header field&qu=
ot;, and "yet-another" shouldn't have a hyphen.

Section =
4.4.1.2: "email headers" to "=
email header fields"

Section 4.4.1.3: "at the appreciation of the postmaster"?  I'm not familia=
r with that expression.  Perhaps "at the discretion of the mail admini=
strator"?

Section 4.5.1: "depending if" -> "dep=
ending on whether".  Also the bullet starting "Finally" is (=
a) comma-spliced, and (b) not the final item in the list.  And the referenc=
e to RFC7372 is correct, but it might be worth saying that it's not wid=
ely deployed yet.

Section 4.6: Misspelling of "alignment".  =
More generally, I'm confused by what this section is saying.  How is th=
e message store involved in DMARC?

That's it for this pass.
-MSK<=
br>
--001a11c38070ae86d705129b0f22-- From nobody Tue Mar 31 15:56:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED861AD373 for ; Tue, 31 Mar 2015 15:56:31 -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 ZOtaARohn7Vw for ; Tue, 31 Mar 2015 15:56:29 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223661ACE30 for ; Tue, 31 Mar 2015 15:56:29 -0700 (PDT) Received: by pacgg7 with SMTP id gg7so33151569pac.0 for ; Tue, 31 Mar 2015 15:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p3yibxGssiUAnU0u5HI1Liywv4WQKdZTqa631yNEcEQ=; b=dWJrGfm5Dr/K/hAHDT7D+mR6sUPY9BMYv21QfCz3QPytgimc02oWKLM/zeasIUBIFO VlDgzi5VXUSVSkuKZqhVuZoQ3jQ6rFaaahtb/nZgvKprhAAHTBo96wVxpnFf6ZY1QipV DlUVIJB5rXJ20SQlSgdwS/juY3P6QWsjFKRgdAapOXbx1yLGrWsYMbIT2IEiL9w0qCuq PWXMtx7zA94wZ1zf59/k7F5S8odaIPfC51Tvi9jzJpC6Zk+NivlFRWmPc4CBUxR2rQph eRgwy7/12H3WVD8FvjYdEpSKelPyS5mdOHTZ1SisWcKXh6CDXiyNbUYroEtb3+/jUUHf xebA== X-Received: by 10.66.129.174 with SMTP id nx14mr10667015pab.12.1427842588851; Tue, 31 Mar 2015 15:56: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 ap4sm19176pbd.2.2015.03.31.15.56.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 15:56:27 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Google MtView In-Reply-To: <874mp1kdix.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 31 Mar 2015 15:56:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8161668.HfpJrFpWJf@kitterma-e6430> <877ftyjlw4.fsf@uwakimon.sk.tsukuba.ac.jp> <1704877.BgSjq7ehEz@kitterma-e6430> <874mp1kdix.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 22:56:31 -0000 > On Mar 30, 2015, at 9:16 PM, Stephen J. Turnbull = wrote: >=20 > Scott Kitterman writes: >> On Tuesday, March 31, 2015 05:00:43 AM Stephen J. Turnbull wrote: >=20 >>> Sure, but that's the tail wagging the dog. The point of DMARC is so >>> that people can put their addresses in =46rom and be believed, not = that >>> there are kludges to get your content past DMARC. >=20 >> Presentation differs among MUAs, so it's hard to draw >> generalizations about how well that set of identities are presented >> to end users. >=20 > I am not concerned here with presentation. This is about requirements > by the *originator*. Some originators think having their domain name > in From: matters, and life will be a lot easier for sysadmins if we > can find a way to let them put it there and still get the benefits of > DMARC. Dear Stephen, A few providers at the IETF conference offered suggestions which might=20= gain traction for reasons beyond those created by DMARC, such as XMPP gateways. Although having experience in reporting policy at scale, it=20= seems providers creating issues for millions of users are equally=20 unwilling to enhance policy feedback to mitigate DMARC's disruption of=20= legitimate third-party services. An enhancement that was even offered=20 on their behalf.=20 Refusals along with a demand for hard data creates a barrier similar to=20= doubt used to oppose global warming or tobacco controls. By impacting=20= such a large number of users, DMARC prevents retaining =46rom Header = field=20 as the role of Author. Only the Sender header field is able to offer=20 DMARC's desired alignment requirements. There is already support in = MUAs=20 to intelligently combine Sender and =46rom based on domain alignments,=20= which would be adequate for mailing-lists limited to subscribed users. In the next few days, I'll post an I-D to expand on the basic idea about=20= retaining and expanding discussion forums. Regards, Douglas Otis