From nobody Mon Sep 1 13:24:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED171A06F4 for ; Mon, 1 Sep 2014 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.668, 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 HQG0G4M6dWbX for ; Mon, 1 Sep 2014 13:24:09 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id A1E571A069B for ; Mon, 1 Sep 2014 13:24:09 -0700 (PDT) Received: from [10.0.1.15] (97-82-223-101.dhcp.hckr.nc.charter.com [97.82.223.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 88420CB46; Mon, 1 Sep 2014 16:24:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <87r3zx9ntl.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 1 Sep 2014 16:24:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8997EE84-F27B-48D4-9AE4-E39CD59A32E3@eudaemon.net> References: <20140828135248.15412.37971.idtracker@ietfa.amsl.com> <5400AF63.1080803@qti.qualcomm.com> <4FE2DA0E-3137-4534-94E6-11C43E683937@eudaemon.net> <5400C109.9090400@qti.qualcomm.com> <5400C1EA.6080305@dcrocker.net> <5400C3DE.4030509@qti.qualcomm.com> <87wq9qa5iz.fsf@uwakimon.sk.tsukuba.ac.jp> <5401D832.2@qti.qualcomm.com> <87r3zx9ntl.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-E1V6HZLEjBnhCIo796N27PuFzE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Milestones changed for dmarc WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 20:24:13 -0000 On Aug 31, 2014, at 2:26 AM, Stephen J. Turnbull = wrote: > My feeling is that the DMARC consortium would appreciate a change of > wording like the one I proposed, and I'm all for keeping them happy > and in the club. If the distinction doesn't matter to others, why > not? Hi Stephen, I replied to your suggestion here: http://www.ietf.org/mail-archive/web/dmarc/current/msg01577.html ..and based on the rest of the thread, there doesn't appear to be = anything to do. As a point of clarification: it is not helpful for this WG to carve out = special consideration for "the DMARC consortium". All organizations = listed on DMARC.ORG have been made aware of this WG's activity, and = they've been invited to participate directly. -=3D Tim From nobody Mon Sep 8 12:05:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30C1A0345 for ; Mon, 8 Sep 2014 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 H4MsIyCUbX_k for ; Mon, 8 Sep 2014 12:05:30 -0700 (PDT) Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4CC1A0320 for ; Mon, 8 Sep 2014 12:05:30 -0700 (PDT) Received: from EXCH-M02.ad.teamaol.com (exch-m02-redir.office.aol.com [10.178.122.59]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id 671C170074DDF for ; Mon, 8 Sep 2014 15:05:29 -0400 (EDT) Received: from AOLDTCMES31.ad.aol.aoltw.net ([169.254.8.53]) by EXCH-M02.ad.teamaol.com ([10.178.122.59]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 15:05:29 -0400 From: "Kelley, John" To: "dmarc@ietf.org" Thread-Topic: Indirect mail flows Thread-Index: AQHPy5fbrBPbe5KR80O0WUuiDj8+FA== Date: Mon, 8 Sep 2014 19:05:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.20.15.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <0FA504564774B84BA2AB052C0C4D3832@teamaol.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QTp_1Q-2rmlaWnE9dVn21OkT9dU Subject: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 19:05:32 -0000 Hi. =20 I'm not sure if it is too soon to start the discussion on indirect mail flows, but theses are the chief problems we (AOL) are seeing with indirect mail. 1. Auto Forwards, principally where the email is munged in some way causing DKIM to fail. 2. Mailing lists; although the big ones seem to be rewriting the From (thanks). 3. Groups (these might be considered a subset of mailing lists, but folks seem to think of them differently) John Kelley From nobody Mon Sep 8 13:58:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A7C1A0376 for ; Mon, 8 Sep 2014 13:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.52 X-Spam-Level: X-Spam-Status: No, score=-13.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 lUVC26HAnrPG for ; Mon, 8 Sep 2014 13:58:21 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD0D1A0354 for ; Mon, 8 Sep 2014 13:58:20 -0700 (PDT) Received: from GQ1-EX10-CAHT18.y.corp.yahoo.com (gq1-ex10-caht18.corp.gq1.yahoo.com [10.73.119.199]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s88Kvc55012171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Sep 2014 13:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1410209859; bh=fVzH5UxIyoMMuHKSDtvq86K5ssqqo+ZZ0HL7TKMzzsc=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject; b=gAHsq6iijONujFFIiUnaSOfCUypl4Wg+KeLMzvaLk1a/C38Mcj8q/10PRoz6Jf0Wo FrmAZg+Z3nrZAi1yybTPSl+gTS8w4z3AYamQu2mKq+Jgil8jeFbyLxsewCJ2M2ofVi Ex/nIZW8y1SFZ0Qe0XIXvJZ/SOt02mzbeK4PVLPo= Received: from omp1065.mail.ne1.yahoo.com (98.138.226.164) by GQ1-EX10-CAHT18.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 13:57:37 -0700 Received: (qmail 62184 invoked by uid 1000); 8 Sep 2014 20:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410209856; bh=OsB0P945sXHiU4/8EepExwb3Ks3iyaeSHcEjTd4EH5Q=; h=Date:From:Reply-To:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type; b=MSAmweX2yDZ9oUSTmFAvP1cSAWQPe9+xS3xnR1efCx80Gni0VtVs8I1a600EclP+UUXJ8K9UaNnSHPfHVFJtN0ZRgyEUoi6PvAlE8piyro4+nYhtdVK7aSgnoG/KmYPjSrwf5XYgE9CiPDdQNqAhx7DvyTUbugnHQ6ETkWkVZhA= Date: Mon, 8 Sep 2014 20:57:35 +0000 From: Elizabeth Zwicky To: "Kelley, John" , "dmarc@ietf.org" Message-ID: <1132881597.22807.1410209855224.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22806_1284540438.1410209855220" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 209858004 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1MGTPXeKnTlmjj37HobkhjP85Xc Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Elizabeth Zwicky List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:58:22 -0000 ------=_Part_22806_1284540438.1410209855220 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also these get chained together -- think of the person who subscribes to a = mailing list from a university email address that then ends up being forwar= ded. Another big, difficult case is people sending mail via an ISP; you have cab= le Internet at home, you want to send mail via SMTP, you don't want to use = "user@ispmail.com", but you are forced through the ISPs SMTP server.=C2=A0 We are seeing less "mail to a friend" (where the mail is generated by an ap= p or website) but still some. Also down but still existent is commercial mail sending for free email addr= esses -- somebody uses business services to send mail but the business has = an email address in somebody else's domain (think "happy birthday" from you= r dentist, for instance). Elizabeth Zwicky From: "Kelley, John" To: "dmarc@ietf.org" =20 Sent:=20 Subject: [dmarc-ietf] Indirect mail flows =20 Hi.=C2=A0=20 I'm not sure if it is too soon to start the discussion on indirect mail flows, but theses are the chief problems we (AOL) are seeing with indirect mail. 1. Auto Forwards, principally where the email is munged in some way causing DKIM to fail. 2. Mailing lists; although the big ones seem to be rewriting the From (thanks). 3. Groups (these might be considered a subset of mailing lists, but folks seem to think of them differently) John Kelley _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ------=_Part_22806_1284540438.1410209855220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Also these get chain= ed together -- think of the person who subscribes to a mailing list from a = university email address that then ends up being forwarded.

Another big, difficult case is p= eople sending mail via an ISP; you have cable Internet at home, you want to= send mail via SMTP, you don't want to use "user@ispmail.com", but you are = forced through the ISPs SMTP server. 

We are seeing less "mail to a friend" (where the = mail is generated by an app or website) but still some.

Also down but still existent is comm= ercial mail sending for free email addresses -- somebody uses business serv= ices to send mail but the business has an email address in somebody else's = domain (think "happy birthday" from your dentist, for instance).

Elizabeth Zwicky

=
From: "Kelley, John" <john.kelley@teamaol.com>
To: "dmarc@ietf.org" <dmarc@ietf.org&= gt;
Sent:
Subject: [dmarc-ietf] Indirect m= ail flows

Hi. 

I'm not sure if it is too = soon to start the discussion on indirect mail
flows, but theses are the = chief problems we (AOL) are seeing with indirect
mail.

1. Auto Fo= rwards, principally where the email is munged in some way
causing DKIM t= o fail.
2. Mailing lists; although the big ones seem to be rewriting the= From
(thanks).
3. Groups (these might be considered a subset of mail= ing lists, but folks
seem to think of them differently)



J= ohn Kelley



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


------=_Part_22806_1284540438.1410209855220-- From nobody Tue Sep 9 01:39:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93EF1A8960 for ; Tue, 9 Sep 2014 01:39:36 -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 3nk4VvOZ0uBi for ; Tue, 9 Sep 2014 01: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 3F3031A8947 for ; Tue, 9 Sep 2014 01:39:34 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id EF8FA1C38D7; Tue, 9 Sep 2014 17:39:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E19FC1A3915; Tue, 9 Sep 2014 17:39:33 +0900 (JST) From: "Stephen J. Turnbull" To: "Kelley, John" In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 09 Sep 2014 17:39:33 +0900 Message-ID: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Oi-UN-yYqvH10yJHwkKAfyKvvn8 Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 08:39:37 -0000 Kelley, John writes: > 1. Auto Forwards, principally where the email is munged in some way > causing DKIM to fail. > 2. Mailing lists; although the big ones seem to be rewriting the From > (thanks). >From what I've seen on Mailman Project lists[1], your users may not feel the same way, though. There have been complaints to list owners that they're getting singled out (a popular Mailman feature, for example, checks DMARC policy and munges From or wraps the message only if it's p=reject). Have you had any such feedback? > 3. Groups (these might be considered a subset of mailing lists, but > folks seem to think of them differently) What's a "group"? Specifically, how do messages get submitted to groups and then injected into the mail system? If there are multiple ways of submitting messages, does it matter which one is used? Footnotes: [1] Can't speak from personal experience, all my "p=reject" subscribers said "thanks for the heads-up" and changed posting address. From nobody Tue Sep 9 10:08:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A831A702D for ; Tue, 9 Sep 2014 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 RJ_lpGxzN3to for ; Tue, 9 Sep 2014 10:08:03 -0700 (PDT) Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com [205.188.109.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEBF1A802B for ; Tue, 9 Sep 2014 10:08:03 -0700 (PDT) Received: from EXCH-M03.ad.teamaol.com (exch-m03-redir.office.aol.com [10.178.122.61]) by omr-d03.mx.aol.com (Outbound Mail Relay) with ESMTP id CB8A2700000A8; Tue, 9 Sep 2014 13:08:02 -0400 (EDT) Received: from AOLDTCMES31.ad.aol.aoltw.net ([169.254.8.53]) by EXCH-M03.ad.teamaol.com ([10.178.122.61]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 13:08:02 -0400 From: "Kelley, John" To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] Indirect mail flows Thread-Index: AQHPy5fbrBPbe5KR80O0WUuiDj8+FJv4vwaAgABLAIA= Date: Tue, 9 Sep 2014 17:08:02 +0000 Message-ID: References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.20.15.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <479917AAE48001499085906CB65C98B8@teamaol.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zfIvhJmhZE9Ak2SrGAdWfaAStXU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:08:06 -0000 On 9/9/14 4:39 AM, "Stephen J. Turnbull" wrote: >Kelley, John writes: > > > 1. Auto Forwards, principally where the email is munged in some way > > causing DKIM to fail. > > 2. Mailing lists; although the big ones seem to be rewriting the From > > (thanks). > >From what I've seen on Mailman Project lists[1], your users may not feel >the same way, though. There have been complaints to list owners that >they're getting singled out (a popular Mailman feature, for example, >checks DMARC policy and munges From or wraps the message only if it's >p=3Dreject). > >Have you had any such feedback? I have no such feedback, but it might not come to me. > > > 3. Groups (these might be considered a subset of mailing lists, but > > folks seem to think of them differently) > >What's a "group"? Specifically, how do messages get submitted to >groups and then injected into the mail system? If there are multiple >ways of submitting messages, does it matter which one is used? We had a pow-wow a few days ago and this came up. I believe that for DMARC purposes, we can refer to it as a mailing-list, but it seems as if people think of them differently. I believe that folks use the term group to identify things they "belong" to (neighborhood association, swimming pool) and the term list to identify things they subscribe to. I broke it apart simply because that is the way it was brought up to me. The inner workings are, I am sure, very similar to a mailing list. Perhaps a moderated mailing list. John Kelley > > >Footnotes:=20 >[1] Can't speak from personal experience, all my "p=3Dreject" >subscribers said "thanks for the heads-up" and changed posting >address. > From nobody Tue Sep 9 10:51:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356971A8798 for ; Tue, 9 Sep 2014 10:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9fjsT4PGsQN for ; Tue, 9 Sep 2014 10:51:05 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4F24C1A8784 for ; Tue, 9 Sep 2014 10:51:01 -0700 (PDT) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id CD3B980D18 for ; Tue, 9 Sep 2014 10:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1410285061; bh=W3DlbzOQ3eqW8SMpsrhPfC7ms8qQPx0IecJjab+WJMM=; h=Subject:From:In-Reply-To:Date:References:To:From; b=DExtUf5pD2oc0Q4Ya7ef2NIaqqW0ekfUmOlC4m6aNnTj98dnQwvVQDh10Ahp75LmK DM8GT18e8ipXk2WSa4cBdpNFXn0BUlBEHYNl6EAc+EE8PTGxpuRl0u6dd6MuAETf+z bhFkbZE8EHORZlovt6NVYxBlu0ULuwqQCEUxSZzE= 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: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 9 Sep 2014 10:50:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cs2DQnS9xJYyrIAaFajpaaYpRPs Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:51:07 -0000 On Sep 9, 2014, at 1:39 AM, Stephen J. Turnbull wrote: > Kelley, John writes: > >> 1. Auto Forwards, principally where the email is munged in some way >> causing DKIM to fail. >> 2. Mailing lists; although the big ones seem to be rewriting the From >> (thanks). > >> From what I've seen on Mailman Project lists[1], your users may not feel > the same way, though. There have been complaints to list owners that > they're getting singled out (a popular Mailman feature, for example, > checks DMARC policy and munges From or wraps the message only if it's > p=reject). Some of the changes that have been made to mailing lists to work around DMARC have made them significantly less useful. It unavoidably breaks the ability to search for emails or filter inbound mail by author email address. It also makes it hard / impossible to reply to the author, or see what domain the author is associated with - though that may be because the changes made by the mailing list operators aren't as well done as they could be rather than something unavoidable. Cheers, Steve From nobody Tue Sep 9 11:24:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A691A8864 for ; Tue, 9 Sep 2014 11:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVJX6ZvXlk-R for ; Tue, 9 Sep 2014 11:24:47 -0700 (PDT) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0522C1A00F8 for ; Tue, 9 Sep 2014 11:24:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3617; t=1410287080; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Dq4/a3Qy0XXuFC4k7c65mzEa9Go=; b=jCQELedMyWrJkAnuuW7p NbVQUauKaYwkgpnpxotesKxjH87i7RpdNeapG9Va5hrVp/j9jPW0Lij2L8LllrTd FJyOkgMsoYgL4MygEAnAscQrVfPs4208ybNTo1FKKMzMzquGhDTfFvu3UMMWlnI7 zBZ1edI3oG/MN8gRdgz61Tw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 09 Sep 2014 14:24:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1177178430.848.1448; Tue, 09 Sep 2014 14:24:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3617; t=1410286751; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HbX4oIZ pxIAMZDnhHDxkCJIjP7yHS+OfL/ub3PBvOfg=; b=z5VktMwVrMfELRi85kHlnbJ sL+gcTaLrUqkD/HOZ+oQx8cSgZXe3Thy2oJ2LnFqY/LZSdiQgfWmyYOry3OGYmq8 7mPhcbZFGHkoRiMKL9KhWz4JjHcRoWndyBlyue/28DJq348U1ozuewhKX8CXOpDZ rRosRvr8hs6PzKWha6Dk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 09 Sep 2014 14:19:11 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4064597890.9.5348; Tue, 09 Sep 2014 14:19:10 -0400 Message-ID: <540F45E7.5030907@isdg.net> Date: Tue, 09 Sep 2014 14:24:39 -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: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/B2rrUG-gWFQsBPOwaBcSUFaKtOo Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:24:53 -0000 That is should be expected when people monkey around with long time mail infrastructure. Its a bad idea and sets a terrible precedent by alluding to the idea "its normal." No its not normal. It will be exploited and probably its too late to put this one back if a few mailing list packages are already doing it. If isolated, fine, but it can't be IETF endorsed in any way. YAHOO does not want people to use their domain without permission. Period and the big gorilla has set the action in motion for many others to follow suit with strong policies that with DMARC will bring things because it lacks the definition for wider use cases. So we need the fastest way to get this resolution out there -- a POLICY LOOKUP METHOD with expanding use cases definitions that was long envisioned since the git-go. We been battling this for a long time and its really about what domain (1st or 3rd party) do we want to receivers to lookup? Well, one side wants receivers to look up some 3rd party trust entity (ala SSL) and the other side says, fine, but we also want the self-signing authority lookup as well - the ownership domain. There are conflicts between the two because the 3rd party guy does not want the 1st party guy to have any say over any its mail changes or tampering and/or forwarding. This "corollary" was unfortunately written into RFC5016. 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. Unfortunately, this is still a strong desire. Which is fine, but they don't want to even bother to ask the 1st party domain what does the correct or bad transaction is expected to LOOK like. It is this separation that the DKIM wants to maintain that has long held back the resolution to this problem. Keep it simple. -- HLS On 9/9/2014 1:50 PM, Steve Atkins wrote: > > On Sep 9, 2014, at 1:39 AM, Stephen J. Turnbull wrote: > >> Kelley, John writes: >> >>> 1. Auto Forwards, principally where the email is munged in some way >>> causing DKIM to fail. >>> 2. Mailing lists; although the big ones seem to be rewriting the From >>> (thanks). >> >>> From what I've seen on Mailman Project lists[1], your users may not feel >> the same way, though. There have been complaints to list owners that >> they're getting singled out (a popular Mailman feature, for example, >> checks DMARC policy and munges From or wraps the message only if it's >> p=reject). > > > Some of the changes that have been made to mailing lists to work > around DMARC have made them significantly less useful. > > It unavoidably breaks the ability to search for emails or filter inbound > mail by author email address. > > It also makes it hard / impossible to reply to the > author, or see what domain the author is associated with - though > that may be because the changes made by the mailing list operators > aren't as well done as they could be rather than something > unavoidable. > > Cheers, > Steve > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- HLS From nobody Tue Sep 9 11:40:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C151A00F6 for ; Tue, 9 Sep 2014 11:40:31 -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 po4DlSmvRsZN for ; Tue, 9 Sep 2014 11:40:29 -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 9FA4C1A0019 for ; Tue, 9 Sep 2014 11:40:29 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 8BCCB1C3912; Wed, 10 Sep 2014 03:40:28 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7CEC81A3915; Wed, 10 Sep 2014 03:40:28 +0900 (JST) From: "Stephen J. Turnbull" To: Steve Atkins In-Reply-To: References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 10 Sep 2014 03:40:28 +0900 Message-ID: <87r3zk63j7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WVWlesz962omaCahlfcVFA4xowk Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:40:31 -0000 Steve Atkins writes: > Some of the changes that have been made to mailing lists to work > around DMARC have made them significantly less useful. > It unavoidably breaks the ability to search for emails or filter > inbound mail by author email address. It's not unavoidable, but it's certainly beyond the capability of the vast majority of users to change their MUAs to deal with it well. Eg, in my MUA it's possible to treat any field as unstructured, so you can recognize addresses from the display name. You can also filter on both From and Reply-To at the same time. In the most recent releases of Mailman, it's possible to wrap a DMARC-triggering message in a message/rfc822 part, having the outer >From being the list, and the inner From (and the rest of the inner message) being as you like it. For the oddball MUA (mine) it's possible to program it to go into such messages (this feature is also useful for certain kinds of forwards, bounces, and digests) and find the inner from for search or filtering purposes. Again, I don't expect The Average Everyday MUA to support that soon. > It also makes it hard / impossible to reply to the author, Mailman automatically adds the author to Reply-To. If this results in a header like From: alist@example.org To: alist@example.org Reply-To: auser@p.reject.com the right thing happens. However, there are some cases, such as if the list was in the habit of munging Reply-To to the list, where you have a choice between too many addresses from a plain "reply" (if you set munging to *both* the author and the list) or the inability to automatically reply to author (if you munge to list only). I should update the wiki. > or see what domain the author is associated with That's the whole point of DMARC, to obfuscate the author unless they are using the domain's infrastructure to transmit the mail. So that's going to be hard to get around. The display name hack is available, though: From: "Alfred E. Neuman (auser@p.reject.com) via Some List" > - though that may be because the changes made by the mailing list > operators aren't as well done as they could be rather than > something unavoidable. Some mailing list management packages already do a substantially better job, so I would expect the problems to reduce to (a) systems that won't upgrade their software and (b) the genuinely hard or impossible cases within a few months. Steve From nobody Tue Sep 9 11:41:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B141A00EC for ; Tue, 9 Sep 2014 11:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 4tApgLXtqf8N for ; Tue, 9 Sep 2014 11:40:36 -0700 (PDT) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D6B1A0019 for ; Tue, 9 Sep 2014 11:40:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0NBN0067BD7IZP00@mta01.service.private> for dmarc@ietf.org; Tue, 09 Sep 2014 14:40:35 -0400 (EDT) X-WMU-Spam: Gauge=X, Probability=10% on Tue Sep 9 14:40:32 2014, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2014.9.9.183024 - Tue Sep 9 14:40:31 2014 Date: Tue, 09 Sep 2014 14:40:30 -0400 (EDT) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: "dmarc@ietf.org" In-reply-to: Message-id: References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LNy83CEONestCkbSe65DlhBRDIU Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:40:37 -0000 On Sep 9, 2014 at 17:08 -0000, Kelley, John wrote: =>On 9/9/14 4:39 AM, "Stephen J. Turnbull" wrote: =>>Kelley, John writes: =>> =>> > 1. Auto Forwards, principally where the email is munged in some way =>> > causing DKIM to fail. =>> > 2. Mailing lists; although the big ones seem to be rewriting the From =>> > (thanks). =>> =>>From what I've seen on Mailman Project lists[1], your users may not feel =>>the same way, though. There have been complaints to list owners that =>>they're getting singled out (a popular Mailman feature, for example, =>>checks DMARC policy and munges From or wraps the message only if it's =>>p=reject). =>> =>>Have you had any such feedback? => =>I have no such feedback, but it might not come to me. How are such modifications RFC5321 compliant? See section 3.9. ...the message header section (RFC5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected. =>> > 3. Groups (these might be considered a subset of mailing lists, but =>> > folks seem to think of them differently) =>> =>>What's a "group"? Specifically, how do messages get submitted to =>>groups and then injected into the mail system? If there are multiple =>>ways of submitting messages, does it matter which one is used? => => =>We had a pow-wow a few days ago and this came up. I believe that for =>DMARC purposes, we can refer to it as a mailing-list, but it seems as if =>people think of them differently. I believe that folks use the term group =>to identify things they "belong" to (neighborhood association, swimming =>pool) and the term list to identify things they subscribe to. I broke it =>apart simply because that is the way it was brought up to me. The inner =>workings are, I am sure, very similar to a mailing list. Perhaps a =>moderated mailing list. I thought a different RFC gives more detail, but see section 3.9.1 and 3.9.2 of RFC 5321. IMO both "lists" and "groups" are a sub-set of "exploders". The way I (and the MTA we run) differentiate the two is that "lists" change the RFC5321.MailFrom address for bounce handling (see RFC5321 section 3.9.2) while "groups" ("alias" in RFC5321 section 3.9.1) don't. -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From nobody Tue Sep 9 11:43:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41FC1A00FB for ; Tue, 9 Sep 2014 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn0AjfKIohk4 for ; Tue, 9 Sep 2014 11:43:22 -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 DBE791A00F6 for ; Tue, 9 Sep 2014 11:43:21 -0700 (PDT) Received: (qmail 82734 invoked from network); 9 Sep 2014 18:43:20 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Sep 2014 18:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f73.540f4a48.k1409; i=johnl@user.iecc.com; bh=nvGx4x4fTeYHHstK56wi6etcrNHofsectex0hfyYcCo=; b=byb1Tl+/lVTzmM4exzk6Y+szr0ewBEYkPvpgwmSzOTSeMmxcEGo2I+AztI6M7cRkMIXhPrWqMu2j0AslHbPq/41b+PQjcXAb6TeD5hrnVan7VFskPs4Bps9HHjK/NK2NqJkcnKSM7nohkmOPE+eEvEugmtCRWqW4bkswyCabXuv4uIFBLwMjTQagLNcZ7tLwmjyhEF7EFA8VzcmICZKC5VLLiRjzsgSrwPxEtOWUpupYLnMjCmyKndVfyvq4cooA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f73.540f4a48.k1409; olt=johnl@user.iecc.com; bh=nvGx4x4fTeYHHstK56wi6etcrNHofsectex0hfyYcCo=; b=viLMVIPvpjHSC8umBVlSIQTKNPz6MNJthrva3fDDVPz4aQNYMumScJ3gcNbTS3e2KRHKL4Qt/OLDLnQRhpgJCvO/U98LFAVCfeyVm6R2Yj0go8bjXxe108WfaJTBJ2eg6mgv/oMqectVMzzRG5j3LPzmy+T3Symt5Pk8UbZfrgKnSKA6nT2sl9PWre48blWzmGA7xaFyduTbKzisESweUzc1UeThgX+DUOKcc3+AdUkwae92Vc90PfiLm5f2inPc Date: 9 Sep 2014 18:42:58 -0000 Message-ID: <20140909184258.3954.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TCuI6JJo_DjrzpyIbpXiJ08MT0w Cc: john.kelley@teamaol.com Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 18:43:22 -0000 >2. Mailing lists; although the big ones seem to be rewriting the From >(thanks). Just for the record, the mailing lists I know that are rewriting the From: line are not doing so because the change is in the interest of their users, but because of the enormous market power of the mail systems that will no longer deliver list mail in the form that the users are accustomed to and prefer. R's, John From nobody Tue Sep 9 20:44:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585DA1A0496 for ; Tue, 9 Sep 2014 20:44:14 -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 ovYuDtGu8dXQ for ; Tue, 9 Sep 2014 20:44:12 -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 A27F31A047C for ; Tue, 9 Sep 2014 20:44:12 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id C5A771C395A; Wed, 10 Sep 2014 12:44:10 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B65491A3915; Wed, 10 Sep 2014 12:44:10 +0900 (JST) From: "Stephen J. Turnbull" To: Derek Diget In-Reply-To: References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 10 Sep 2014 12:44:10 +0900 Message-ID: <87ppf45ed1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UqVeyCzA4-BGyPDd-axfuL3wBro Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 03:44:14 -0000 Derek Diget writes: > How are such modifications RFC5321 compliant? See section 3.9. > > ...the message header section (RFC5322 [4]) MUST be left unchanged; in > particular, the "From" field of the header section is unaffected. RFC 5321 is irrelevant in the case of mailing list management software (MLM) like GNU Mailman, because the changes don't happen in the MTA. Mail is received, processed outside of the purview of RFC 5321 (including the usual alterations made by the MLM), and then reinjected into the mail transport system. Note the last paragraph from 3.9.2: There exist mailing lists that perform additional, sometimes extensive, modifications to a message and its envelope. Such mailing lists need to be viewed as full MUAs, which accept a delivery and post a new message. where "new message" clearly should *not* be construed to necessarily mean "new" in the sense of changing RFC5322.Message-Id. It means wrapping some version of the message in a fresh "envelope". OTOH, RFC 5322 specifies the content of the From field to be the address(es) of the author(s), and that it is an originator field. I don't have a channel to the original intent of the RFC authors, but I personally interpret "originator field" to mean that From-munging is violation of that RFC, as per policy of most mailing lists (in the sense of "GNU Mailman", not RFC 5321. Like John Levine, I don't like From-munging, and consider it a serious imposition. > I thought a different RFC gives more detail, but see section 3.9.1 and > 3.9.2 of RFC 5321. I interpreted John Kelley to be describing difficulties users report. > IMO both "lists" and "groups" are a sub-set of "exploders". The > way I (and the MTA we run) differentiate the two is that "lists" > change the RFC5321.MailFrom address for bounce handling (see > RFC5321 section 3.9.2) while "groups" ("alias" in RFC5321 section > 3.9.1) don't. That's a useful distinction, although we should probably be careful about terminology here. I don't think RFC 5321 terminology is a good default, since the applications that are hurting are generally not bound at all by RFC 5321, being MUAs in the sense of that RFC, as described by the paragraph I quoted above. But it's fine to deliberately borrow from RFC 5321. For the distinction Derek describes above, I like the term "mailing list manager" (MLM) for exploders that set RFC5321.MailFrom to themselves and "alias" for exploders that don't. I think that even if the WG members all agree on "group" for the latter, some of the people whose use cases we'll discuss are going to be using "group" for something else. I'd rather not have to deal with that. I can live with "list" instead of "MLM", though. From nobody Thu Sep 11 04:42:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40E71A8940 for ; Thu, 11 Sep 2014 04:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.38 X-Spam-Level: X-Spam-Status: No, score=-98.38 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_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 qz9MIgQWfCdE for ; Thu, 11 Sep 2014 04:42:01 -0700 (PDT) Received: from catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5621A1A0B7C for ; Thu, 11 Sep 2014 04:41:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4216; t=1410435683; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=rrvbl+O M/uZ3DROpIzZ0EluALMU=; b=tkGDymm9ZatmuFwjr1nlFD5kqLWw9YWIO0mRYPj zozt3jXxVzrqbjaJwqWJOo0QSAslbm0V3mkQYVV42N8ttjN3imHEbBn/3y9HHX1b Ac0qlQzYz1rasXoXJbg6qjfh1VQeX0iyFsDL3QG2mZzPrygSIkatN0IKMFAz8icS /f7Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 11 Sep 2014 07:41:23 -0400 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 1325780162.4089.3592; Thu, 11 Sep 2014 07:41:23 -0400 References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppf45ed1.fsf@uwakimon.sk.tsukuba.ac.jp> Mime-Version: 1.0 (1.0) In-Reply-To: <87ppf45ed1.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1E8C87A0-0A33-4E7B-B129-5EC68BBB3DE0@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Thu, 11 Sep 2014 07:41:20 -0400 To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1bX6GoeqGa_EZEE-zzTwilOO-YY Cc: "dmarc@ietf.org" , Derek Diget Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 11:42:04 -0000 For multiple decades, starting with mail systems predating RFC822, with ever= yone one of them there was a common mail engineering taboo, "thou shall not t= amper with mail" and one of the primary anchoring fields, the author of the m= essage was a principle field you didn't screw around with. You either get i= t or you don't. Mostly those at the application level didn't and it's under= standable. But at the system level, it will cause problems. Even if there w= as a legitimate transformation, it needs to be reversible and the security r= emained intact. In this rewrite, it is neither. It was done prematurely wit= hout even trying to fix DMARC first and this irresponsible rewrite action wi= ll cause problems for everyone. The door was cracks opened and even if ther= e is a new solution to address it, you can't put this one away. The bad guy= s now know how to get around DMARC security. This is not good mail engineer= ing. I make no apology for having strong moral ethical feelings about it. = =20 -- Hector Santos http://www.santronics.com > On Sep 9, 2014, at 11:44 PM, "Stephen J. Turnbull" wr= ote: >=20 > Derek Diget writes: >=20 >> How are such modifications RFC5321 compliant? See section 3.9. >>=20 >> ...the message header section (RFC5322 [4]) MUST be left unchanged; in=20= >> particular, the "From" field of the header section is unaffected. >=20 > RFC 5321 is irrelevant in the case of mailing list management software > (MLM) like GNU Mailman, because the changes don't happen in the MTA. > Mail is received, processed outside of the purview of RFC 5321 > (including the usual alterations made by the MLM), and then reinjected > into the mail transport system. Note the last paragraph from 3.9.2: >=20 > There exist mailing lists that perform additional, sometimes > extensive, modifications to a message and its envelope. Such > mailing lists need to be viewed as full MUAs, which accept a > delivery and post a new message. >=20 > where "new message" clearly should *not* be construed to necessarily > mean "new" in the sense of changing RFC5322.Message-Id. It means > wrapping some version of the message in a fresh "envelope". >=20 > OTOH, RFC 5322 specifies the content of the =46rom field to be the > address(es) of the author(s), and that it is an originator field. I > don't have a channel to the original intent of the RFC authors, but I > personally interpret "originator field" to mean that From-munging is > violation of that RFC, as per policy of most mailing lists (in the > sense of "GNU Mailman", not RFC 5321. Like John Levine, I don't like > From-munging, and consider it a serious imposition. >=20 >> I thought a different RFC gives more detail, but see section 3.9.1 and=20= >> 3.9.2 of RFC 5321. >=20 > I interpreted John Kelley to be describing difficulties users report. >=20 >> IMO both "lists" and "groups" are a sub-set of "exploders". The >> way I (and the MTA we run) differentiate the two is that "lists" >> change the RFC5321.Mail=46rom address for bounce handling (see >> RFC5321 section 3.9.2) while "groups" ("alias" in RFC5321 section >> 3.9.1) don't. >=20 > That's a useful distinction, although we should probably be careful > about terminology here. I don't think RFC 5321 terminology is a good > default, since the applications that are hurting are generally not > bound at all by RFC 5321, being MUAs in the sense of that RFC, as > described by the paragraph I quoted above. >=20 > But it's fine to deliberately borrow from RFC 5321. For the > distinction Derek describes above, I like the term "mailing list > manager" (MLM) for exploders that set RFC5321.Mail=46rom to themselves > and "alias" for exploders that don't. I think that even if the WG > members all agree on "group" for the latter, some of the people whose > use cases we'll discuss are going to be using "group" for something > else. I'd rather not have to deal with that. I can live with "list" > instead of "MLM", though. >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Sat Sep 13 09:43:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5391A0013 for ; Sat, 13 Sep 2014 09:43:53 -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 sxtz7y9pJyfn for ; Sat, 13 Sep 2014 09:43:50 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FFC1A0010 for ; Sat, 13 Sep 2014 09:43:50 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 4AB98D0431A; Sat, 13 Sep 2014 12:43:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410626629; bh=9lZW4nxiEr5D0tnS6teCdSuYAPBnAPpkZn3HTlXklQA=; h=From:To:Subject:Date:From; b=QlVl1pS9+hkjVR0JhuvWdHSUfFBqY1ePFQEou0w/8C5JTxcrCATkKbPQUAIRuBCgG DZ4fnUUmbNhjqJdyALzskw7hMxIuiW+O9jHG7IIDGz7uuRVd9o4MtzDnUmWnKrxi/T z9Vc0KWAefMecNbf3WWgZ3ONpeENnHrvH7cMT7G0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 17B79D040B1; Sat, 13 Sep 2014 12:43:48 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Sat, 13 Sep 2014 12:43:45 -0400 Message-ID: <1619146.fJgkRhlbM5@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tdOj75X6n2q1-Un6KfIf3hDCasQ Subject: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 16:43:53 -0000 My MUA of choice (Kmail for what it's worth) has a very nice feature called "Reply to Mailing List" It uses the List-Post field to determine the address to set the reply to. I find this very useful, since the many mailing lists I am subscribed to are set up differently, so sometimes "Reply" goes to the list and sometime it goes to the original sender. This got me thinking that it might be useful to standardize a way to communicate who the original author was in cases where the mailing list is configured to rewrite From to avoid DMARC issues. Google is already doing this in a non-standard way in Google Groups. You'll see something like: X-Original-From: If this were standardized, then MUA authors could use it to add a new reply option, something like "Reply to Mailing List Author". This would mitigate some of the damage caused by From rewriting as a DMARC damage avoidance technique. One can argue all day if From rewriting should be done or not, but it is and it's not going to do away. Here's the current set of List-* header fields added by this list: List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Perhaps the new one could be: List-Author: This falls within the working group charter for "Addressing the issues with indirect mail flows", specifically, "Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity." In terms of work items, I think it is definitely within the scope of "Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them." I doubt, however, that standardization of a new List-foo field should be buried in a single large document that describes the entire issue/mitigations situation for DMARC. If this seems reasonable to pursue, I think it should be it's own draft that the result of this work item can then reference. If we do this, I can guarantee at least one MUA implementation. Scott K From nobody Sat Sep 13 10:08:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41E01A0015 for ; Sat, 13 Sep 2014 10:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POZVMNvlAqXC for ; Sat, 13 Sep 2014 10:08:13 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED621A0013 for ; Sat, 13 Sep 2014 10:08:13 -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 677298124B for ; Sat, 13 Sep 2014 10:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1410628093; bh=klPfg6BvwK7TiP+b2CIySZyUUO4lFyradumDMlkCq8s=; h=Subject:From:In-Reply-To:Date:References:To:From; b=RjxcXJI1cgonZLqw3s7IsOsVQacggRZ1gYxFJ/H3WETd+C8mq/EcOFb+GBjmMdiJ/ lJTVT/KRtANT4Lh+6l0zqippNBaxDPWlfgn5Iv935ADWHqEnfnkwHmKMnRCzPNWlWL RhcVXyDMK5TaIOQEAhWBcPvVbvGzqpkDcAMDmC18= 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: <1619146.fJgkRhlbM5@scott-latitude-e6320> Date: Sat, 13 Sep 2014 10:08:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XuLpgMVqLrc-SpVU1DvVh4vSX3Q Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 17:08:17 -0000 On Sep 13, 2014, at 9:43 AM, Scott Kitterman = wrote: > This got me thinking that it might be useful to standardize a way to=20= > communicate who the original author was in cases where the mailing = list is=20 > configured to rewrite =46rom to avoid DMARC issues. Google is already = doing this=20 > in a non-standard way in Google Groups. You'll see something like: >=20 > X-Original-From: >=20 > If this were standardized, then MUA authors could use it to add a new = reply=20 > option, something like "Reply to Mailing List Author".=20 >=20 >=20 > In terms of work items, I think it is definitely within the scope of = "Draft=20 > description of interoperability issues for indirect mail flows and = plausible=20 > methods for reducing them." I doubt, however, that standardization of = a new=20 > List-foo field should be buried in a single large document that = describes the=20 > entire issue/mitigations situation for DMARC. It's a redefinition of the current meaning of the From: field, and the = addition of another header to take the place of the existing From: field. That's bigger than = DMARC, and it seems like the 5322 people should be involved in that discussion. Cheers, Steve= From nobody Sat Sep 13 10:21:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C207E1A001A for ; Sat, 13 Sep 2014 10:21:40 -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 3G4e4vrCRvlK for ; Sat, 13 Sep 2014 10:21:39 -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 707931A0015 for ; Sat, 13 Sep 2014 10:21:39 -0700 (PDT) Received: from [172.20.180.167] ([198.94.221.88]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8DHLZ8m023939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 13 Sep 2014 10:21:39 -0700 Message-ID: <54147C54.3020604@dcrocker.net> Date: Sat, 13 Sep 2014 10:18:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <1619146.fJgkRhlbM5@scott-latitude-e6320> In-Reply-To: <1619146.fJgkRhlbM5@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 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, 13 Sep 2014 10:21:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5Dy0d9BB0itO8SGrdLvIxruD3Gw Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 17:21:40 -0000 On 9/13/2014 9:43 AM, Scott Kitterman wrote: > X-Original-From: > > If this were standardized, then MUA authors could use it to add a new reply > option, something like "Reply to Mailing List Author". This is worth exploring. In an abstract sense, this is "merely" another approach to encapsulation. It uses additional header views, rather than MIME wrapping, but I think it achieves the same end. On 9/13/2014 10:08 AM, Steve Atkins wrote: > It's a redefinition of the current meaning of the From: field, and > the addition of anotherheader to take the place of the existing From: > field. That's bigger than DMARC, and itseems like the 5322 people > should be involved in that discussion. Steve is of course correct. But I think that no matter what gravitate towards, we are talking about a change to the 'model' of signaling the distinction between the 'author' and whoever is an intermediary. I am pretty sure that my earlier observation will prove true, no matter what we choose. That is, if it works for scenarios with good actors, it will also be useful for bad actors. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Sep 13 10:21:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF91A0028 for ; Sat, 13 Sep 2014 10:21:42 -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 iB6qujGNv33b for ; Sat, 13 Sep 2014 10:21:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F941A0015 for ; Sat, 13 Sep 2014 10:21:41 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8C209D045FB; Sat, 13 Sep 2014 13:21:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410628900; bh=7ThJ+SiFAPVyheFbmTyMw+Os1cbAt2lWBRGCbIiZxKk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dg7n8AtXJJ6XDeJUVXtnjLEppVKmJjGS8+3+CBuHBsBIfXlDhOupJ8eibheFo3G8l t5qccsYVZqXZGERi1CX3AmY/Mt7p1A8wKbBIJ3E4hqGlo9XvDV0vY689TG+7UoQU0S 1oeZYIbMkhLDw7Ka/X06Ip0doRrHSk9iRiaA7NWI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6104ED04558; Sat, 13 Sep 2014 13:21:40 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Sep 2014 13:21:36 -0400 Message-ID: <5095831.vR8OcjAh40@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Whsmu4G9PqD3njkJjC8cZzg1SnM Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 17:21:43 -0000 On Saturday, September 13, 2014 10:08:11 Steve Atkins wrote: > On Sep 13, 2014, at 9:43 AM, Scott Kitterman wrote: > > This got me thinking that it might be useful to standardize a way to > > communicate who the original author was in cases where the mailing list is > > configured to rewrite From to avoid DMARC issues. Google is already doing > > this in a non-standard way in Google Groups. You'll see something like: > > > > X-Original-From: > > > > If this were standardized, then MUA authors could use it to add a new > > reply > > option, something like "Reply to Mailing List Author". > > > > > > In terms of work items, I think it is definitely within the scope of > > "Draft > > description of interoperability issues for indirect mail flows and > > plausible methods for reducing them." I doubt, however, that > > standardization of a new List-foo field should be buried in a single > > large document that describes the entire issue/mitigations situation for > > DMARC. > > It's a redefinition of the current meaning of the From: field, and the > addition of another header to take the place of the existing From: field. > That's bigger than DMARC, and it seems like the 5322 people should be > involved in that discussion. Rewriting From or adding the new List-foo redefines it? Scott K From nobody Sat Sep 13 13:38:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143741A0118 for ; Sat, 13 Sep 2014 13:38:28 -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 TZWA0rEsz1iy for ; Sat, 13 Sep 2014 13:38:26 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D3B1A010C for ; Sat, 13 Sep 2014 13:38:26 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 72BB9D046AA; Sat, 13 Sep 2014 16:38:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410640705; bh=7ujZAORa8PvDxX1aDT8OowSZQg015tsl9ApV0CVQPo4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Xz/CyjbET9km1Owj8Of44U1n9j8QVvuZ9BPBC12fdq3iXQ0HFoN+puTwgp7arha14 0lJFad4Q3PcGaD8q6RTyVvglDGh/vaT3c16rsWnhk7eqQlcFzW0LIq2utYS6LOw6wa TUaNnndzpIo4IR5ACYTx5U5TimMAfS3/xC9s5Q5k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 40F87D0452E; Sat, 13 Sep 2014 16:38:25 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Sep 2014 16:38:21 -0400 Message-ID: <3999457.XoR0KUjBNM@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <54147C54.3020604@dcrocker.net> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <54147C54.3020604@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/B_G2BnOx3Df2sMKmq72XmmnlcGE Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 20:38:28 -0000 On Saturday, September 13, 2014 10:18:12 Dave Crocker wrote: > On 9/13/2014 9:43 AM, Scott Kitterman wrote: > > X-Original-From: > > > > If this were standardized, then MUA authors could use it to add a new > > reply > > option, something like "Reply to Mailing List Author". > > This is worth exploring. In an abstract sense, this is "merely" another > approach to encapsulation. It uses additional header views, rather than > MIME wrapping, but I think it achieves the same end. While the MIME wrapping idea "works", it seemed overly complicated to deal with U/I wise and it makes messages "Look funny". The new header field should be easier to deal with in both the MLM and the MUA. Also, since I already see X-Original-From in use, it builds on existing practice. Given X-Original-From is being used, I think it'd make sense to standardize a field name for this sooner rather than later before the non-standard one becomes too firmly entrenched. > On 9/13/2014 10:08 AM, Steve Atkins wrote: > > It's a redefinition of the current meaning of the From: field, and > > the addition of anotherheader to take the place of the existing From: > > field. That's bigger than DMARC, and itseems like the 5322 people > > should be involved in that discussion. > > Steve is of course correct. > > But I think that no matter what gravitate towards, we are talking about > a change to the 'model' of signaling the distinction between the > 'author' and whoever is an intermediary. > > I am pretty sure that my earlier observation will prove true, no matter > what we choose. That is, if it works for scenarios with good actors, it > will also be useful for bad actors. For bad actors, I don't think it gives them anything more than they already have with reply-to. For good actors, there are advantages. So I agree in theory, but in practice, I don't think it'll make a difference. Scott K From nobody Sat Sep 13 14:07:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43421A0142 for ; Sat, 13 Sep 2014 14:07:03 -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 f-oabkc8eDbM for ; Sat, 13 Sep 2014 14:07:02 -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 D3FE21A0141 for ; Sat, 13 Sep 2014 14:07:02 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8DL6w2s028124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 13 Sep 2014 14:07:02 -0700 Message-ID: <5414B11D.6080203@dcrocker.net> Date: Sat, 13 Sep 2014 14:03:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Scott Kitterman , dmarc@ietf.org References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <54147C54.3020604@dcrocker.net> <3999457.XoR0KUjBNM@scott-latitude-e6320> In-Reply-To: <3999457.XoR0KUjBNM@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 13 Sep 2014 14:07:02 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/khrTg_0DdvbnUlsyOgMROVd7Hi4 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 21:07:04 -0000 On 9/13/2014 1:38 PM, Scott Kitterman wrote: >> This is worth exploring. In an abstract sense, this is "merely" another >> approach to encapsulation. It uses additional header views, rather than >> MIME wrapping, but I think it achieves the same end. > > While the MIME wrapping idea "works", it seemed overly complicated to deal I wasn't arguing preference or superiority of either approach. I merely wanted to note that they are in the same conceptual bin. I should also note that as soon as we go down this path of design thinking (independent of which might be preferred) we should carefully consider costs of making changes. For example, changing all the MUAs in the world, versus changing all the mailing list software... > For bad actors, I don't think it gives them anything more than they already > have with reply-to. For good actors, there are advantages. So I agree in > theory, but in practice, I don't think it'll make a difference. Actually, it does. Reply-to does not make assertions of authorship. The type of change being contemplated does. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Sep 13 14:29:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03B1A00FD for ; Sat, 13 Sep 2014 14:29:02 -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 GT-PsL9zY0Jw for ; Sat, 13 Sep 2014 14:29:01 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082D11A00DA for ; Sat, 13 Sep 2014 14:29:00 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 1FBC9D0470D; Sat, 13 Sep 2014 17:29:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410643740; bh=bgWK1n3iD/JXO7zb7OAdBLEkn4WcBHBkk+b3atImXso=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZGsbk5pPHNrIabdE7KTeRiZM2lpscRP2YRo+/3omtj9eMMv1+xeojeZ21g37SfzC7 3QNjhncG1z5jP2VHJDwMQpZC8rqHsdPF+i4AvrXxrF1imr7AG1X+cQEWfzEY4Hj4Oa 8jy48KSMMr0rwQuqCu0LB3HtuplDgNGI3gWTKsqM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E7E5AD046C3; Sat, 13 Sep 2014 17:28:59 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Sep 2014 17:28:56 -0400 Message-ID: <1649333.nlP8KdUCtY@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5414B11D.6080203@dcrocker.net> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <3999457.XoR0KUjBNM@scott-latitude-e6320> <5414B11D.6080203@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jiqT7woD26vwRtgN_eNhq3OuP50 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 21:29:02 -0000 On Saturday, September 13, 2014 14:03:25 Dave Crocker wrote: > On 9/13/2014 1:38 PM, Scott Kitterman wrote: > >> This is worth exploring. In an abstract sense, this is "merely" another > >> approach to encapsulation. It uses additional header views, rather than > >> MIME wrapping, but I think it achieves the same end. > > > > While the MIME wrapping idea "works", it seemed overly complicated to deal > > I wasn't arguing preference or superiority of either approach. I merely > wanted to note that they are in the same conceptual bin. > > I should also note that as soon as we go down this path of design > thinking (independent of which might be preferred) we should carefully > consider costs of making changes. > > For example, changing all the MUAs in the world, versus changing all the > mailing list software... I'm confident we're going to end up with a portfolio of mitigations, similar to what's in the Appendices of RFC 7208. I'm equally confident that despite the distaste many of us feel when we consider it, rewriting From in the MLM is going to be on the list of mitigations. It seems to be the most popular in use. It's not going away. Given that, I'm not sure where your proposed cost comparison could make a great difference. To mitigate the impacts of rewriting from (in this case losing information on the original author of the message and having an easy way to send a reply to them rather than the list), it's going to take both MLM and MUA changes to make it work well. Eventually, MUAs adapt to provide popular features. If this idea proves popular to their target audience, they'll adopt it, if it doesn't, they won't. > > For bad actors, I don't think it gives them anything more than they > > already > > have with reply-to. For good actors, there are advantages. So I agree in > > theory, but in practice, I don't think it'll make a difference. > > Actually, it does. Reply-to does not make assertions of authorship. > The type of change being contemplated does. How much difference does that make to end users? I mash a button than get a message going back to an address. They both could do that. Scott K From nobody Sat Sep 13 14:39:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196491A00E5 for ; Sat, 13 Sep 2014 14:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJW33tKMOU2N for ; Sat, 13 Sep 2014 14:39:12 -0700 (PDT) Received: from mail.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D98921A0089 for ; Sat, 13 Sep 2014 14:39:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3774; t=1410644348; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Z6neiJa3vHQah/v/6s7LFqoQIls=; b=RYWxAePYGlx8s/BnNBU9 f6FQTEV3jtXk0wLbPqA2jjMXWoF/XgiNErJmofQECnC3s7daSmnaQYdGNmbcfRN3 17qrYy+T6ya5bpgH+/+8TjfVhJN+7KX5ZG2ASz20mfNPRfZ6iMf2OV4tvusihv9o LB17eVamC+rddtf2gibd1WY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 13 Sep 2014 17:39:08 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1534442872.7465.5556; Sat, 13 Sep 2014 17:39:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3774; t=1410644012; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=p6Na8qv V1dQHPUTc9IMSrS/aXLY9Yoyq/qRoAFuRKmE=; b=W5cDrPubYs4nlwToEG4QTu+ n7PGhIMZIswQMHyn7FJS3owg0Q7ruvvg1gyEhytACzcXA20PLEAYlNjWetnwaH72 +ZKlkF+vmV1FAtr5uxU9AvzDHH082RNb/AVaOQt0cNP3vRQjjcxndih0+xnzyKP/ K5D/5TPYKWAxnzPRI6QU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 13 Sep 2014 17:33:32 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 126892735.9.4340; Sat, 13 Sep 2014 17:33:32 -0400 Message-ID: <5414B982.3000600@isdg.net> Date: Sat, 13 Sep 2014 17:39:14 -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: <1619146.fJgkRhlbM5@scott-latitude-e6320> In-Reply-To: <1619146.fJgkRhlbM5@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MCshbuutSOqmWF0F3Jm-lv521nM Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 21:39:16 -0000 This is a GATEWAY concept. Transformations and its need to be reversible with NO LOST OF SECURITY. Gateways help with heterogeneous mail networking and that is what we are basically creating here. So one way to solve this is for a MEMBER of a list to an outbound/inbound translation alias, where the LIST would replace the incoming 5322.From Address with a LIST-DOMAIN-OWNED 5322.From Membership address and it is this address used with the resigned mail. A a new list header can be used to indicate that this transformation has taken place. BUT.... WE STILL NEED THE ORIGINAL DOMAIN TO AUTHORIZE THIS TRANSFORMATION -- A Lookup Policy protocol. Even with an in-band method, it needs to be verifiable. This is what everyone keeps forgetting. We came up with all sorts of ideas to make it all work over the years, but it required the original domain authorization and/or allowance for a secured list transformation to take place. -- HLS On 9/13/2014 12:43 PM, Scott Kitterman wrote: > My MUA of choice (Kmail for what it's worth) has a very nice feature called > "Reply to Mailing List" It uses the List-Post field to determine the address > to set the reply to. I find this very useful, since the many mailing lists I > am subscribed to are set up differently, so sometimes "Reply" goes to the list > and sometime it goes to the original sender. > > This got me thinking that it might be useful to standardize a way to > communicate who the original author was in cases where the mailing list is > configured to rewrite From to avoid DMARC issues. Google is already doing this > in a non-standard way in Google Groups. You'll see something like: > > X-Original-From: > > If this were standardized, then MUA authors could use it to add a new reply > option, something like "Reply to Mailing List Author". > > This would mitigate some of the damage caused by From rewriting as a DMARC > damage avoidance technique. One can argue all day if From rewriting should be > done or not, but it is and it's not going to do away. > > Here's the current set of List-* header fields added by this list: > > List-Id: "Domain-based Message Authentication, Reporting, > and Compliance \(DMARC\)" > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > > Perhaps the new one could be: > > List-Author: > > This falls within the working group charter for "Addressing the issues with > indirect mail flows", specifically, "Message modification by an intermediary, to > avoid authentication failures, such as by using specified conventions for > changing the aligned identity." > > In terms of work items, I think it is definitely within the scope of "Draft > description of interoperability issues for indirect mail flows and plausible > methods for reducing them." I doubt, however, that standardization of a new > List-foo field should be buried in a single large document that describes the > entire issue/mitigations situation for DMARC. > > If this seems reasonable to pursue, I think it should be it's own draft that > the result of this work item can then reference. If we do this, I can > guarantee at least one MUA implementation. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Sat Sep 13 14:42:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFED1A00AA for ; Sat, 13 Sep 2014 14:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys51s_gzkydf for ; Sat, 13 Sep 2014 14:42:31 -0700 (PDT) Received: from mail.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5517A1A0089 for ; Sat, 13 Sep 2014 14:42:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=821; t=1410644549; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GCFZyouN3guJpWqahCd21WG/7rg=; b=wRSNMy/RP5W34G9Dm3ma FMKfMd2qAkY/8O2kRKXHlSN/JRH4mKKVdzS4CDkjZ+QekClyctYerCQos+qdSGNs F33M6ibTaCv+qYl/g8O/+22DJf+5CnWE9BpnjInw+y9aClJMPiZ+wW9C9Mf0hDAD VGbLjYAwZn+DNnuD+f4TWv4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 13 Sep 2014 17:42:28 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1534643037.7465.5768; Sat, 13 Sep 2014 17:42:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=821; t=1410644208; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=alptfsP 7/AWCCMfpTUdM0eKh43Z6dmPXsWx4mq1bFfE=; b=UfrTGdy9AUjVg5NRmTF+DOS SSwUrS7dnI1bVbI7CUyXTfrZ/SA3Bsy3elf9Cm2rO2PVBXw3m7X/IWh/AaI49dip Ytf6HdD3duc6l3gx+6/PfISlHXtTad7XlVTyHg60WN3217BgsUExXStOJp+t35p6 ZqHlQ4/nhj7qGni465A8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 13 Sep 2014 17:36:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 127087594.9.1172; Sat, 13 Sep 2014 17:36:47 -0400 Message-ID: <5414BA45.9070805@isdg.net> Date: Sat, 13 Sep 2014 17:42:29 -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: <1619146.fJgkRhlbM5@scott-latitude-e6320> <3999457.XoR0KUjBNM@scott-latitude-e6320> <5414B11D.6080203@dcrocker.net> <1649333.nlP8KdUCtY@scott-latitude-e6320> In-Reply-To: <1649333.nlP8KdUCtY@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JQ_jUBSq5L7WsOIvq72Y9EteDXg Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 21:42:33 -0000 On 9/13/2014 5:28 PM, Scott Kitterman wrote: > I'm confident we're going to end up with a portfolio of mitigations, similar to > what's in the Appendices of RFC 7208. I'm equally confident that despite the > distaste many of us feel when we consider it, rewriting From in the MLM is > going to be on the list of mitigations. It seems to be the most popular in > use. It's not going away. I hope not. No doubt if its not secured as I mentioned in my last post, its going to get filtered just like we added the 5322 Double From FILTER test as well before DKIM even sees it. This rewrite will get exploited and it is irresponsible to promote it. I will not add it to our Wildcat! LIST Server Product line and will use the idea that others do as marketing leverage against them. How about that? -- HLS From nobody Sat Sep 13 15:00:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0571A0079 for ; Sat, 13 Sep 2014 14:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MRncd0kMEkO for ; Sat, 13 Sep 2014 14:59:57 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id BB6301A0032 for ; Sat, 13 Sep 2014 14:59:57 -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 8D46280EC1 for ; Sat, 13 Sep 2014 14:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1410645597; bh=M435UBLyxgHsyhK+o9DT37nA3anSUfuJjbXmjEkRe0Q=; h=Subject:From:In-Reply-To:Date:References:To:From; b=F1Y/Q+n/9vDiQx5zksaucphLeMMxypAN4pXO43ewGaYPqfhC6JszYZGDwWv3zbbC9 u43MsqDEVK0OZ2r+Slt9hLLjtlOaAA2VVawo3WmsKlLeyW3qr5cUqhqJ1HmafUjzxd 4fhV5enGlmtm9POKK7CfOBE+5HtmhryOClCJGZxU= 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: <5095831.vR8OcjAh40@scott-latitude-e6320> Date: Sat, 13 Sep 2014 14:59:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Fhx3hlMN7qIHZDJfkLr0moi6-F8 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 21:59:59 -0000 On Sep 13, 2014, at 10:21 AM, Scott Kitterman = wrote: >>=20 >> It's a redefinition of the current meaning of the From: field, and = the >> addition of another header to take the place of the existing From: = field. >> That's bigger than DMARC, and it seems like the 5322 people should be >> involved in that discussion. >=20 > Rewriting =46rom or adding the new List-foo redefines it? Yes. =46rom 5322: The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message." The proposal here is to use the From: field to specify the mailbox of the agent responsible for the actual transmission of the message (the mailing list manager); the value that 5322 specifies as the Sender. That's a significant change to 5322. Also, to add a new field that will contain the mailbox of the person responsible for writing the message; what 5322 defines as the From: field. While adding a new header is fine, adding one that is defined to contain the value that 5322 says is the value of the From: header is stepping on some toes. It's a significant change to RFC 5322, so any discussion of it needs to take that into account (perhaps by having the appropriate IETF WG involved in the discussion earlier rather than later). Cheers, Steve From nobody Sat Sep 13 15:35:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692B41A00F2 for ; Sat, 13 Sep 2014 15:35:12 -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 csxtCk5Vy32R for ; Sat, 13 Sep 2014 15:35:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054281A00E0 for ; Sat, 13 Sep 2014 15:35:10 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 26905D043B9; Sat, 13 Sep 2014 18:35:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410647710; bh=OacwDDJ68ZFsyA/NjSQWT8GTwXa4E5m2UWx3xV33hsE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bLRuVPm1i8tR2NZlFqFgtfj1Zi6NEbZdEua5WhSpNJXkiNxH6BRAMrd8qgtHs7Iuq R58eRjX5sn8Fecu5Zpj4/biU0NaC1nl8uVWQTjsNeti5rCJNOHzpa9HntzDS3MOjZf qBo9dWQ57w1OB2HHMRKglZ7KQsn6UA7NmkPPFuU0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id F131FD04216; Sat, 13 Sep 2014 18:35:09 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Sep 2014 18:35:06 -0400 Message-ID: <3657835.KmjXCTr7Sk@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/afBPtJipQBOKeBSpnH3QFmkCuqs Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 22:35:12 -0000 On Saturday, September 13, 2014 14:59:56 Steve Atkins wrote: > On Sep 13, 2014, at 10:21 AM, Scott Kitterman wrote: > >> It's a redefinition of the current meaning of the From: field, and the > >> addition of another header to take the place of the existing From: field. > >> That's bigger than DMARC, and it seems like the 5322 people should be > >> involved in that discussion. > > > > Rewriting From or adding the new List-foo redefines it? > > Yes. > > From 5322: > > The "From:" field specifies the author(s) of the message, > that is, the mailbox(es) of the person(s) or system(s) responsible > for the writing of the message. The "Sender:" field specifies the > mailbox of the agent responsible for the actual transmission of the > message." > > The proposal here is to use the From: field to specify the mailbox > of the agent responsible for the actual transmission of the message > (the mailing list manager); the value that 5322 specifies as the Sender. > That's a significant change to 5322. > > Also, to add a new field that will contain the mailbox of the person > responsible for writing the message; what 5322 defines as the From: > field. While adding a new header is fine, adding one that is defined to > contain the value that 5322 says is the value of the From: header is > stepping on some toes. > > It's a significant change to RFC 5322, so any discussion of it > needs to take that into account (perhaps by having the appropriate > IETF WG involved in the discussion earlier rather than later). OK. What WG? With respect to rewriting from, I think the horse has already left the barn. People can not like it all they want, I don't see it stopping any more than I see basic DMARC design changing to not break non-DKIM preserving mailing lists. Would it make sense to discuss a draft here and then once it's beat into shape a bit send it $PLACES for appropriate review? Scott K From nobody Sun Sep 14 01:25:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E21A02DB for ; Sun, 14 Sep 2014 01:25:41 -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 sREA55iC7Q0J for ; Sun, 14 Sep 2014 01:25: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 02A741A02DA for ; Sun, 14 Sep 2014 01:25:39 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 622941C38D5; Sun, 14 Sep 2014 17:25:38 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 540A21A28C8; Sun, 14 Sep 2014 17:25:38 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <1649333.nlP8KdUCtY@scott-latitude-e6320> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <3999457.XoR0KUjBNM@scott-latitude-e6320> <5414B11D.6080203@dcrocker.net> <1649333.nlP8KdUCtY@scott-latitude-e6320> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 14 Sep 2014 17:25:38 +0900 Message-ID: <87ppey4ni5.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vk4jN8aEkKZzicCQYyIKtLaK86Q Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 08:25:41 -0000 Scott Kitterman writes: > > Actually, it does. Reply-to does not make assertions of > > authorship. The type of change being contemplated does. > > How much difference does that make to end users? I mash a button > than get a message going back to an address. They both could do > that. That's the intended use. The problem is that any "Really-Truly-From" field is likely to be used by MUAs as a From substitute. That is, instead of using the GNU Mailman logo as an "avatar" in the GUI when presenting a post on the "Mailman Developers" list, it will grab "stephen@xemacs.org" out of the "Really-Truly-From" field, and present *my* avatar to the user. Who will then believe that I sent them the link to the phishing site, click on it, and provide their credit card credentials. (And if you have a convincing argument that nobody would be that stupid, please tell the AOL and Yahoo! PHBs so that they'll stop their p=reject folly, and the Bad Guys, so they'll stop hammering AOL and Yahoo! MXes.) Really, the only general solution is author-signed mail. For mailing lists and the like, the MUA can help (for pholks who actually use their domain's web MUA). I would guess that for "on behalf of", domains would need to provide an OAuth solution or, for trusted ESPs, third party authorization. (But I hasten to add that TPA is hardly a generic solution. The logistics of authorization are prohibitive.) Regards, From nobody Sun Sep 14 01:45:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510AD1A0071 for ; Sun, 14 Sep 2014 01:45:56 -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 eJ1TEjcligeW for ; Sun, 14 Sep 2014 01:45:54 -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 D1EFF1A02F1 for ; Sun, 14 Sep 2014 01:45:52 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 525941C38FC; Sun, 14 Sep 2014 17:45:52 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3C7261A28C8; Sun, 14 Sep 2014 17:45:52 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <3657835.KmjXCTr7Sk@scott-latitude-e6320> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 14 Sep 2014 17:45:52 +0900 Message-ID: <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CionZ0Cp1eKWyYEcrgQJcBf3DUc Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 08:45:56 -0000 Scott Kitterman writes: > With respect to rewriting from, I think the horse has already left > the barn. True. The parts of RFC 5322 describing the Reply-To field are quite analogous, though. Reply-To munging by misguided mailing lists has been happening since RFC 733 was current as far as I can tell, but the obsoleting RFCs have consistently refused to sanction it. I suppose that From munging will get the same treatment, for the same reasons. > People can not like it all they want, I don't see it stopping any > more than I see basic DMARC design changing to not break non-DKIM > preserving mailing lists. Sure, but Steve is quite right. The From field is the RFC-defined way to indicate the author of a message. That is its *precise* semantics, no more and no less. Any proposed standard that presumes otherwise (including that the From field might not contain the author) is going to need to revise the definition of the From field, as well as propose the alternative field for "really truly from". From nobody Sun Sep 14 06:54:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349D11A0393 for ; Sun, 14 Sep 2014 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLo_1wQHWOSp for ; Sun, 14 Sep 2014 06:54:24 -0700 (PDT) Received: from dkim.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 644F41A038F for ; Sun, 14 Sep 2014 06:54:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1731; t=1410702853; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=Fb1leZW nDoje7Nsfki8YsTGPqkE=; b=MCDDeCXNqr/UqKhF1SyTWFlVmtXG5ekHcWHn3B0 RwEegT2qSfTYxGbyfecZv6Hqkcvmms/1w1M/NObzqNwvCPMVLCEO1EYtB5evzRwb Jsf9w8d50OcvNbxkHLP6v8CPNcSC1+SR9byD8EUCbytEGyp+EsPZMv8pMv7UP1GO I6is= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 14 Sep 2014 09:54:13 -0400 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 1592946866.1.3748; Sun, 14 Sep 2014 09:54:12 -0400 References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> Mime-Version: 1.0 (1.0) In-Reply-To: <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <67449E96-5BDD-4BCA-BD35-A49C2BEC3770@isdg.net> X-Mailer: iPad Mail (11D257) From: Hector Santos Date: Sun, 14 Sep 2014 09:54:09 -0400 To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5LAU0XbHfxxfWUgm-X17QkUcG0s Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 13:54:27 -0000 > On Sep 14, 2014, at 4:45 AM, "Stephen J. Turnbull" wr= ote: >=20 > Scott Kitterman writes: >=20 >> With respect to rewriting from, I think the horse has already left >> the barn. >=20 > True. The parts of RFC 5322 describing the Reply-To field are quite > analogous, though. Reply-To munging by misguided mailing lists has > been happening since RFC 733 was current as far as I can tell, but the > obsoleting RFCs have consistently refused to sanction it. >=20 > I suppose that =46rom munging will get the same treatment, for the same > reasons. I don't think so. It will be isolated. Don't assume all systems are going to= honor it. They won't. It's a hack, a kludge and it's irresponsibly ugly. = However, it will be exploited by the bad guys to send "on behalf" phishing D= KIM exploits and that is when you will see filters to trap for these exploit= s. =20 At the end of the day, all the restrictive domains usages will be pruned out= , filtered away. Just like all our restrictive domains, like yahoo.com users= subscribed to our support lists have shown. This will most likely occur at= the vast amount of smaller systems which is by far the majority as a total= group. But the same effect will occur at the more isolated larger site too.= =20 By the time the WG will figure out any complex solution to get around this,= I suspect the depleting targets user base will have moved on. Why would yo= u keep using a domain that you can no longer use in public like in the past?= A user might use it at a site because it is rewriting but he won't be able= to use it at other sites and in not in general. =20 -- Hector Santos http://www.santronics.com= From nobody Sun Sep 14 07:54:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37A41A03EC for ; Sun, 14 Sep 2014 07:54: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 iZGcw36F6MSc for ; Sun, 14 Sep 2014 07:54:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855A41A03DB for ; Sun, 14 Sep 2014 07:54:03 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 64182D044F4; Sun, 14 Sep 2014 10:54:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410706442; bh=gF98D2y246/PUzMe7BqwvXwGRcyes+efnU0arA2Njiw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=10AN0IW8FUPXt8ijso6gjvhP1KMp4M/okOWiMPkrGHfu6gs8VO1DVxw6ITailOGqY BnahSyLS6rkPrH/2gYWZTITlCXeAZOR4tpNy/8qj+xtOcrlFFyn30gfZX/k3dty90K csjDMWMgdJtPDQEZFM5gpR7lUTJGikaj3a6zlt2o= Received: from [IPV6:2600:1003:b12c:eb76:a87a:dfe6:3aae:6730] (unknown [IPv6:2600:1003:b12c:eb76:a87a:dfe6:3aae:6730]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E7ECBD0417A; Sun, 14 Sep 2014 10:54:01 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sun, 14 Sep 2014 10:53:57 -0400 To: dmarc@ietf.org Message-ID: <5dab12b5-ad9a-4f1f-8908-b53509e1583d@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rNuJwXp4OTEndT2kvix2_u_JbJE Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 14:54:05 -0000 On September 14, 2014 4:45:52 AM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > With respect to rewriting from, I think the horse has already left > > the barn. > >True. The parts of RFC 5322 describing the Reply-To field are quite >analogous, though. Reply-To munging by misguided mailing lists has >been happening since RFC 733 was current as far as I can tell, but the >obsoleting RFCs have consistently refused to sanction it. > >I suppose that From munging will get the same treatment, for the same >reasons. > > > People can not like it all they want, I don't see it stopping any > > more than I see basic DMARC design changing to not break non-DKIM > > preserving mailing lists. > >Sure, but Steve is quite right. The From field is the RFC-defined way >to indicate the author of a message. That is its *precise* semantics, >no more and no less. Any proposed standard that presumes otherwise >(including that the From field might not contain the author) is going >to need to revise the definition of the From field, as well as propose >the alternative field for "really truly from". And by the time that's done, how many non-standard variants will be in use and "too hard to change"? Whatever IETF documents say, it's already been redefined in the world of running code. I'd propose something along the lines of "we don't endorse From rewriting by mailing lists, but if you're going to do it anyway, do it this way". Then this can be decoupled from the larger semantic issue since we know there's a loss of information problem to be solved regardless of anyone's opinion about From rewriting. Scott K From nobody Sun Sep 14 09:20:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D81A009C for ; Sun, 14 Sep 2014 09:20:16 -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 7QSseBRB3LMw for ; Sun, 14 Sep 2014 09:20:14 -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 B8F151A0099 for ; Sun, 14 Sep 2014 09:20:14 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9C72A1C393D; Mon, 15 Sep 2014 01:20:13 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8FB421A28C8; Mon, 15 Sep 2014 01:20:13 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <5dab12b5-ad9a-4f1f-8908-b53509e1583d@email.android.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> <5dab12b5-ad9a-4f1f-8908-b53509e1583d@email.android.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 15 Sep 2014 01:20:13 +0900 Message-ID: <8761gq41j6.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HjU_SgoeVHSFH5msgl3ac3ciq3U Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 16:20:17 -0000 Scott Kitterman writes: > And by the time that's done, how many non-standard variants will be > in use and "too hard to change"? Why should anyone care? That's an honest question, because I think the chances are quite good that Hector is right. Yahoo! and AOL have demonstrated that they care less about reliable delivery than other providers do, and they will lose mailbox users because of that, and the rate of loss will increase over time as people make other arrangements or store up annoyance. It won't kill either of them, but it will hurt, and they will find ways to do without p=reject. Is it really worth trying to patch up the nonconforming implementations if the need will automatically go away? (At least for GNU Mailman, where no p=reject => no From munging and no message wrapping). > Whatever IETF documents say, it's already been redefined in the > world of running code. My point is that so has Reply-To, and the IETF has *pointedly* ignored that fact for decades. > I'd propose something along the lines of "we don't endorse From > rewriting by mailing lists, This WG is not just about mailing lists. Have you thought about other indirect mail use cases? > but if you're going to do it anyway, do it this way". Then this > can be decoupled from the larger semantic issue since we know > there's a loss of information problem to be solved regardless of > anyone's opinion about From rewriting. Good luck, because I expect the IETF to prefer pointedly ignoring nonconforming implementations in its documents, or perhaps outright condemnation, to anything like what you're proposing. Regards, Steve From nobody Sun Sep 14 11:49:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107681A0180 for ; Sun, 14 Sep 2014 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, 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 SIeaZm5oLqW1 for ; Sun, 14 Sep 2014 11:49:38 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD56B1A017E for ; Sun, 14 Sep 2014 11:49:36 -0700 (PDT) Received: from horde.andreasschulze.de (horde.andreasschulze.de [IPv6:2001:a60:f0b4:e503:e49d:e7ff:fea2:4010]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3hx09n3sDhzDcn for ; Sun, 14 Sep 2014 20:49:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1410720573; bh=cP0eLegtopcvd3o0CKz4LRRAUjoCTgbEh2um6tr/wuE=; h=Date:From:To:Subject:References:In-Reply-To; b=IV6ReEsMGWc+zN0Ez4+pbRcdqkZx41GmNKCEDM/hXTWocnoivEIBihYYfFnbX6fXD SHGswSMmS5lANEsv63/ZqDwhNE7H4R2K97qsQLNUgL03I6FwtgRfs7i4rf7vXH7FL3 jodWA/iJsE6etfDUd+vZA9uIl5nMmPBnte/ij0GPNC9+F6wMgATpv5svFMgJ1oEElI UTVizTmz7grOXKueutwTD9uB3FHUhV7dhGrZXnE7Vh385A3K/w8ltTP8okEe+Ae7ys hn/StvZjV1n8gvJOJVBNZ8uHzqO+JX2Jqgnq3KB0ODOTs9Ndq/wu2csl5C8dql+vvH mZUgO9xmgqM/TiRKOvyA595ZNBVf0iJa4jBaPgm+5DoDZZfjrl0XDCcuWSmYfQZ6FU Em5bTSzaF5ci+oAwOwx6iZ0BgGBWG1pa/q96zq7my+bYQVb/mzdTXY+6TFx2vLCmOQ FLrOZzpuk4i1wY5ywrWdLIIVgyCMdZiFGoc1iDIECW2ioyHVTs1p4y/w/B16OtFWbw Dxmd3KPOwOXhlmXARSgLwSATIlkijRwtxxwDMEDzT/RUJ0lM5Qq2nlzERSOkwmy5QZ gE/KBjava5bwBFaVyohHPLr7MlWw9kvuDamWIHQBBs4dkiy5DrsnHxE7XIBId1//D+ 4yUEAwsXU9MpZy11F9bvhPlc= Received: from solar.andreasschulze.de (solar.andreasschulze.de [2001:a60:f0b4:e502::51]) by horde.andreasschulze.de (Horde Framework) with HTTP; Sun, 14 Sep 2014 20:49:31 +0200 Date: Sun, 14 Sep 2014 20:49:31 +0200 Message-ID: <20140914204931.Horde.a971R3BTpmKbD3-RvKzLUw4@horde.andreasschulze.de> From: "A. Schulze" To: dmarc@ietf.org References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <54147C54.3020604@dcrocker.net> <3999457.XoR0KUjBNM@scott-latitude-e6320> <5414B11D.6080203@dcrocker.net> In-Reply-To: <5414B11D.6080203@dcrocker.net> User-Agent: Internet Messaging Program (IMP) H5 (6.2.2) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rxl-kcp0iIlr9A4aN_Kdu4eG95E Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 18:49:40 -0000 Dave Crocker: > I should also note that as soon as we go down this path of design > thinking (independent of which might be preferred) we should carefully > consider costs of making changes. > > For example, changing all the MUAs in the world, versus changing all the > mailing list software... good point. currently it looks to me like list managers are the biggest point of pain. The list managers policy (adding subject tag + footer) stay against the DKIM signature to prove the owner ship. The current solution to mitigate DMARC damage is to takeover the ownership by rewriting RFC822.From What about simply honer the senders policy and avoid message changes? No need to change any trillions of MUA in the univers but only 100k list managers. Andreas From nobody Sun Sep 14 12:34:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4CF1A01A9 for ; Sun, 14 Sep 2014 12:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpkN7StSGph7 for ; Sun, 14 Sep 2014 12:34:16 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFAB1A01A5 for ; Sun, 14 Sep 2014 12:34:16 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 3732A95600F; Sun, 14 Sep 2014 15:34:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410723255; bh=XMxjky1riYnJyUvuGZ4kvsuT6irRJ548GpisL30nJqM=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ZkTV0hWmFbu55uU2SB4wPVWmLtWHPDHbXxyfep0VsW6Mp323wv/v3QKu44HdcliPE xwMKylCiv0mjM5P7pvOYCSJzMxjMny318D6l2eWUZOHu9kfyGWfj/fSg+iSyJM0g1f WgzsLjJ7lIMZIPYM4pW9GPdB7oZaZgggPM5c4Isw= Received: from [IPV6:2600:1003:b100:8ccd:5cc7:2067:f2a8:6b3d] (unknown [IPv6:2600:1003:b100:8ccd:5cc7:2067:f2a8:6b3d]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8788BD041F5; Sun, 14 Sep 2014 15:34:14 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <8761gq41j6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> <5dab12b5-ad9a-4f1f-8908-b53509e1583d@email.android.com> <8761gq41j6.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sun, 14 Sep 2014 15:34:11 -0400 To: dmarc@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Fv2W2erYEy26enFHlZHahC2pdWg Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 19:34:21 -0000 On September 14, 2014 12:20:13 PM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > And by the time that's done, how many non-standard variants will be > > in use and "too hard to change"? > >Why should anyone care? That's an honest question, because I think >the chances are quite good that Hector is right. Yahoo! and AOL have >demonstrated that they care less about reliable delivery than other >providers do, and they will lose mailbox users because of that, and >the rate of loss will increase over time as people make other >arrangements or store up annoyance. It won't kill either of them, but >it will hurt, and they will find ways to do without p=reject. Is it >really worth trying to patch up the nonconforming implementations if >the need will automatically go away? (At least for GNU Mailman, where >no p=reject => no From munging and no message wrapping). > > > Whatever IETF documents say, it's already been redefined in the > > world of running code. > >My point is that so has Reply-To, and the IETF has *pointedly* ignored >that fact for decades. > > > I'd propose something along the lines of "we don't endorse From > > rewriting by mailing lists, > >This WG is not just about mailing lists. Have you thought about other >indirect mail use cases? > > > but if you're going to do it anyway, do it this way". Then this > > can be decoupled from the larger semantic issue since we know > > there's a loss of information problem to be solved regardless of > > anyone's opinion about From rewriting. > >Good luck, because I expect the IETF to prefer pointedly ignoring >nonconforming implementations in its documents, or perhaps outright >condemnation, to anything like what you're proposing. Witness the excellent success of the head in the sand approach to stopping use of NAT. People are already routing around the damage. The mailing list issue is particularly problematic because it's affecting users of domains that don't have reject policies. Google didn't invest the engineering resources in selective From rewriting for Google Groups to solve a non-problem. I can (an plan to) write code that leverages their X-Original-To. I'd rather have something standardized, but it's not essential for me to solve the problem I'm having. For the broader internet, I'm not so sure. Scott K From nobody Sun Sep 14 14:46:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D48F1A02E5 for ; Sun, 14 Sep 2014 14:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-1.652, 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 T6zLfqE7Awyw for ; Sun, 14 Sep 2014 14:46:31 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 065341A0140 for ; Sun, 14 Sep 2014 14:46:30 -0700 (PDT) Received: from [10.0.1.15] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 3B3DECB52 for ; Sun, 14 Sep 2014 17:46:31 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 14 Sep 2014 17:46:28 -0400 To: "dmarc@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/t3O-tHOQIJp0340K5tJ-WOku6nw Subject: [dmarc-ietf] Milestone 1 wiki updated X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Sep 2014 21:46:32 -0000 I've gone through and updated the Wiki to fold in items that the list = has discussed: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Please continue to flesh out the existing items and to raise additional = items. The devil is in the details. Thanks to Stephen J. Turnbull for taking the first cut at the Wiki. The = volunteer editors should be stepping in to fold in additional feedback = as it develops. =3D- Tim From nobody Sun Sep 14 17:53:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB771A045E for ; Sun, 14 Sep 2014 17:53:40 -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 0D6Ph6xYZGth for ; Sun, 14 Sep 2014 17:53:38 -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 A92B31A045B for ; Sun, 14 Sep 2014 17:53:38 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6DC231C3979; Mon, 15 Sep 2014 09:53:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5C7651A28C8; Mon, 15 Sep 2014 09:53:37 +0900 (JST) From: "Stephen J. Turnbull" To: "A. Schulze" In-Reply-To: <20140914204931.Horde.a971R3BTpmKbD3-RvKzLUw4@horde.andreasschulze.de> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <54147C54.3020604@dcrocker.net> <3999457.XoR0KUjBNM@scott-latitude-e6320> <5414B11D.6080203@dcrocker.net> <20140914204931.Horde.a971R3BTpmKbD3-RvKzLUw4@horde.andreasschulze.de> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 15 Sep 2014 09:53:37 +0900 Message-ID: <871trd4sby.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vFeYATV5pIE0jM2eJrC5L6utx-4 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 00:53:40 -0000 A. Schulze writes: > What about simply honer the senders policy and avoid message changes? What about it? That suggestion was first made years ago and rejected by the users, even after the April Fools DMARC debacle. History from my point of view: Mailman devs tried for months to come up with a way to avoid implementing From munging, but like Reply munging, list admins insist on this because users like some of the message-modifying features (subject tags and serial numbers, access to settings page in the footer) and others are more or less legally required for some lists in some jurisdictions (visible simple way to unsubscribe). Note that removing subject tags may be an imposition on hundreds of millions of users, who don't know any other way to filter on mailing list (even if those other ways are obvious to us). Regards, From nobody Mon Sep 15 11:23:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E861A6EF1 for ; Mon, 15 Sep 2014 11:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 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, 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 7VNbO-Mw8OQM for ; Mon, 15 Sep 2014 11:23:25 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA43E1A03C1 for ; Mon, 15 Sep 2014 10:39:53 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id tp5so4830779ieb.23 for ; Mon, 15 Sep 2014 10:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=g5ok4ustEKNCIOqJaUXbhGrpT+eTkmCLHZukvG/XvOs=; b=czgi9Aj9AiRyK1TBNrTmUVs1LNoPT4qDj6YWW5gMERXq10wmgdbCynaDBCLac0MDh6 tG2E+ypMt5ntSeGdZI1RAkjWwQaRFi5/dSLQSMOWIZw4xYbGwsuQe70R+KkCf9y9zgMS BCWBZxr9nsS7zOOFHeCYtpqpPbOGFcWqa83GygleAwDzt1k3Sr5gdhVNiBgOHqgx5SFa VAhv8q+jakHs25biu4qlrhqihBASkvO2VaRROb9hATETNRRZ+vXPO5NxsnYaBpZaqpNb S4VKNudl/Xf1/MuDAwRPpj4XMOraPqZyhg3eKOkNjne5cHFgcgaYPjTWFvIEPVnC1T7v HgXQ== MIME-Version: 1.0 X-Received: by 10.50.82.98 with SMTP id h2mr23759031igy.26.1410802793216; Mon, 15 Sep 2014 10:39:53 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Mon, 15 Sep 2014 10:39:53 -0700 (PDT) Date: Mon, 15 Sep 2014 19:39:53 +0200 Message-ID: From: Henrik Schack To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=089e0111b2c65681c305031e1f0b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KrejRoQy2KH3phqR8ZNM7RLrpzE Subject: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrik@schack.dk List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 18:23:30 -0000 --089e0111b2c65681c305031e1f0b Content-Type: text/plain; charset=UTF-8 In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider breaking DKIM signatures. They break DKIM signatures on incoming email by adding a "Virus scanned by xxxx" line to the body of the email. Not sure how to fix this, but perhaps some day they'll get tired of my bi-monthly calls and emails complaining about how they do things. -- Mvh/Best regards Henrik Schack http://henrik.schack.dk/ --089e0111b2c65681c305031e1f0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In Denmark we have a somewhat large (10K+ domains) anti-vi= rus/spam provider breaking DKIM signatures.
They break DKIM signatures = on incoming email by adding a "Virus scanned by xxxx" line to the= body of the email.

Not sure how to fix this, but = perhaps some day they'll get tired of my bi-monthly calls and emails co= mplaining about how they do things.
=C2=A0
=
--
Mvh/Best regards
Henrik Schack
--089e0111b2c65681c305031e1f0b-- From nobody Mon Sep 15 11:51:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF21A7007 for ; Mon, 15 Sep 2014 11:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 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, HTML_MESSAGE=0.001, 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 X32gqic3zOvE for ; Mon, 15 Sep 2014 11:51:50 -0700 (PDT) Received: from ironport.turtlesys.net (ironport.yipnet.com [207.135.97.20]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715241A87C0 for ; Mon, 15 Sep 2014 11:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomki.com; i=@tomki.com; l=3172; q=dns/txt; s=tomki; t=1410806228; x=1410979028; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; z=Message-ID:=20<541731D2.4070105@tomki.com>|Date:=20Mon, =2015=20Sep=202014=2011:37:06=20-0700|From:=20Tomki=20|Reply-To:=20dmarcietf@tomki.com |MIME-Version:=201.0|To:=20dmarc@ietf.org|Subject:=20Re: =20[dmarc-ietf]=20Indirect=20mail=20flows:=20DKIM=20signa ture=20breakage=20by=0D=0A=20cloud=20anti-virus/spam=20pr ovider|References:=20|In-Reply-To:=20; bh=Nzg8V9hN34+DM97nJTZX+nalDiynTEXDYD4233I6Wuw=; b=F4eUHg+c/O5y4GPi213U9MrfIewFW6tB1oLB0UzM+laOE9JcELuMl7nb DLg0Jf1IT7PNCY+gsBWwZMzdlp/QNNV8YRfzO0NYp6X6tykft1ZE5TRRQ 0+solq84FzdNGEOP8Kkor0a3r1zwLl5INQ8+LMDv5LMzkvyw+olghiY8l FJRi2aZSge+1yXSOJWXM4WDZ0W/dEK81vQurdxlyBvAOpEOZzaUSLadLs QVy7ZduBmdf/LW4/E91uW0A+99dgxevMasbPFbHTnBWleBICothbf9M47 yozM8RtbEmV/aYDpnEaedVYpP5zhO8jWFj021ZzweTsaXDHYOUeLEoSnf Q==; X-Filenames: X-SBRS: None X-recvListener: Inbound X-sendergroup: RELAYLIST X-remote-hostname: www01.turtlesys.net X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=zVbkqPPf3+r+0ypC1AvITBZKOYaiVOyTo2cssal+I1k= c=1 sm=2 a=snOOj206kjsA:10 a=OkNzzoTPFCwA:10 a=iqr1BhXdXEcA:10 a=ciTX9W7zoa0A:10 a=PaXCPaBKbXIA:10 a=S80ENf0cAAAA:8 a=48vgC7mUAAAA:8 a=v0oDQLaD8oTsdl1ahUEA:9 a=pILNOxqGKmIA:10 a=lZB815dzVvQA:10 a=pGLkceISAAAA:8 a=wbrsiorgPGxLOHonCQQA:9 a=_W_S_7VecoQA:10 X-IronPort-AV: E=McAfee;i="5600,1067,7562"; a="6119107" X-IronPort-AV: E=Sophos;i="5.04,409,1406617200"; d="scan'208,217";a="6119107" Received: from www01.turtlesys.net ([207.135.97.24]) by ironport.turtlesys.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2014 11:37:08 -0700 Received: from 50-197-151-169-static.hfc.comcastbusiness.net ([50.197.151.169]:60452 helo=silverado.local) by www01.turtlesys.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTb99-0007ee-40 for dmarc@ietf.org; Mon, 15 Sep 2014 11:37:07 -0700 Message-ID: <541731D2.4070105@tomki.com> Date: Mon, 15 Sep 2014 11:37:06 -0700 From: Tomki User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060506020302040408070902" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - www01.turtlesys.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tomki.com X-Get-Message-Sender-Via: www01.turtlesys.net: authenticated_id: tki@tomki.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CQ1rIQJtQiBQeuxQKgD7RLtBCsg Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dmarcietf@tomki.com List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 18:51:51 -0000 This is a multi-part message in MIME format. --------------060506020302040408070902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Henrik, I think that the fact of virus scanning is more commonly just another header in the message, which would not break a properly created DKIM-Signature. For example your message (via the list) got to me with extra headers such as: X-IronPort-AV, X-IronPort-AS Perhaps that example from another major scanning system would help. --Tomki On 9/15/14 10:39, Henrik Schack wrote: > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam > provider breaking DKIM signatures. > They break DKIM signatures on incoming email by adding a "Virus > scanned by xxxx" line to the body of the email. > > Not sure how to fix this, but perhaps some day they'll get tired of my > bi-monthly calls and emails complaining about how they do things. > > > -- > Mvh/Best regards > Henrik Schack > http://henrik.schack.dk/ > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------060506020302040408070902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Henrik,
I think that the fact of virus scanning is more commonly just another header in the message, which would not break a properly created DKIM-Signature.
For example your message (via the list) got to me with extra headers such as: X-IronPort-AV, X-IronPort-AS

Perhaps that example from another major scanning system would help.

--Tomki



On 9/15/14 10:39, Henrik Schack wrote:
In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider breaking DKIM signatures.
They break DKIM signatures on incoming email by adding a "Virus scanned by xxxx" line to the body of the email.

Not sure how to fix this, but perhaps some day they'll get tired of my bi-monthly calls and emails complaining about how they do things.
 

--
Mvh/Best regards
Henrik Schack


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

--------------060506020302040408070902-- From nobody Mon Sep 15 12:10:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C141A6F52 for ; Mon, 15 Sep 2014 12:10:00 -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 A1SPQWuS9HI1 for ; Mon, 15 Sep 2014 12:09:56 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051481A870D for ; Mon, 15 Sep 2014 12:00:33 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rl12so5267604iec.28 for ; Mon, 15 Sep 2014 12:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+F4TY70EsPGmwOjQyhwTmc8W7RN/MG9Iuz+/XWOx+ow=; b=zRkmH7En/QQD+4DW15xANuisw2qCZde+wYUl1NckPRZhuZvvS4Uee1JK4MHVFtqyGt PchEimJ+3PgWSeXNorLdWQL6KVyyhm3xIIqGk0Ow80Z1sa4n2V9+rz7imWoX8WBoTHRS Ccb1kzCLGqAFEzlBEo6xvEnC5s5Hkx/Sgj5VHNcsu7B8PZY+VSV+AZ4zRdIMoq5H+Z2+ jCm2B8IcKR2Pszl3nbnBT+U102HNi8Del27I9WRF9ynLUQDyybN/iYH/7YyfqcxoFwYc YONeYLP+LFeqKCMxJxe1ILPjYUM2lS4E3N+n+VSgSTtsZ8viO74EDh9QJJWKKoQhenqU mZeg== MIME-Version: 1.0 X-Received: by 10.42.114.130 with SMTP id g2mr26937802icq.46.1410807633352; Mon, 15 Sep 2014 12:00:33 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Mon, 15 Sep 2014 12:00:33 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Mon, 15 Sep 2014 12:00:33 -0700 (PDT) In-Reply-To: <541731D2.4070105@tomki.com> References: <541731D2.4070105@tomki.com> Date: Mon, 15 Sep 2014 21:00:33 +0200 Message-ID: From: Henrik Schack To: dmarcietf@tomki.com Content-Type: multipart/alternative; boundary=20cf303bf576d5202d05031f3fce Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Oq8yTSt9ab8qhbbMIoIWfy8tgrg Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrik@schack.dk List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:10:00 -0000 --20cf303bf576d5202d05031f3fce Content-Type: text/plain; charset=UTF-8 In this case it's not a header, but a line added to the body of the email Br Henrik Schack On Sep 15, 2014 8:51 PM, "Tomki" wrote: > Henrik, > I think that the fact of virus scanning is more commonly just another > header in the message, which would not break a properly created > DKIM-Signature. > For example your message (via the list) got to me with extra headers such > as: X-IronPort-AV, X-IronPort-AS > > Perhaps that example from another major scanning system would help. > > --Tomki > > > > On 9/15/14 10:39, Henrik Schack wrote: > > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam > provider breaking DKIM signatures. > They break DKIM signatures on incoming email by adding a "Virus scanned by > xxxx" line to the body of the email. > > Not sure how to fix this, but perhaps some day they'll get tired of my > bi-monthly calls and emails complaining about how they do things. > > > -- > Mvh/Best regards > Henrik Schack > http://henrik.schack.dk/ > > > > _______________________________________________ > dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --20cf303bf576d5202d05031f3fce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In this case it's not a header, but a line added to the = body of the email
Br Henrik Schack

On Sep 15, 2014 8:51 PM, "Tomki" <<= a href=3D"mailto:dmarcietf@tomki.com">dmarcietf@tomki.com> wrote:
=20 =20 =20
Henrik,
I think that the fact of virus scanning is more commonly just another header in the message, which would not break a properly created DKIM-Signature.
For example your message (via the list) got to me with extra headers such as: X-IronPort-AV, X-IronPort-AS

Perhaps that example from another major scanning system would help.

--Tomki



On 9/15/14 10:39, Henrik Schack wrote:
In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider breaking DKIM signatures.
They break DKIM signatures on incoming email by adding a "Virus scanned by xxxx" line to the body of the email.<= /div>

Not sure how to fix this, but perhaps some day they'll get tired of my bi-monthly calls and emails complaining about how they do things.
=C2=A0

--
Mvh/Best regards
Henrik Schack


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


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

--20cf303bf576d5202d05031f3fce-- From nobody Mon Sep 15 12:29:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ADA1A6F41 for ; Mon, 15 Sep 2014 12:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 C5Xqg_tTy2DW for ; Mon, 15 Sep 2014 12:28:56 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45631A0026 for ; Mon, 15 Sep 2014 12:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1410809336; x=1442345336; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/SnhH4hd7Neori01OwAoIYoU7q6IK6sxum1Uw/eovHI=; b=X/DJhb3pgolfiPcORrtTjrKNZ/LYvFXULIJSW8NPypSBuLzE5vz0AxI6 FUhBCBnWUKeeCp66Ocr4L9RjBOWlC0S5zp3scaDJFz3BneJ03YOujPf81 zuOhNjTZ/OxqF05dy5Go48jQWmgjnroJB/6WgfE67FN9/5zz/fducEusV Y=; X-IronPort-AV: E=Sophos;i="5.04,529,1406617200"; d="asc'?scan'208";a="141125332" Received: from ESV4-MB03.linkedin.biz ([fe80::1caa:1422:7ef8:5ceb]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Mon, 15 Sep 2014 12:28:55 -0700 From: Franck Martin To: "henrik@schack.dk" Thread-Topic: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider Thread-Index: AQHP0RIuLjBMHcsDRkWQSV5A3T7WVpwDCNmA Date: Mon, 15 Sep 2014 19:28:53 +0000 Message-ID: <54F9700F-E895-4913-BB2B-1B601909C897@linkedin.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: multipart/signed; boundary="Apple-Mail=_5C907E7F-FC68-43FD-90B4-6E9C0AD514DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WgyD2d5Nc0LE2reAJcwZNHVO7f0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:28:58 -0000 --Apple-Mail=_5C907E7F-FC68-43FD-90B4-6E9C0AD514DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 15, 2014, at 7:39 PM, Henrik Schack = wrote: > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam = provider breaking DKIM signatures. > They break DKIM signatures on incoming email by adding a "Virus = scanned by xxxx" line to the body of the email. >=20 > Not sure how to fix this, but perhaps some day they'll get tired of my = bi-monthly calls and emails complaining about how they do things. > =20 Is this a free service that they have to advertise themselves in the = body of the email? If you pay for the service, may be you don=92t want = to get any advertisement? --Apple-Mail=_5C907E7F-FC68-43FD-90B4-6E9C0AD514DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUFz0wAAoJEJHd9Bbysc+ajfEH/3/v48tMC7Ua7FDEenx8GsnG XLl9zYV9QCGDczFtg10i+IcdS7OoQvkyTFU7+b3Ska4AoZehD7+eMMlG6VNuoc7J ipjT/Gnth513qY2OVjP5GdjYL6JnE7msHjFpngGVC8GB2qfxvJq2Zf7+qhWLBhFQ EF9Tgrb83DAXSy73Nzf7Wl90SAw3/ZMjSBb6ausf9A1yO5QLyXoGPbsBeFLGwQTZ izdozgFSvMYPBYpUQra8JcldR+85dl7rVdc70F/WmyhMh8UWq5NM38LIUxon5NQk f/j+wYCtFZ5ilbEG9yFyPeCRvJs7IiD35rxGWD8GTtKd7RjRk33HDVYxxEDF3I0= =nli8 -----END PGP SIGNATURE----- --Apple-Mail=_5C907E7F-FC68-43FD-90B4-6E9C0AD514DA-- From nobody Mon Sep 15 12:31:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622B91A6F61 for ; Mon, 15 Sep 2014 12:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM9kkJbPhlq1 for ; Mon, 15 Sep 2014 12:31:32 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E641A6F5D for ; Mon, 15 Sep 2014 12:31:32 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tr6so5270802ieb.17 for ; Mon, 15 Sep 2014 12:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=x+Qq+yz5uxMzDavCgqaQ6yVgrMrzG8kRAKgGNX0Gq58=; b=PlJN4yjuVKixcosvNWTPrPWXPHJPCTzdFcn1ETUKcZThdRrcMsuPpTKseXn4BBps4z 7YsQM4YUNAGaPm41x46LZTN0LBEeENM1ztD3e4guBsXeMRa6Za/HAILaiY8CdzhKwtwW LOypib2uJVnrPj9CtwOEVcJN7EtYfTsr8e96n30R/+C2iOARiFOVNtUw0RU8e5w+bj75 2E5DPWDlSGVL1JpYtUSuzo5tvA+REpkHIiqiXUmch2Wy2eWecbjlV77hoXARr4/U5nex qH/bbCuClu5bAJzCryjInmNHc0+l62ET7DR0ez1+ZQZ5Fw2aPdJl3E3PKOGIW56MrGf0 Vy9Q== MIME-Version: 1.0 X-Received: by 10.43.154.145 with SMTP id le17mr4766529icc.71.1410809492086; Mon, 15 Sep 2014 12:31:32 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Mon, 15 Sep 2014 12:31:32 -0700 (PDT) In-Reply-To: <54F9700F-E895-4913-BB2B-1B601909C897@linkedin.com> References: <54F9700F-E895-4913-BB2B-1B601909C897@linkedin.com> Date: Mon, 15 Sep 2014 21:31:32 +0200 Message-ID: From: Henrik Schack To: Franck Martin Content-Type: multipart/alternative; boundary=001a11c30c6e9f70a605031fae5b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8Shbgp8Ixlh4iaBai4cQ_h6jSsE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrik@schack.dk List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:31:34 -0000 --001a11c30c6e9f70a605031fae5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No it's not at all a free service. But they advertise anyway :-( Br Henrik On Mon, Sep 15, 2014 at 9:28 PM, Franck Martin wrote= : > > On Sep 15, 2014, at 7:39 PM, Henrik Schack > wrote: > > > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam > provider breaking DKIM signatures. > > They break DKIM signatures on incoming email by adding a "Virus scanned > by xxxx" line to the body of the email. > > > > Not sure how to fix this, but perhaps some day they'll get tired of my > bi-monthly calls and emails complaining about how they do things. > > > > > Is this a free service that they have to advertise themselves in the body > of the email? If you pay for the service, may be you don=E2=80=99t want t= o get any > advertisement? > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --=20 Mvh/Best regards Henrik Schack ICQ: 889295 http://henrik.schack.dk/ http://links.schack.dk/ --001a11c30c6e9f70a605031fae5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No it's not at all a free service. But they advertise = anyway :-(
Br
Henrik

On Mon, Sep 15, 2014 at= 9:28 PM, Franck Martin <fmartin@linkedin.com> wrote:
=

On Sep 15, 2014, at 7:39 PM, Henrik Schack <henrik.schack@gmail.com> wrote:

> In Denmark we have a somewhat large (10K+ domains) anti-virus/spam pro= vider breaking DKIM signatures.
> They break DKIM signatures on incoming email by adding a "Virus s= canned by xxxx" line to the body of the email.
>
> Not sure how to fix this, but perhaps some day they'll get tired o= f my bi-monthly calls and emails complaining about how they do things.
>


Is this a free service that they have to advertise themselves in the= body of the email? If you pay for the service, may be you don=E2=80=99t wa= nt to get any advertisement?

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




--
Mvh/Best= regards
Henrik Schack
ICQ: 889295
http://henrik.schack.dk/
h= ttp://links.schack.dk/
--001a11c30c6e9f70a605031fae5b-- From nobody Mon Sep 15 12:38:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49901A6F8F for ; Mon, 15 Sep 2014 12:38:14 -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 Feiat3HPPmIK for ; Mon, 15 Sep 2014 12:38:12 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AB31A1F20 for ; Mon, 15 Sep 2014 12:38:12 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so5313329lab.33 for ; Mon, 15 Sep 2014 12:38: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=MD7bNKqOmJ9+brxwgGN/BweqxoRSFFztRDxo+1Uv94g=; b=WhxhbEgj6vlp7cOjsh4wJc1ESKEiRayESoKIU3dbHaINBY6wktRrFYuwtSP17y5FxT qRk3f/DtwBU7t8LySlpcD3YYMlqDDa61s54qy4VqLhaqM3uzDHNOj111eVVW3sz+Nhdb q+Mnt0RDxfSeyA1fcC2U0aZgOg6z4exizMEZ1DODkjw40W3C65lmRJf5Ls37mZneeWm2 n5kWC54ecDvhqNrW7lQ0HaY4pr/3XNiRxEIQT01tcT0s5akR/4FHoALrWqr33Vjk+Jck DX+39kSu/cUzbx3KP+uVybN0ol/7LaIGUXl+UJaqlafhxa6pqshhkVfSqLjjrlY9xv/U 0YPg== MIME-Version: 1.0 X-Received: by 10.112.198.34 with SMTP id iz2mr5528317lbc.96.1410809889226; Mon, 15 Sep 2014 12:38:09 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 12:38:08 -0700 (PDT) In-Reply-To: References: <54F9700F-E895-4913-BB2B-1B601909C897@linkedin.com> Date: Mon, 15 Sep 2014 12:38:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: henrik@schack.dk Content-Type: multipart/alternative; boundary=001a11c33d704b059c05031fc6c4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7ZG9vXgEQ7FpqH5XkZ1tBrNKlyY Cc: Franck Martin , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:38:14 -0000 --001a11c33d704b059c05031fc6c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Though I would never put such a thing in a standards document, OpenDKIM does have the capability to rewrite arriving header fields prior to signing/verifying to overcome things like this. Your ESP's verifier could be trained to ignore the added line prior to verifying, or better yet, do DKIM verification prior to AV processing. -MSK On Mon, Sep 15, 2014 at 12:31 PM, Henrik Schack wrote: > No it's not at all a free service. But they advertise anyway :-( > Br > Henrik > > On Mon, Sep 15, 2014 at 9:28 PM, Franck Martin > wrote: > >> >> On Sep 15, 2014, at 7:39 PM, Henrik Schack >> wrote: >> >> > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam >> provider breaking DKIM signatures. >> > They break DKIM signatures on incoming email by adding a "Virus scanne= d >> by xxxx" line to the body of the email. >> > >> > Not sure how to fix this, but perhaps some day they'll get tired of my >> bi-monthly calls and emails complaining about how they do things. >> > >> >> >> Is this a free service that they have to advertise themselves in the bod= y >> of the email? If you pay for the service, may be you don=E2=80=99t want = to get any >> advertisement? >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > > -- > Mvh/Best regards > Henrik Schack > ICQ: 889295 > http://henrik.schack.dk/ > http://links.schack.dk/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c33d704b059c05031fc6c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Though I would never put such a thing in a standards = document, OpenDKIM does have the capability to rewrite arriving header fiel= ds prior to signing/verifying to overcome things like this.=C2=A0 Your ESP&= #39;s verifier could be trained to ignore the added line prior to verifying= , or better yet, do DKIM verification prior to AV processing.

= -MSK

On = Mon, Sep 15, 2014 at 12:31 PM, Henrik Schack <henrik.schack@gmail.c= om> wrote:
No it's not at all a free service. But they advertise anyway :-(
Br
Henrik

On Mon, Sep 15, = 2014 at 9:28 PM, Franck Martin <fmartin@linkedin.com> wro= te:

On Sep 15, 2014, at 7:39 PM, Henrik Schack <henrik.schack@gmail.com> wrote:

> In Denmark we have a somewhat large (10K+ domains) anti-virus/spam pro= vider breaking DKIM signatures.
> They break DKIM signatures on incoming email by adding a "Virus s= canned by xxxx" line to the body of the email.
>
> Not sure how to fix this, but perhaps some day they'll get tired o= f my bi-monthly calls and emails complaining about how they do things.
>


Is this a free service that they have to advertise themselves in the= body of the email? If you pay for the service, may be you don=E2=80=99t wa= nt to get any advertisement?

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



<= br>
--
Mvh/Best regards
Henrik Schack
ICQ: 889295
= http://henrik.schack= .dk/
http://li= nks.schack.dk/

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


--001a11c33d704b059c05031fc6c4-- From nobody Mon Sep 15 12:40:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C541A6F99 for ; Mon, 15 Sep 2014 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-1.652, 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 s8ku14O1u-PF for ; Mon, 15 Sep 2014 12:39:59 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E428F1A6F92 for ; Mon, 15 Sep 2014 12:39:53 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id r10so4581799igi.6 for ; Mon, 15 Sep 2014 12:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NW7zmCjB3t2g7nwQitN7WlEUUup04z4mW0GBlTVjGqw=; b=Tuj883713UkNIuPq+DvLUD/YAO5IL5QkQ0EbpBWPRFxQ5Q0EhYhhIcyjuaF+te0iio OfojRfUDPS4QkB122RxFAOsKXEBKTVq2siedkEfa0S1l/dlwp+mcrOg5Ytc9qdDSr3bJ or1tJ0YnYLd7QGb9PMsvwAP5v7VkXZsLAtMjVnfFTNdUkfqm5JcLamMnYyK9Rc4DWeiF PblWUVGnxz/UmbBEZ4k+vJCYVxKJnQ1zECzO74DO5LDroyyM5ZRFIDeLqFysVO+XPSoG EnAnIpcFMPZkW7XokoHPVV3T93vSeoGjESn9TIH/1s6h5nM+FCM0rNkQCf8JyEJEly/v Lvyg== 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=NW7zmCjB3t2g7nwQitN7WlEUUup04z4mW0GBlTVjGqw=; b=UsCFrihxMowEDP1D85SCqOPocn2Uq87NC9wfsrWHZiAwJYGyjCdm94AIKNImgzAYuj dbeLiwH3IkI2YUmJckghDEDgYnHINmjBcVet3H1Svhrt0a4Dz2BoG+CRAk/zejfSZYjJ z3jATP/530ugn866tnGPKnzSIgmaOTQq7b65OkO2War4qnEPraCZJ1E8SsCB0jm0y7sk FZjTZmH2DuR8HmAAC9C6L5CeXGfjuQXyFQB/y77n3N+Df3d7ctCCpGXNJDTP5+Q/USFU zvp4qTzsNeZrAJVCSLYu0lWE0Ew2nqVYPfha8a4nGLgtC24LAXksYJXXLnzLaqJD6Sp2 ZXfQ== X-Gm-Message-State: ALoCoQkXt1uOMflSEJcZLAvyVxiMeUHkNAZ0ZsVl0UghmgO0CkNfLxs59BySzax8Jv3UpJoN0wgs MIME-Version: 1.0 X-Received: by 10.42.61.146 with SMTP id u18mr28065242ich.1.1410809993221; Mon, 15 Sep 2014 12:39:53 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Mon, 15 Sep 2014 12:39:53 -0700 (PDT) In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> <5dab12b5-ad9a-4f1f-8908-b53509e1583d@email.android.com> <8761gq41j6.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 15 Sep 2014 12:39:53 -0700 Message-ID: From: Brandon Long To: Scott Kitterman Content-Type: multipart/alternative; boundary=20cf302240217e10b105031fcc5e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1s4kgfzBVzs5IF1dfWcV9efM_aM Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:40:06 -0000 --20cf302240217e10b105031fcc5e Content-Type: text/plain; charset=UTF-8 On Sun, Sep 14, 2014 at 12:34 PM, Scott Kitterman wrote: > On September 14, 2014 12:20:13 PM EDT, "Stephen J. Turnbull" < > stephen@xemacs.org> wrote: > >Scott Kitterman writes: > > > > > And by the time that's done, how many non-standard variants will be > > > in use and "too hard to change"? > > > >Why should anyone care? That's an honest question, because I think > >the chances are quite good that Hector is right. Yahoo! and AOL have > >demonstrated that they care less about reliable delivery than other > >providers do, and they will lose mailbox users because of that, and > >the rate of loss will increase over time as people make other > >arrangements or store up annoyance. It won't kill either of them, but > >it will hurt, and they will find ways to do without p=reject. Is it > >really worth trying to patch up the nonconforming implementations if > >the need will automatically go away? (At least for GNU Mailman, where > >no p=reject => no From munging and no message wrapping). > > > > > Whatever IETF documents say, it's already been redefined in the > > > world of running code. > > > >My point is that so has Reply-To, and the IETF has *pointedly* ignored > >that fact for decades. > > > > > I'd propose something along the lines of "we don't endorse From > > > rewriting by mailing lists, > > > >This WG is not just about mailing lists. Have you thought about other > >indirect mail use cases? > > > > > but if you're going to do it anyway, do it this way". Then this > > > can be decoupled from the larger semantic issue since we know > > > there's a loss of information problem to be solved regardless of > > > anyone's opinion about From rewriting. > > > >Good luck, because I expect the IETF to prefer pointedly ignoring > >nonconforming implementations in its documents, or perhaps outright > >condemnation, to anything like what you're proposing. > > Witness the excellent success of the head in the sand approach to stopping > use of NAT. > > People are already routing around the damage. The mailing list issue is > particularly problematic because it's affecting users of domains that don't > have reject policies. > > Google didn't invest the engineering resources in selective From rewriting > for Google Groups to solve a non-problem. > Honestly, I've spent way more engineering resources debating it than it took to actually do it. That's part of the lure, of course, is that its so damn easy to do. And, yes, we had to do something to fix things for our subscribers, since despite what others may want to believe or witness as anecdote, people aren't flocking away from yahoo/aol addresses due to their now being p=REJECT domains. Brandon --20cf302240217e10b105031fcc5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 12:34 PM, Scott Kitterman <= ;sklist@kitterman= .com> wrote:
On September 14, 2014 12:20:13 PM EDT, "Step= hen J. Turnbull" <stephen@xem= acs.org> wrote:
>Scott Kitterman writes:
>
> > And by the time that's done, how many non-standard variants w= ill be
> > in use and "too hard to change"?
>
>Why should anyone care?=C2=A0 That's an honest question, because I = think
>the chances are quite good that Hector is right.=C2=A0 Yahoo! and AOL h= ave
>demonstrated that they care less about reliable delivery than other
>providers do, and they will lose mailbox users because of that, and
>the rate of loss will increase over time as people make other
>arrangements or store up annoyance.=C2=A0 It won't kill either of t= hem, but
>it will hurt, and they will find ways to do without p=3Dreject.=C2=A0 I= s it
>really worth trying to patch up the nonconforming implementations if >the need will automatically go away?=C2=A0 (At least for GNU Mailman, w= here
>no p=3Dreject =3D> no From munging and no message wrapping).
>
> > Whatever IETF documents say, it's already been redefined in t= he
> > world of running code.
>
>My point is that so has Reply-To, and the IETF has *pointedly* ignored<= br> >that fact for decades.
>
> > I'd propose something along the lines of "we don't e= ndorse From
> > rewriting by mailing lists,
>
>This WG is not just about mailing lists.=C2=A0 Have you thought about o= ther
>indirect mail use cases?
>
> > but if you're going to do it anyway, do it this way".=C2= =A0 Then this
> > can be decoupled from the larger semantic issue since we know
> > there's a loss of information problem to be solved regardless= of
> > anyone's opinion about From rewriting.
>
>Good luck, because I expect the IETF to prefer pointedly ignoring
>nonconforming implementations in its documents, or perhaps outright
>condemnation, to anything like what you're proposing.

Witness the excellent success of the head in the sand approach = to stopping use of NAT.

People are already routing around the damage. The mailing list issue is par= ticularly problematic because it's affecting users of domains that don&= #39;t have reject policies.

Google didn't invest the engineering resources in selective From rewrit= ing for Google Groups to solve a non-problem.

Honestly, I've spent way more engineering resources debating it = than it took to actually do it.=C2=A0 That's part of the lure, of cours= e, is that its so damn easy to do.

And, yes, we ha= d to do something to fix things for our subscribers, since despite what oth= ers may want to believe or witness as anecdote, people aren't flocking = away from yahoo/aol addresses due to their now being p=3DREJECT domains.

Brandon
--20cf302240217e10b105031fcc5e-- From nobody Mon Sep 15 12:46:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806991A6F45 for ; Mon, 15 Sep 2014 12:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 DW9vtOspjk6C for ; Mon, 15 Sep 2014 12:46:03 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FE91A6F51 for ; Mon, 15 Sep 2014 12:46:02 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tp5so5341823ieb.15 for ; Mon, 15 Sep 2014 12:46:02 -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=sa9CTyN+4DpRUY00FCW9uaO/UaQ5GXZYDPldyx9nIPs=; b=GrvEb5m2BTuaHrKL5S3K+P1ONoOfQJnXqzSE5uYzM33WBMzB61P99aN1GAS2TqwrWx 4zsmAFXzELxS/PLuOSFdQXJ2bGmu0RhdH1UY3y8QHv8LjPFaSWytZ5x4fAXPettuoe9u KghcAuFbqY6e4bek09y1Ycamt6oTBKqdo/ZRxNP0YQL3DCqoZu+MtOpp7yRuEKuYkDsU ysV1AivLPIRlLMpoGrKM4LkUAdVUmlqWlM04Q8maf5KJyZbBdJut0UsnW4zpDnUO62/O bkI0YfcJ3dxF/ZmhvxsDRHfG5A2ois5/JBfNQPVH/eYl0pW8sjS95n6XqI14ygPobRR9 xCQQ== 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=sa9CTyN+4DpRUY00FCW9uaO/UaQ5GXZYDPldyx9nIPs=; b=DOmneyZCV0kE7erKDKDgzYo80fyrG5+YUaGbr0I0OChsOAa8uPk3gDbUqMzWHEabU8 jh/AKMJCKt0G5QRzeL+tHAWNBOP+YXyplcsemJWsG9oCjcjn3I4zIAlnlrShS3TmE4RI yWZHWn7/QnBaNDw01TAnOaqdAP810J3KZqSxmmgKn6wYPtmfKUXhoGZLIjSy+gQnl0Ja STHjqqZ4GrXmCQc+AvfxAGHwMGEOehkIuzFRLWjBNDVu4Z0ovwvYNrFA+NMCA+A2xLVb CWzFI7Z8+qEYA5u5SjgG9cLgI9hLrbqsfljK80Ub/2OT+uR3nRYmXDrAiOGfjxNgvplj ktPA== X-Gm-Message-State: ALoCoQkXwYOExgUvuXOfNVtZMK9zKLZU1gInYGmPdmmu7s6CwArDX8pWkYqTTrFZnmEnZY68VRgd MIME-Version: 1.0 X-Received: by 10.42.227.10 with SMTP id iy10mr28913706icb.3.1410810362199; Mon, 15 Sep 2014 12:46:02 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Mon, 15 Sep 2014 12:46:02 -0700 (PDT) In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <5095831.vR8OcjAh40@scott-latitude-e6320> <3657835.KmjXCTr7Sk@scott-latitude-e6320> <87oaui4mkf.fsf@uwakimon.sk.tsukuba.ac.jp> <5dab12b5-ad9a-4f1f-8908-b53509e1583d@email.android.com> <8761gq41j6.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 15 Sep 2014 12:46:02 -0700 Message-ID: From: Brandon Long To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c3e50e7c2a5705031fe290 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YIYhgYlerbYbdCrsaFnnCwAzDNE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:46:04 -0000 --001a11c3e50e7c2a5705031fe290 Content-Type: text/plain; charset=UTF-8 On Sun, Sep 14, 2014 at 12:34 PM, Scott Kitterman wrote: > > I can (an plan to) write code that leverages their X-Original-To. I'd > rather have something standardized, but it's not essential for me to solve > the problem I'm having. For the broader internet, I'm not so sure. (assuming you meant X-Original-From): Theoretically, this seems fine... as long as you don't display the results directly in the UI, since that would defeat the whole purpose of DMARC and re-writing the From in the first place. As for why we did that, its kind of a our default to add an X-Original or X-Google-Original prefix when rewriting headers. We're still debating whether or not we should do anything more with it, or adjust how we generate reply-to headers in these cases... or even add the author to the list footer, but there's been no burning need so far. Brandon --001a11c3e50e7c2a5705031fe290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 12:34 PM, Scott Kitterman <= ;sklist@kitterman= .com> wrote:

I can (an plan to) write code that leverages their X-Original-To.=C2=A0 I&#= 39;d rather have something standardized, but it's not essential for me = to solve the problem I'm having. For the broader internet, I'm not = so sure.

(assuming you meant X-Original-Fro= m):
=C2=A0
Theoretically, this seems fine... as long as= you don't display the results directly in the UI, since that would def= eat the whole purpose of DMARC and re-writing the From in the first place.<= /div>

As for why we did that, its kind of a our default = to add an X-Original or X-Google-Original prefix when rewriting headers.=C2= =A0 We're still debating whether or not we should do anything more with= it, or adjust how we generate reply-to headers in these cases... or even a= dd the author to the list footer, but there's been no burning need so f= ar.

Brandon
--001a11c3e50e7c2a5705031fe290-- From nobody Mon Sep 15 12:56:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90871A6FE0 for ; Mon, 15 Sep 2014 12:56:46 -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 XjHS9shMHrZA for ; Mon, 15 Sep 2014 12:56:45 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CD71A6FEC for ; Mon, 15 Sep 2014 12:56:30 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 6AE95D046BC; Mon, 15 Sep 2014 15:56:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1410810988; bh=5mb+dC2h+C/cY/Hup6Tw3Naay9FqSWWmzC623ZSP1yI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VUCnJ2xuK3lonHQsRrxee0vM/XTF+kCW/n+H0AtKvjSujI6K6sXoIn3MqqX7kqcPz BPxxISto4/h9l4eWgW1F3yE2UW2Ph6FYk+C9xuTA4hCAEdyCPLGyhkkDq55Div4gRb UoLZzOlJ8OvRaBf1TeQ23f1qFFrfAWG27GUNWsR8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3D3ECD0461C; Mon, 15 Sep 2014 15:56:28 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 15 Sep 2014 15:56:22 -0400 Message-ID: <1976470.DIDb21Ceeq@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/48aevFfpWKiYHYLsll3IGDWAnZQ Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:56:46 -0000 On Monday, September 15, 2014 12:46:02 Brandon Long wrote: > On Sun, Sep 14, 2014 at 12:34 PM, Scott Kitterman > > wrote: > > I can (an plan to) write code that leverages their X-Original-To. I'd > > rather have something standardized, but it's not essential for me to solve > > the problem I'm having. For the broader internet, I'm not so sure. > > (assuming you meant X-Original-From): > > Theoretically, this seems fine... as long as you don't display the results > directly in the UI, since that would defeat the whole purpose of DMARC and > re-writing the From in the first place. > > As for why we did that, its kind of a our default to add an X-Original or > X-Google-Original prefix when rewriting headers. We're still debating > whether or not we should do anything more with it, or adjust how we > generate reply-to headers in these cases... or even add the author to the > list footer, but there's been no burning need so far. I do (mean that one). I agree that displaying it would be wrong. My thought is to, as a companion to the current Reply to Mailing List reply option, add a Reply to Mailing List Author option that would direct the reply to X-Original- >From (and/or whatever equivalent might get standardized) or the actual From if none of those are present. Thanks, Scott K From nobody Mon Sep 15 13:38:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AB81A86F8 for ; Mon, 15 Sep 2014 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elM6qL0Ai14Y for ; Mon, 15 Sep 2014 13:38:28 -0700 (PDT) Received: from vincent.hireahit.com (vincent.hireahit.com [23.19.120.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D581A6F92 for ; Mon, 15 Sep 2014 13:38:23 -0700 (PDT) Received: from VINCENT.hireahit.com by hireahit.com (vincent.hireahit.com) (SecurityGateway 3.0.2) with ESMTP id SG001170789.MSG for ; Mon, 15 Sep 2014 13:38:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=hireahit.com; s=MD-20140321; t=1410813498; x=1411418298; q=dns/txt; h=Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=d0qqaFJsVhz/cOsjCHDMq5+VTRCG2RCmE8K5MEUxLvk=; b=G4m10N3/jjQY6 jBuIgVDBAdqFhcp0oohLt45NpucyKEeyFTiL8kqc51KY0jJFOCAQ1MeCGKGL0XAs /EvFpF0Srvpie9gKIYsLcb1m+2sjEjNVwD2aguNTb7DfKluY1Jrv6hZDlGenKgdo 3YGcTaw3LcJf/sGSmAd5PtNVaNda+I= Received: from [x.x.x.x] ([184.68.44.226]) by VINCENT.hireahit.com (VINCENT.hireahit.com [23.19.120.58]) (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.5.0rc2) with ESMTPSA id 05-md50000011020.msg for ; Mon, 15 Sep 2014 13:38:16 -0700 X-Spam-Processed: VINCENT.hireahit.com, Mon, 15 Sep 2014 13:38:16 -0700 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 184.68.44.226 X-MDArrival-Date: Mon, 15 Sep 2014 13:38:16 -0700 X-Authenticated-Sender: davew@hireahit.com X-Return-Path: davew@hireahit.com X-Envelope-From: davew@hireahit.com X-MDaemon-Deliver-To: dmarc@ietf.org Message-ID: <54174E33.7010309@hireahit.com> Date: Mon, 15 Sep 2014 13:38:11 -0700 From: Dave Warren User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:24.0) Gecko/20140623 FossaMail/24.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/A-WAwaXhb2NNgw0hrqT7prD3rNo Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:38:30 -0000 On 2014-09-15 10:39, Henrik Schack wrote: > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam > provider breaking DKIM signatures. > They break DKIM signatures on incoming email by adding a "Virus > scanned by xxxx" line to the body of the email. > > Not sure how to fix this, but perhaps some day they'll get tired of my > bi-monthly calls and emails complaining about how they do things. > I doubt your calls are nearly as annoying as they value they receive from the free advertising -- It's not just "Put your name in front of someone" advertising, it's a defacto endorsement, it's a "My friend/colleague/whatever uses This Product, so maybe I should too?" I look at them like I look at people that leave their mobile mail client's default signature, I assume they don't know any better, but I don't expect companies to ever stop trying to get free advertising in this way. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren From nobody Mon Sep 15 14:16:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376EA1A875A for ; Mon, 15 Sep 2014 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOsTo7IxhnJw for ; Mon, 15 Sep 2014 14:16:39 -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 466331A875B for ; Mon, 15 Sep 2014 14:16:39 -0700 (PDT) Received: (qmail 85442 invoked from network); 15 Sep 2014 21:16:38 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 15 Sep 2014 21:16:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ad7.54175735.k1409; i=johnl@user.iecc.com; bh=WajkS0kL5QAkE8SRf5MZWE/w67S0HHaG2BQyHqfJ6ho=; b=BmAmTUN0ucCrEwF46k4yr3xQOG9jnV0WKme5Mf8kYU3K/klxtDmZFZhw1mLerZDUhy/pjqVl+0ZgtWM5Fcfva5CAZJwV+J3bDIciBv168x2vuyxtmKstciIiSMupRDFkIa1h43CRCu/OcI5b2eMFjdi6nB/C18eIXiYdfJuoJkmZDHa3fQo7BvIowpQwGyhtzJRRu6K2IJnRP4zUym1cibMc+lyRGG/iVr6mhxUiLKnwnbgBpD6wcvTPKyqwIqft DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ad7.54175735.k1409; olt=johnl@user.iecc.com; bh=WajkS0kL5QAkE8SRf5MZWE/w67S0HHaG2BQyHqfJ6ho=; b=xNH3skLkw5BZ++OKzjvnh0c6nox/8T5coapEbxz9abDA9TRqsCghBZiL/BXaLZKuCNexJDtvZu/lcNJ+P8R3k0qQk80Py3rG5MOyYvC2McZopFrF0TXBug3bPWoiV10zHrRbSkYfZpcT2ppc3RJtBJZXvWfynR7McU9AUkrnwF+ibVZB4jhPVYkWXcCJ62DYxm+lvs/JA7xxF43qlHcgcqsDleU90MOByHJB12RgZ3Jgd/GsNLtjo1If0qmG524g Date: 15 Sep 2014 21:16:15 -0000 Message-ID: <20140915211615.2774.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FCZmwqHbkFIZ7zWHcWhYzGlWd98 Cc: henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:16:40 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provider >breaking DKIM signatures. >They break DKIM signatures on incoming email by adding a "Virus scanned by >xxxx" line to the body of the email. > >Not sure how to fix this, but perhaps some day they'll get tired of my >bi-monthly calls and emails complaining about how they do things. As other people have said, put the advertisement in a header, not in the body. R's, John -- This message is infected with annoying ads because it has been scanned by Avast! anti-virus. From nobody Mon Sep 15 17:14:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B611A0071 for ; Mon, 15 Sep 2014 17:14:13 -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 F8PoBMp_OY8A for ; Mon, 15 Sep 2014 17:14:11 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8332A1A0066 for ; Mon, 15 Sep 2014 17:14:11 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.0.1044.2; Mon, 15 Sep 2014 23:39:33 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.39]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.39]) with mapi id 15.00.1044.000; Mon, 15 Sep 2014 23:39:33 +0000 From: Terry Zink To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider Thread-Index: AQHP0RIs/XmdSYuAHUucix/QFdgotpwCsmyAgAAntCA= Date: Mon, 15 Sep 2014 23:39:32 +0000 Message-ID: <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140915211615.2774.qmail@joyce.lan> In-Reply-To: <20140915211615.2774.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(13464003)(377454003)(51704005)(199003)(19580405001)(19580395003)(64706001)(46102001)(81542001)(81342001)(80022001)(31966008)(15975445006)(83322001)(74502001)(74662001)(4396001)(83072002)(87936001)(92566001)(79102001)(2656002)(33646002)(85852003)(20776003)(105586002)(101416001)(77982001)(107046002)(50986999)(54356999)(106356001)(76176999)(106116001)(97736003)(85306004)(21056001)(99396002)(108616004)(90102001)(76482001)(2501002)(21314002)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dwPYkjH0AscYQwxwqYToRezmxO0 Cc: "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 00:14:14 -0000 Having the "Virus scanned by xxx" defeats the purpose of advertising becaus= e most mail clients won't display it, and the point of adding this to the b= ody is so that other people can see it. I think Murray's earlier suggestion= to perform the DKIM check before A/V filtering is the best option. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine Sent: Monday, September 15, 2014 2:16 PM To: dmarc@ietf.org Cc: henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by c= loud anti-virus/spam provider In article you write: >-=3D-=3D-=3D-=3D-=3D- >-=3D-=3D-=3D-=3D-=3D- > >In Denmark we have a somewhat large (10K+ domains) anti-virus/spam provide= r >breaking DKIM signatures. >They break DKIM signatures on incoming email by adding a "Virus scanned by >xxxx" line to the body of the email. > >Not sure how to fix this, but perhaps some day they'll get tired of my >bi-monthly calls and emails complaining about how they do things. As other people have said, put the advertisement in a header, not in the bo= dy. R's, John -- This message is infected with annoying ads because it has been scanned by A= vast! anti-virus. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Sep 15 17:20:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A531A0087 for ; Mon, 15 Sep 2014 17:20: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 AnxLPpojKq3K for ; Mon, 15 Sep 2014 17:20:38 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C465A1A0066 for ; Mon, 15 Sep 2014 17:20:37 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so5725077lab.15 for ; Mon, 15 Sep 2014 17:20:35 -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=SibIqVWnMkuNXBLVxx+TjmDhla/w+J2cK3i+G1/DN10=; b=bv7kIy6jyJwS4ekCZOmjnC2xKbtW+6EmLOzr3yWUoiOOh3TDiUuz/t+xmWE6VuFNog 224l/G8Cu7vkr21bpGJmPrqyLdBmaUPK4R8atOYxDIpiM8fTJ69WxgtcYi1cn+7YSOlD d0lz4X3GlucdDi4ugjeqaG+wO3Gs9Dq41SVZcfn8FnhK6H6IwRw1jdPFeFZg2qTb8kNI FtsMlXwFQg9vLk9Duvpx+B/YIirojWkAVOhlUtp+iq7vj+AsCSXuGxEsHTxZCQdDkz0c BuabwydPSgKSihd+ztEBiVNSEEVQqfll0WRNfFXsdcNOFJTgWPE6aRHFBiCn9GHf5snu 4Iog== MIME-Version: 1.0 X-Received: by 10.112.143.105 with SMTP id sd9mr30874617lbb.43.1410826835636; Mon, 15 Sep 2014 17:20:35 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 17:20:35 -0700 (PDT) In-Reply-To: <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Mon, 15 Sep 2014 17:20:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e010d8d0260b7ca050323b8a3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uRcq9hzD3bg1-b2fBN6op68qC-E Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 00:20:40 -0000 --089e010d8d0260b7ca050323b8a3 Content-Type: text/plain; charset=UTF-8 How will most mail clients know not to display it if it's made part of the body? On Mon, Sep 15, 2014 at 4:39 PM, Terry Zink wrote: > Having the "Virus scanned by xxx" defeats the purpose of advertising > because most mail clients won't display it, and the point of adding this to > the body is so that other people can see it. I think Murray's earlier > suggestion to perform the DKIM check before A/V filtering is the best > option. > > -- Terry > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine > Sent: Monday, September 15, 2014 2:16 PM > To: dmarc@ietf.org > Cc: henrik@schack.dk > Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by > cloud anti-virus/spam provider > > In article T00PLRg@mail.gmail.com> you write: > >-=-=-=-=-=- > >-=-=-=-=-=- > > > >In Denmark we have a somewhat large (10K+ domains) anti-virus/spam > provider > >breaking DKIM signatures. > >They break DKIM signatures on incoming email by adding a "Virus scanned by > >xxxx" line to the body of the email. > > > >Not sure how to fix this, but perhaps some day they'll get tired of my > >bi-monthly calls and emails complaining about how they do things. > > As other people have said, put the advertisement in a header, not in the > body. > > R's, > John > -- > This message is infected with annoying ads because it has been scanned by > Avast! anti-virus. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e010d8d0260b7ca050323b8a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How will most mail clients know not to display it if it= 9;s made part of the body?

On Mon, Sep 15, 2014 at 4:39 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:
Having the "Virus scanned by xxx" defeats the purpose = of advertising because most mail clients won't display it, and the poin= t of adding this to the body is so that other people can see it. I think Mu= rray's earlier suggestion to perform the DKIM check before A/V filterin= g is the best option.

-- Terry

-----Original Message-----
From: dmarc [mailto:dmarc-bounces= @ietf.org] On Behalf Of John Levine
Sent: Monday, September 15, 2014 2:16 PM
To: dmarc@ietf.org
Cc: henrik@schack.dk
Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by c= loud anti-virus/spam provider

In article <CAGfQzLTvB9C97s=3DcGZ-k17ynv0=3DJUr6pygEbVnohhA=3DT00PLRg@mail.gmail.com> you write: >-=3D-=3D-=3D-=3D-=3D-
>-=3D-=3D-=3D-=3D-=3D-
>
>In Denmark we have a somewhat large (10K+ domains) anti-virus/spam prov= ider
>breaking DKIM signatures.
>They break DKIM signatures on incoming email by adding a "Virus sc= anned by
>xxxx" line to the body of the email.
>
>Not sure how to fix this, but perhaps some day they'll get tired of= my
>bi-monthly calls and emails complaining about how they do things.

As other people have said, put the advertisement in a header, not in the bo= dy.

R's,
John
--
This message is infected with annoying ads because it has been scanned by A= vast! anti-virus.

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

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

--089e010d8d0260b7ca050323b8a3-- From nobody Mon Sep 15 17:26:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12EE1A00B0 for ; Mon, 15 Sep 2014 17:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 73mjDLSfvUu2 for ; Mon, 15 Sep 2014 17:26:15 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F60D1A00A8 for ; Mon, 15 Sep 2014 17:26:15 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.0.1044.2; Tue, 16 Sep 2014 00:26:13 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.39]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.39]) with mapi id 15.00.1044.000; Tue, 16 Sep 2014 00:26:13 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider Thread-Index: AQHP0RIs/XmdSYuAHUucix/QFdgotpwCsmyAgAAntCCAAAvMgIAAARYA Date: Tue, 16 Sep 2014 00:26:13 +0000 Message-ID: <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(24454002)(199003)(189002)(377454003)(13464003)(110136001)(97736003)(85306004)(21056001)(107046002)(50986999)(54356999)(77982001)(19617315012)(76176999)(106356001)(106116001)(76482001)(90102001)(1411001)(99396002)(108616004)(31966008)(15202345003)(81342001)(81542001)(80022001)(74502001)(74662001)(4396001)(19300405004)(19609705001)(15975445006)(83322001)(19580405001)(19580395003)(46102001)(64706001)(20776003)(105586002)(85852003)(101416001)(87936001)(93886004)(19625215002)(83072002)(2656002)(16236675004)(33646002)(92566001)(79102001)(21314002)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_4634fc4c6a16478ca725a79b67af1f5eBL2SR01MB605namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oAmrH7iDqGADmYxX8RVAEXRBIZI Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 00:26:18 -0000 --_000_4634fc4c6a16478ca725a79b67af1f5eBL2SR01MB605namsdf01sdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXIsIHdoYXQgSSBtZWFudCB3YXMgdGhpczoNCg0KSGF2aW5nIHRoZSAiVmlydXMgc2Nhbm5lZCBi eSB4eHgiICoqKmluIGEgaGVhZGVyKioqIGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2YgYWR2ZXJ0aXNp bmcgc2luY2UgbW9zdCBjbGllbnRzIHdvbuKAmXQgZGlzcGxheSBpdC4gQS9WIGZpbHRlcnMgcHV0 IHRob3NlIHRhZ2xpbmVzIGluIHRoZXJlIHRvIGFkdmVydGlzZSwgbm90IGp1c3QgdG8gdGVsbCB0 aGUgbWFpbCBjbGllbnQgdGhhdCB0aGVpciBtYWlsIGhhcyBiZWVuIHNjYW5uZWQuDQoNCi0tIFRl cnJ5DQoNCkZyb206IE11cnJheSBTLiBLdWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwu Y29tXQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTQgNToyMSBQTQ0KVG86IFRlcnJ5 IFppbmsNCkNjOiBKb2huIExldmluZTsgZG1hcmNAaWV0Zi5vcmc7IGhlbnJpa0BzY2hhY2suZGsN ClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gSW5kaXJlY3QgbWFpbCBmbG93czogREtJTSBzaWdu YXR1cmUgYnJlYWthZ2UgYnkgY2xvdWQgYW50aS12aXJ1cy9zcGFtIHByb3ZpZGVyDQoNCkhvdyB3 aWxsIG1vc3QgbWFpbCBjbGllbnRzIGtub3cgbm90IHRvIGRpc3BsYXkgaXQgaWYgaXQncyBtYWRl IHBhcnQgb2YgdGhlIGJvZHk/DQoNCk9uIE1vbiwgU2VwIDE1LCAyMDE0IGF0IDQ6MzkgUE0sIFRl cnJ5IFppbmsgPHR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb208bWFpbHRvOnR6aW5rQGV4Y2hh bmdlLm1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkhhdmluZyB0aGUgIlZpcnVzIHNjYW5uZWQgYnkg eHh4IiBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGFkdmVydGlzaW5nIGJlY2F1c2UgbW9zdCBtYWls IGNsaWVudHMgd29uJ3QgZGlzcGxheSBpdCwgYW5kIHRoZSBwb2ludCBvZiBhZGRpbmcgdGhpcyB0 byB0aGUgYm9keSBpcyBzbyB0aGF0IG90aGVyIHBlb3BsZSBjYW4gc2VlIGl0LiBJIHRoaW5rIE11 cnJheSdzIGVhcmxpZXIgc3VnZ2VzdGlvbiB0byBwZXJmb3JtIHRoZSBES0lNIGNoZWNrIGJlZm9y ZSBBL1YgZmlsdGVyaW5nIGlzIHRoZSBiZXN0IG9wdGlvbi4NCg0KLS0gVGVycnkNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2hu IExldmluZQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTQgMjoxNiBQTQ0KVG86IGRt YXJjQGlldGYub3JnPG1haWx0bzpkbWFyY0BpZXRmLm9yZz4NCkNjOiBoZW5yaWtAc2NoYWNrLmRr PG1haWx0bzpoZW5yaWtAc2NoYWNrLmRrPg0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBJbmRp cmVjdCBtYWlsIGZsb3dzOiBES0lNIHNpZ25hdHVyZSBicmVha2FnZSBieSBjbG91ZCBhbnRpLXZp cnVzL3NwYW0gcHJvdmlkZXINCg0KSW4gYXJ0aWNsZSA8Q0FHZlF6TFR2QjlDOTdzPWNHWi1rMTd5 bnYwPUpVcjZweWdFYlZub2hoQT1UMDBQTFJnQG1haWwuZ21haWwuY29tPG1haWx0bzpUMDBQTFJn QG1haWwuZ21haWwuY29tPj4geW91IHdyaXRlOg0KPi09LT0tPS09LT0tDQo+LT0tPS09LT0tPS0N Cj4NCj5JbiBEZW5tYXJrIHdlIGhhdmUgYSBzb21ld2hhdCBsYXJnZSAoMTBLKyBkb21haW5zKSBh bnRpLXZpcnVzL3NwYW0gcHJvdmlkZXINCj5icmVha2luZyBES0lNIHNpZ25hdHVyZXMuDQo+VGhl eSBicmVhayBES0lNIHNpZ25hdHVyZXMgb24gaW5jb21pbmcgZW1haWwgYnkgYWRkaW5nIGEgIlZp cnVzIHNjYW5uZWQgYnkNCj54eHh4IiBsaW5lIHRvIHRoZSBib2R5IG9mIHRoZSBlbWFpbC4NCj4N Cj5Ob3Qgc3VyZSBob3cgdG8gZml4IHRoaXMsIGJ1dCBwZXJoYXBzIHNvbWUgZGF5IHRoZXknbGwg Z2V0IHRpcmVkIG9mIG15DQo+YmktbW9udGhseSBjYWxscyBhbmQgZW1haWxzIGNvbXBsYWluaW5n IGFib3V0IGhvdyB0aGV5IGRvIHRoaW5ncy4NCg0KQXMgb3RoZXIgcGVvcGxlIGhhdmUgc2FpZCwg cHV0IHRoZSBhZHZlcnRpc2VtZW50IGluIGEgaGVhZGVyLCBub3QgaW4gdGhlIGJvZHkuDQoNClIn cywNCkpvaG4NCi0tDQpUaGlzIG1lc3NhZ2UgaXMgaW5mZWN0ZWQgd2l0aCBhbm5veWluZyBhZHMg YmVjYXVzZSBpdCBoYXMgYmVlbiBzY2FubmVkIGJ5IEF2YXN0ISBhbnRpLXZpcnVzLg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFpbGlu ZyBsaXN0DQpkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbWFyYyBtYWlsaW5nIGxpc3QNCmRtYXJjQGll dGYub3JnPG1haWx0bzpkbWFyY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1hcmMNCg0K --_000_4634fc4c6a16478ca725a79b67af1f5eBL2SR01MB605namsdf01sdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1l OmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RXIsIHdoYXQgSSBtZWFu dCB3YXMgdGhpczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SGF2aW5nIHRoZSAmcXVvdDtWaXJ1cyBzY2FubmVkIGJ5IHh4eCZxdW90OyAq KippbiBhIGhlYWRlcioqKiBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGFkdmVydGlzaW5nIHNpbmNl IG1vc3QgY2xpZW50cyB3b27igJl0IGRpc3BsYXkgaXQuIEEvViBmaWx0ZXJzIHB1dCB0aG9zZSB0 YWdsaW5lcyBpbiB0aGVyZSB0byBhZHZlcnRpc2UsDQogbm90IGp1c3QgdG8gdGVsbCB0aGUgbWFp bCBjbGllbnQgdGhhdCB0aGVpciBtYWlsIGhhcyBiZWVuIHNjYW5uZWQuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0tIFRlcnJ5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNdXJyYXkgUy4gS3VjaGVyYXd5IFtt YWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNl cHRlbWJlciAxNSwgMjAxNCA1OjIxIFBNPGJyPg0KPGI+VG86PC9iPiBUZXJyeSBaaW5rPGJyPg0K PGI+Q2M6PC9iPiBKb2huIExldmluZTsgZG1hcmNAaWV0Zi5vcmc7IGhlbnJpa0BzY2hhY2suZGs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBJbmRpcmVjdCBtYWlsIGZsb3dz OiBES0lNIHNpZ25hdHVyZSBicmVha2FnZSBieSBjbG91ZCBhbnRpLXZpcnVzL3NwYW0gcHJvdmlk ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgd2lsbCBtb3N0IG1h aWwgY2xpZW50cyBrbm93IG5vdCB0byBkaXNwbGF5IGl0IGlmIGl0J3MgbWFkZSBwYXJ0IG9mIHRo ZSBib2R5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBTZXAgMTUsIDIwMTQgYXQgNDozOSBQTSwgVGVycnkgWmluayAmbHQ7PGEgaHJlZj0ibWFp bHRvOnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50emlua0Bl eGNoYW5nZS5taWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5nIHRoZSAmcXVvdDtWaXJ1cyBzY2Fu bmVkIGJ5IHh4eCZxdW90OyBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGFkdmVydGlzaW5nIGJlY2F1 c2UgbW9zdCBtYWlsIGNsaWVudHMgd29uJ3QgZGlzcGxheSBpdCwgYW5kIHRoZSBwb2ludCBvZiBh ZGRpbmcgdGhpcyB0byB0aGUgYm9keSBpcyBzbyB0aGF0IG90aGVyIHBlb3BsZSBjYW4gc2VlIGl0 LiBJIHRoaW5rIE11cnJheSdzIGVhcmxpZXIgc3VnZ2VzdGlvbiB0byBwZXJmb3JtDQogdGhlIERL SU0gY2hlY2sgYmVmb3JlIEEvViBmaWx0ZXJpbmcgaXMgdGhlIGJlc3Qgb3B0aW9uLjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLSBU ZXJyeTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog ZG1hcmMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZyI+ZG1h cmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKb2huIExldmluZTxicj4NClNl bnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE1LCAyMDE0IDI6MTYgUE08YnI+DQpUbzogPGEgaHJlZj0i bWFpbHRvOmRtYXJjQGlldGYub3JnIj5kbWFyY0BpZXRmLm9yZzwvYT48YnI+DQpDYzogPGEgaHJl Zj0ibWFpbHRvOmhlbnJpa0BzY2hhY2suZGsiPmhlbnJpa0BzY2hhY2suZGs8L2E+PGJyPg0KU3Vi amVjdDogUmU6IFtkbWFyYy1pZXRmXSBJbmRpcmVjdCBtYWlsIGZsb3dzOiBES0lNIHNpZ25hdHVy ZSBicmVha2FnZSBieSBjbG91ZCBhbnRpLXZpcnVzL3NwYW0gcHJvdmlkZXI8YnI+DQo8YnI+DQpJ biBhcnRpY2xlICZsdDtDQUdmUXpMVHZCOUM5N3M9Y0daLWsxN3ludjA9SlVyNnB5Z0ViVm5vaGhB PTxhIGhyZWY9Im1haWx0bzpUMDBQTFJnQG1haWwuZ21haWwuY29tIj5UMDBQTFJnQG1haWwuZ21h aWwuY29tPC9hPiZndDsgeW91IHdyaXRlOjxicj4NCiZndDstPS09LT0tPS09LTxicj4NCiZndDst PS09LT0tPS09LTxicj4NCiZndDs8YnI+DQomZ3Q7SW4gRGVubWFyayB3ZSBoYXZlIGEgc29tZXdo YXQgbGFyZ2UgKDEwSyYjNDM7IGRvbWFpbnMpIGFudGktdmlydXMvc3BhbSBwcm92aWRlcjxicj4N CiZndDticmVha2luZyBES0lNIHNpZ25hdHVyZXMuPGJyPg0KJmd0O1RoZXkgYnJlYWsgREtJTSBz aWduYXR1cmVzIG9uIGluY29taW5nIGVtYWlsIGJ5IGFkZGluZyBhICZxdW90O1ZpcnVzIHNjYW5u ZWQgYnk8YnI+DQomZ3Q7eHh4eCZxdW90OyBsaW5lIHRvIHRoZSBib2R5IG9mIHRoZSBlbWFpbC48 YnI+DQomZ3Q7PGJyPg0KJmd0O05vdCBzdXJlIGhvdyB0byBmaXggdGhpcywgYnV0IHBlcmhhcHMg c29tZSBkYXkgdGhleSdsbCBnZXQgdGlyZWQgb2YgbXk8YnI+DQomZ3Q7YmktbW9udGhseSBjYWxs cyBhbmQgZW1haWxzIGNvbXBsYWluaW5nIGFib3V0IGhvdyB0aGV5IGRvIHRoaW5ncy48YnI+DQo8 YnI+DQpBcyBvdGhlciBwZW9wbGUgaGF2ZSBzYWlkLCBwdXQgdGhlIGFkdmVydGlzZW1lbnQgaW4g YSBoZWFkZXIsIG5vdCBpbiB0aGUgYm9keS48YnI+DQo8YnI+DQpSJ3MsPGJyPg0KSm9objxicj4N Ci0tPGJyPg0KVGhpcyBtZXNzYWdlIGlzIGluZmVjdGVkIHdpdGggYW5ub3lpbmcgYWRzIGJlY2F1 c2UgaXQgaGFzIGJlZW4gc2Nhbm5lZCBieSBBdmFzdCEgYW50aS12aXJ1cy48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtYXJj IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbWFyYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1hcmM8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciPmRtYXJjQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_4634fc4c6a16478ca725a79b67af1f5eBL2SR01MB605namsdf01sdf_-- From nobody Mon Sep 15 17:30:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8754A1A00A7 for ; Mon, 15 Sep 2014 17:30:49 -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 7JQQzdQ3aDyY for ; Mon, 15 Sep 2014 17:30:48 -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 03A851A00AD for ; Mon, 15 Sep 2014 17:30:48 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8G0UeA5000779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 17:30:43 -0700 Message-ID: <541783E2.2070002@dcrocker.net> Date: Mon, 15 Sep 2014 17:27:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Terry Zink , "Murray S. Kucherawy" References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 15 Sep 2014 17:30:43 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XfFGQ9NjGGxD9oaJnzdKp4V2Llk Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider 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, 16 Sep 2014 00:30:49 -0000 On 9/15/2014 5:26 PM, Terry Zink wrote: > Having the "Virus scanned by xxx" ***in a header*** defeats the purpose > of advertising since most clients won’t display it. A/V filters put > those taglines in there to advertise, not just to tell the mail client > that their mail has been scanned. And having it displayed achieves what demonstrable benefit? Actual and measured, not theoretical and based on guesswork? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 18:15:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A107E1A00D8 for ; Mon, 15 Sep 2014 18:15:34 -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 88UW8I0R4NUm for ; Mon, 15 Sep 2014 18:15:32 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0F91A0099 for ; Mon, 15 Sep 2014 18:15:32 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.0.1044.2; Tue, 16 Sep 2014 00:59:33 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.39]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.39]) with mapi id 15.00.1044.000; Tue, 16 Sep 2014 00:59:33 +0000 From: Terry Zink To: "dcrocker@bbiw.net" , "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider Thread-Index: AQHP0RIs/XmdSYuAHUucix/QFdgotpwCsmyAgAAntCCAAAvMgIAAARYAgAAAxgCAAAhxgA== Date: Tue, 16 Sep 2014 00:59:33 +0000 Message-ID: <7db8f6390072485fbc1139deb3d6e7bd@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <541783E2.2070002@dcrocker.net> In-Reply-To: <541783E2.2070002@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(199003)(189002)(479174003)(377454003)(13464003)(97736003)(85306004)(21056001)(107046002)(50986999)(54356999)(77982001)(76176999)(106356001)(106116001)(76482001)(2501002)(90102001)(99396002)(108616004)(31966008)(81342001)(81542001)(80022001)(74502001)(74662001)(4396001)(83322001)(19580405001)(19580395003)(46102001)(64706001)(105586002)(85852003)(20776003)(87936001)(101416001)(93886004)(83072002)(2656002)(33646002)(92566001)(79102001)(21314002)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Vl5fM4YrJddM32fnNdzeVfcFOcY Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 01:15:34 -0000 I'm not saying I agree that an A/V company is right to put their tagline in= to the message, especially if it breaks DKIM. If I owned an A/V company, I = wouldn't do it [1]. However, I understand why A/V companies would do it - it (presumably) helps= drive revenue because it increases visibility in a way that putting it int= o a header does not. -- Terry [1] This is easy for me to say because I don't own an A/V company and my re= venue stream does not depend on it. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net]=20 Sent: Monday, September 15, 2014 5:27 PM To: Terry Zink; Murray S. Kucherawy Cc: dmarc@ietf.org; John Levine; henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by c= loud anti-virus/spam provider On 9/15/2014 5:26 PM, Terry Zink wrote: > Having the "Virus scanned by xxx" ***in a header*** defeats the purpose > of advertising since most clients won't display it. A/V filters put > those taglines in there to advertise, not just to tell the mail client > that their mail has been scanned. And having it displayed achieves what demonstrable benefit? Actual and measured, not theoretical and based on guesswork? d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 19:00:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0701A00F8 for ; Mon, 15 Sep 2014 19:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 K57n_qqPxFuM for ; Mon, 15 Sep 2014 19:00:46 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABA51A00A8 for ; Mon, 15 Sep 2014 19:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+F5pJeKrxLIUT+/zBuZ/ysf360v4kGLjtuuhJFfIR8s=; b=VKGKNaMEihtb5DpscBDhUKrUn7Q2t907ZPikZC+WO00WMGDBJOkJTEjQqo5BN/YmmH+4nHsxr3lmItMJtbDeuXmprgeKZL0SfkmToPROn78m0LATio+pAE4E5jX2IfNTqBymFKF1YfPf044HfpEDuPakSisa2zknZySEmfGFcIo=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=48450 helo=[10.100.1.110]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XTi4L-0001zf-Mr; Tue, 16 Sep 2014 02:00:38 +0000 Message-ID: <541799C5.3030800@rolandturner.com> Date: Tue, 16 Sep 2014 10:00:37 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dcrocker@bbiw.net, Terry Zink , "Murray S. Kucherawy" References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <541783E2.2070002@dcrocker.net> In-Reply-To: <541783E2.2070002@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fAwyVlr34B4FO1AWrENXZQ2aO3c Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 02:00:47 -0000 On 09/16/2014 08:27 AM, Dave Crocker wrote: > On 9/15/2014 5:26 PM, Terry Zink wrote: >> Having the "Virus scanned by xxx" ***in a header*** defeats the purpose >> of advertising since most clients won’t display it. A/V filters put >> those taglines in there to advertise, not just to tell the mail client >> that their mail has been scanned. > > And having it displayed achieves what demonstrable benefit? > > Actual and measured, not theoretical and based on guesswork? As I understand it, most advertisers maintain a "nuclear ambiguity" about the effectiveness of their activities, making measurements rather difficult to obtain. - Roland From nobody Mon Sep 15 20:04:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32391A0199 for ; Mon, 15 Sep 2014 20:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 TFLZG9VNo2mq for ; Mon, 15 Sep 2014 20:04:51 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ABB1A01D2 for ; Mon, 15 Sep 2014 20:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=bzI24pq47hbnWiTo4HROq9vWX9Wlmgi8CKsyggzr+fw=; b=jD5QPE14Gst2UoQ/DD8f3AgTYiDoe5Ydrh1+cMKP4VNvaZoA6Rufg7gcFyk3hy/4yercD8fPFPHTRUruY7Ci43vLiOxXXtONIBBqHiL0ERgN/So/rVaaqC6uqBgVoZTtyEzlS7eDxhDDNP1IfUfPWhYOA6vs8BrxgPKQxgH7wNU=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=51315 helo=[10.100.1.110]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XTj4P-00023A-BP for dmarc@ietf.org; Tue, 16 Sep 2014 03:04:49 +0000 Message-ID: <5417A8CC.9070204@rolandturner.com> Date: Tue, 16 Sep 2014 11:04:44 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2rDr9riDB1qonV_fCv4_tIm9aO8 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:04:53 -0000 On 09/14/2014 05:59 AM, Steve Atkins wrote: > On Sep 13, 2014, at 10:21 AM, Scott Kitterman wrote: > >>> It's a redefinition of the current meaning of the From: field, and the >>> addition of another header to take the place of the existing From: field. >>> That's bigger than DMARC, and it seems like the 5322 people should be >>> involved in that discussion. >> Rewriting From or adding the new List-foo redefines it? > Yes. > > From 5322: > > The "From:" field specifies the author(s) of the message, > that is, the mailbox(es) of the person(s) or system(s) responsible > for the writing of the message. The "Sender:" field specifies the > mailbox of the agent responsible for the actual transmission of the > message." > > The proposal here is to use the From: field to specify the mailbox > of the agent responsible for the actual transmission of the message > (the mailing list manager); the value that 5322 specifies as the Sender. > That's a significant change to 5322. This is actually pretty easy to fix. As the concern is about authoring lists (those which modify messages rather than merely forward them) it is both technically accurate and real-world-sensible for the From: header to reflect the list as the author of the message. To remove the ambiguity created by the original proposal, the header identifying the poster to the authoring list might instead be called List-Poster: which both correctly expresses the relationship and avoids any confusion about authorship. - Roland From nobody Mon Sep 15 20:09:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341DA1A01F1 for ; Mon, 15 Sep 2014 20:08:55 -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 VIqI7v36tRRv for ; Mon, 15 Sep 2014 20:08:49 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028D91A01E6 for ; Mon, 15 Sep 2014 20:08:47 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so6043457lab.30 for ; Mon, 15 Sep 2014 20:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=84iPlATFCFxGyKsKnceUy8TUnE/PlJgOUACCcj1bA/Y=; b=mzADBPL49y16s+4/0v58NkAKmmyEvVbUfpLgnEnpH3H5FUFQ/XRUac/2nrYXxQh5iV /GKRJLsq74JFBkkBCi29NorCD1vGVZrvR23g59xauXgKqXI0cI1GRmIFO1mRiyN6v0ZN B7eM9ZwqMjLp3zY/3KUNWilSwweeXZSLh+RdmxKH44vxDxeMz8gJYCZiLMLWwBHRtUET WXbegf5fWupesQ5YQAVaUrr8kSzWtg7wPiMbi6o//3yOI+EmIXN+foL/Aki9mx1mLIrj XK8YrxFC1YQT77wvhGnXnw8T4OcgZx7rZhBUw4Vgql2l/r8MzkAu+Ip8uVWylEBUc9bZ meBg== MIME-Version: 1.0 X-Received: by 10.152.7.212 with SMTP id l20mr33121405laa.7.1410836926276; Mon, 15 Sep 2014 20:08:46 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Mon, 15 Sep 2014 20:08:46 -0700 (PDT) In-Reply-To: <20140916002328.94DDC182539@rfc-editor.org> References: <20140916002328.94DDC182539@rfc-editor.org> Date: Mon, 15 Sep 2014 20:08:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c34a0ad3a98305032611b9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vZVFtS7YSrvu7CDnT3VlEivqPx4 Subject: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:08:56 -0000 --001a11c34a0ad3a98305032611b9 Content-Type: text/plain; charset=UTF-8 For later reference when registering enhanced status codes for DMARC. -MSK ---------- Forwarded message ---------- From: Date: Mon, Sep 15, 2014 at 5:23 PM Subject: RFC 7372 on Email Authentication Status Codes To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7372 Title: Email Authentication Status Codes Author: M. Kucherawy Status: Standards Track Stream: IETF Date: September 2014 Mailbox: superuser@gmail.com Pages: 8 Characters: 14224 Updates: RFC 7208 I-D Tag: draft-ietf-appsawg-email-auth-codes-07.txt URL: https://www.rfc-editor.org/rfc/rfc7372.txt This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures. This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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 --001a11c34a0ad3a98305032611b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For later reference when registering enhanced status = codes for DMARC.

-MSK

---------- Forwarded message ----------
From: <rfc-editor@rfc-editor.org>
Date: Mon, Sep 15, 2014 at= 5:23 PM
Subject: RFC 7372 on Email Authentication Status Codes
To: <= a href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, = apps-discuss@ietf.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 7372

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Email Authentication= Status Codes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0M. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0September 2014<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 superuser@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 14224
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates:=C2=A0 =C2=A0 RFC 7208

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-appsawg-email-= auth-codes-07.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.rfc-e= ditor.org/rfc/rfc7372.txt

This document registers code points to allow status codes to be
returned to an email client to indicate that a message is being
rejected or deferred specifically because of email authentication
failures.

This document updates RFC 7208, since some of the code points
registered replace the ones recommended for use in that document.

This document is a product of the Applications Area Working Group Working G= roup of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.=C2=A0 Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.=C2=A0 Distribution of th= is
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



--001a11c34a0ad3a98305032611b9-- From nobody Mon Sep 15 20:43:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748DE1A0270 for ; Mon, 15 Sep 2014 20:43:03 -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 oM8fj0dtwJ_6 for ; Mon, 15 Sep 2014 20:43:02 -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 7C93D1A01A8 for ; Mon, 15 Sep 2014 20:43:02 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8G3grL9006223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 20:42:57 -0700 Message-ID: <5417B1BC.5080601@dcrocker.net> Date: Mon, 15 Sep 2014 20:42:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roland Turner , dcrocker@bbiw.net, Terry Zink , "Murray S. Kucherawy" References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <541783E2.2070002@dcrocker.net> <541799C5.3030800@rolandturner.com> In-Reply-To: <541799C5.3030800@rolandturner.com> 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, 15 Sep 2014 20:42:57 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Hrf0ku9byZ3HPIiJK_zUZmhK2-c Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider 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, 16 Sep 2014 03:43:03 -0000 On 9/15/2014 7:00 PM, Roland Turner wrote: > As I understand it, most advertisers maintain a "nuclear ambiguity" > about the effectiveness of their activities, making measurements rather > difficult to obtain. Every presentation I've seen from usability (human factors, UX, ...) specialist has said the objective research shows very, very poor efficacy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 15 20:51:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467AC1A0277 for ; Mon, 15 Sep 2014 20:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 9n8uZ1kXhb_F for ; Mon, 15 Sep 2014 20:51:10 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921501A0270 for ; Mon, 15 Sep 2014 20:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=diAB171KE4qx/ky9SEyTzJbtqyiXSC2idOly5+o2jTE=; b=FmNEz2EcUbEtQJk0qTBQmI0ot7WByQ9HpDf9otKA3mtNB9IIK45PcLXoIY5ScPGHxaWhxdh4+TDmnmDBUmaTUFm64lQNRGY4y891ZeLOMW3flwEF36cGyiNTbf48cIlM7OOCqKdH6JAt9bNLvr5Lfw5lcaBkYjujPI9z9g0cM3A=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=53122 helo=[10.100.1.110]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XTjn9-000267-TJ; Tue, 16 Sep 2014 03:51:00 +0000 Message-ID: <5417B3A3.2080407@rolandturner.com> Date: Tue, 16 Sep 2014 11:50:59 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dcrocker@bbiw.net, Terry Zink , "Murray S. Kucherawy" References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <541783E2.2070002@dcrocker.net> <541799C5.3030800@rolandturner.com> <5417B1BC.5080601@dcrocker.net> In-Reply-To: <5417B1BC.5080601@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KE6P05eiEejkzwIX-PZvOd9Bw7A Cc: "dmarc@ietf.org" , John Levine , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 03:51:11 -0000 On 09/16/2014 11:42 AM, Dave Crocker wrote: > On 9/15/2014 7:00 PM, Roland Turner wrote: >> As I understand it, most advertisers maintain a "nuclear ambiguity" >> about the effectiveness of their activities, making measurements rather >> difficult to obtain. > > Every presentation I've seen from usability (human factors, UX, ...) > specialist has said the objective research shows very, very poor efficacy. Indirect evidence abounds (we can reasonably infer from CPM pricing that even context-relevant display ads have a value that approaches zero, let alone those that are out of context as in this case), but that isn't what you asked. - Roland From nobody Mon Sep 15 22:18:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B019C1A02BA for ; Mon, 15 Sep 2014 22:17:55 -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 zJpLmb-4GCp9 for ; Mon, 15 Sep 2014 22:17:54 -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 CAE311A02DE for ; Mon, 15 Sep 2014 22:17:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7657D1C390E; Tue, 16 Sep 2014 14:17:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 69DAE1A28C8; Tue, 16 Sep 2014 14:17:42 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <54F9700F-E895-4913-BB2B-1B601909C897@linkedin.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 16 Sep 2014 14:17:42 +0900 Message-ID: <87ppew2lft.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/As0fp2G3018pNsoEEWR81IWzPFo Cc: Franck Martin , "dmarc@ietf.org" , henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:17:56 -0000 Murray S. Kucherawy writes: > better yet, do DKIM verification prior to AV processing. This looks like the best bet to me. Especially if the AV processor charges by the message: perhaps you can reject or approve before submitting to the AV. ;-) From nobody Tue Sep 16 08:10:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740811A0366 for ; Tue, 16 Sep 2014 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG4CbSaiPo9k for ; Tue, 16 Sep 2014 08:09:58 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6711A038E for ; Tue, 16 Sep 2014 08:09:58 -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 56D6A80D0A for ; Tue, 16 Sep 2014 08:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1410880198; bh=CbT9dH3OF4+VwwFjR938/uwyhU/RW6UW7Gm63gUgSUA=; h=Subject:From:In-Reply-To:Date:References:To:From; b=jT/KWcPmdyorh3/rzNadsTUpfHT0oOW9J1JpRfpx/yH3cJj2cNtW3IUkW2yeM9s+e kdckHTjLaDI/2z6fEbW9GvKkhvcQEP+yNgOWYEycCiGIcq8oaLjgFAJWHg6BDGdf8n jN+ER4+I/kl6/5HGHW7luC2RpIt87c0oQo/vp5Vc= 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: <5417A8CC.9070204@rolandturner.com> Date: Tue, 16 Sep 2014 08:09:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AW-3S2cpdnpssDAmADRLa0QUEWM Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 15:10:14 -0000 On Sep 15, 2014, at 8:04 PM, Roland Turner = wrote: > On 09/14/2014 05:59 AM, Steve Atkins wrote: >=20 >> The proposal here is to use the From: field to specify the mailbox >> of the agent responsible for the actual transmission of the message >> (the mailing list manager); the value that 5322 specifies as the = Sender. >> That's a significant change to 5322. >=20 > This is actually pretty easy to fix. As the concern is about authoring = lists (those which modify messages rather than merely forward them) it = is both technically accurate and real-world-sensible for the From: = header to reflect the list as the author of the message. If you wouldn't suggest such a thing unless you were trying to mitigate = DMARC damage then it's probably neither technically accurate nor = real-world-sensible. (And it's not something that I recall anyone = suggesting before April). > To remove the ambiguity created by the original proposal, the header = identifying the poster to the authoring list might instead be called = List-Poster: which both correctly expresses the relationship and avoids = any confusion about authorship. Not an entirely unreasonable line of argument - but it's a significant = change to 5322, so the right forum to propose it is likely somewhere = else. I'd guess it's ietf-smtp, but I'm not entirely sure. Dave? Murray? Cheers, Steve =20= From nobody Tue Sep 16 14:55:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577B71A6F14 for ; Tue, 16 Sep 2014 14:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 3UaJh48am9Lv for ; Tue, 16 Sep 2014 14:55:26 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442321A6F0E for ; Tue, 16 Sep 2014 14:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=jpNlhRR06UjneI5wmgHwf1W4hOT3Ur5KWCAa08RB7Cc=; b=XWLBJX7A9fREtBjL3pOYVv7vnaGXUD5t55D7KXP412rSGLK/2lkIvK0vsI35TK+mk6NGJk6r6vOCsaKWeNGA9TFOM5WJ5rTTtlrSan0/TH1FBWfshnekhqmnWSAy//qxEhHVRN1RjeZ9aFuAdfHGR2ihYDw8EpnEQmK0c4JPTAw=; Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=202.156.168.100; iprev=pass policy.iprev=202.156.168.100 (cm100.gamma168.maxonline.com.sg) Received: from [202.156.168.100] (port=60912 helo=[10.105.1.101]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XU0iZ-0003U6-Dr for dmarc@ietf.org; Tue, 16 Sep 2014 21:55:24 +0000 Message-ID: <5418B1C5.5030604@rolandturner.com> Date: Wed, 17 Sep 2014 05:55:17 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> In-Reply-To: <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> Content-Type: multipart/alternative; boundary="------------080906050607050902030903" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Zom-UofoiiAYPzzckADI0qDdS38 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:55:28 -0000 This is a multi-part message in MIME format. --------------080906050607050902030903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/16/2014 11:09 PM, Steve Atkins wrote: > On Sep 15, 2014, at 8:04 PM, Roland Turner wrote: > >> On 09/14/2014 05:59 AM, Steve Atkins wrote: >> >>> The proposal here is to use the From: field to specify the mailbox >>> of the agent responsible for the actual transmission of the message >>> (the mailing list manager); the value that 5322 specifies as the Sender. >>> That's a significant change to 5322. >> This is actually pretty easy to fix. As the concern is about authoring lists (those which modify messages rather than merely forward them) it is both technically accurate and real-world-sensible for the From: header to reflect the list as the author of the message. > If you wouldn't suggest such a thing unless you were trying to mitigate DMARC damage then it's probably neither technically accurate nor real-world-sensible. (And it's not something that I recall anyone suggesting before April). I would certainly suggest a thing independently of DMARC (thus "both technically accurate and real-world-sensible") and, indeed, can't even claim credit for it: this has come up before in both the DKIM/ADSP discussion and in the origin of the term "authoring list". I am surprised to learn that you were not around for those discussions. > >> To remove the ambiguity created by the original proposal, the header identifying the poster to the authoring list might instead be called List-Poster: which both correctly expresses the relationship and avoids any confusion about authorship. > Not an entirely unreasonable line of argument - but it's a significant change to 5322, so the right forum to propose it is likely somewhere else. I'd guess it's ietf-smtp, but I'm not entirely sure. Dave? Murray? No, it specifically _*preserves*_ RFC 5322 and can therefore be specified independently. - Roland --------------080906050607050902030903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 09/16/2014 11:09 PM, Steve Atkins wrote:

On Sep 15, 2014, at 8:04 PM, Roland Turner <roland@rolandturner.com> wrote:


On 09/14/2014 05:59 AM, Steve Atkins wrote:


The proposal here is to use the From: field to specify the mailbox
of the agent responsible for the actual transmission of the message
(the mailing list manager); the value that 5322 specifies as the Sender.
That's a significant change to 5322.

This is actually pretty easy to fix. As the concern is about authoring lists (those which modify messages rather than merely forward them) it is both technically accurate and real-world-sensible for the From: header to reflect the list as the author of the message.

If you wouldn't suggest such a thing unless you were trying to mitigate DMARC damage then it's probably neither technically accurate nor real-world-sensible. (And it's not something that I recall anyone suggesting before April).

I would certainly suggest a thing independently of DMARC (thus "both technically accurate and real-world-sensible") and, indeed, can't even claim credit for it: this has come up before in both the DKIM/ADSP discussion and in the origin of the term "authoring list". I am surprised to learn that you were not around for those discussions.


To remove the ambiguity created by the original proposal, the header identifying the poster to the authoring list might instead be called List-Poster: which both correctly expresses the relationship and avoids any confusion about authorship.

Not an entirely unreasonable line of argument - but it's a significant change to 5322, so the right forum to propose it is likely somewhere else. I'd guess it's ietf-smtp, but I'm not entirely sure. Dave? Murray?

No, it specifically preserves RFC 5322 and can therefore be specified independently.

- Roland
--------------080906050607050902030903-- From nobody Tue Sep 16 17:56:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5C11A6F63 for ; Tue, 16 Sep 2014 17:56: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 AT1E0jMYCdhl for ; Tue, 16 Sep 2014 17:55: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 038591A6F5A for ; Tue, 16 Sep 2014 17:55:58 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 927901C393B; Wed, 17 Sep 2014 09:55:57 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 83F871A28C8; Wed, 17 Sep 2014 09:55:57 +0900 (JST) From: "Stephen J. Turnbull" To: Roland Turner In-Reply-To: <5418B1C5.5030604@rolandturner.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 17 Sep 2014 09:55:57 +0900 Message-ID: <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mDnhn7dyxKzRe1FaSB_1vxK-y_k Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:56:01 -0000 Roland Turner writes: > I would certainly suggest a thing independently of DMARC (thus "both > technically accurate and real-world-sensible") and, indeed, can't even > claim credit for it: this has come up before in both the DKIM/ADSP > discussion and in the origin of the term "authoring list". I believe that "Mediator" is the currently standardized generic term (RFC 5598), so "mediating list" would be the best such term. For the present discussion, although Mediators are indeed Authors (as defined by RFC 5598), the important specialization is that a Mediator "attempts to preserve the original Author's information in the message it reformulates". Earlier on this list the terms "alias" (non-mediating) and "list" (mediating) were suggested, as well as a few variations on these themes. However, I think those terms are likely to engender confusion in new participants (as would "authoring list"), while I suspect most new participants will immediately "guess" a fairly accurate interpretation of "mediating list". From nobody Wed Sep 17 01:44:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5E1A001C for ; Wed, 17 Sep 2014 01:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fW9jgG2H9StP for ; Wed, 17 Sep 2014 01:43:59 -0700 (PDT) Received: from moi.1and1.com (moi001.1and1.com [212.227.126.208]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06D61A0004 for ; Wed, 17 Sep 2014 01:43:58 -0700 (PDT) Received: from [172.17.11.160] by mri.1and1.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XUAqC-0006av-6r for dmarc@ietf.org; Wed, 17 Sep 2014 10:43:56 +0200 Message-ID: <541949CA.9070108@1und1.de> Date: Wed, 17 Sep 2014 10:43:54 +0200 From: Sven Krohlas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140916002328.94DDC182539@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV@mvs-ha-bs Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QWf2vihD69bOK8-So8RgdFBsR4Y Subject: Re: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 08:44:01 -0000 Hi, On 09/16/14 05:08, Murray S. Kucherawy wrote: > URL: https://www.rfc-editor.org/rfc/rfc7372.txt > > This document registers code points to allow status codes to be > returned to an email client to indicate that a message is being > rejected or deferred specifically because of email authentication > failures. > > This document updates RFC 7208, since some of the code points > registered replace the ones recommended for use in that document. I hope this is not off topic here: RFC 7372 proposes to use a 550 response code for reverse DNS auth failures, see section 3.3. Reverse DNS checks are usually done early in the connection (like IP blocks) in the connection establishment stage of the SMTP dialog. RFC 5321 allows only a 554 error response there, see section 4.3.2. So, shouldn't a 554 code be used here? Or does RFC 5321 need an update? Greetings, -- Sven Krohlas Mailsecurity Agent Mail Application Security From nobody Wed Sep 17 02:11:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175001A0055 for ; Wed, 17 Sep 2014 02:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOHJ3KDKJjch for ; Wed, 17 Sep 2014 02:11:07 -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 A68581A0063 for ; Wed, 17 Sep 2014 02:10:58 -0700 (PDT) Received: (qmail 56301 invoked from network); 17 Sep 2014 09:10:57 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Sep 2014 09:10:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8c1.54195020.k1409; i=johnl@user.iecc.com; bh=Cdgv0WcSOX0JzLLbg4Igd341/PdwStAJHJokVEC6LTc=; b=xIFratj71B4vLqqzMPT8gMlZO4e9lWtQ9q3h80npxgDP2GbEGGlwbR7EyLz+IlSNp1k6v3rl4n3ngmPJERji2AslfazJ19mWZ4SaRshnKqEWq52Y0rprcuEqwBg84veeRuN16KT/kK9/P1Mh+IAYxlWLYfMGNCkZHetu/f4FbItI64LF/j4EPUtRWwB1MJSS5RBqD8q3kw6hdrKmp1x5f2O+oCGKBn4fs8hkcy+yOaEIStZcEdvDTIhBsMKz1o2D DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8c1.54195020.k1409; olt=johnl@user.iecc.com; bh=Cdgv0WcSOX0JzLLbg4Igd341/PdwStAJHJokVEC6LTc=; b=2GcFzWCWWiu7tMskO1C3UIvo0WC2XR6lrjtj8hjVrsx1O8IL5TbGIovP592C4R6GblFHEEbWmrvRf7koSWip7pKZK1CtMZvZP3Re+jr1tawWG9POPECzofwTxEuC2C41dXtIRTH6SY9I/m62ky3P412wMlSCCWK0Gapn/DN5GjcyLQNXhwKdAQdZE+ZFfoStRcLZtRr8oTuWScr/0IcgCd6YI4NJfx+zZugvUt3HY3BbwuzpCKPBTToPl6wpoCmR Date: 17 Sep 2014 09:10:33 -0000 Message-ID: <20140917091033.2240.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5418B1C5.5030604@rolandturner.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2l832CH6mvidnbO3ao2cLCJGKeI Cc: roland@rolandturner.com Subject: Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 09:11:08 -0000 >I would certainly suggest a thing independently of DMARC (thus "both >technically accurate and real-world-sensible") and, indeed, can't even >claim credit for it: this has come up before in both the DKIM/ADSP >discussion and in the origin of the term "authoring list". I am >surprised to learn that you were not around for those discussions. I was. Lists that rewrite the From: line were a bad idea then, and are an equally bad idea now, for reasons that have been discussed to death. If we're just going to beat dead horses here, we can save a lot of time and shut down the WG now. R's, John From nobody Wed Sep 17 06:02:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9C81A030C for ; Wed, 17 Sep 2014 06:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 mY-Vrv5cKzVE for ; Wed, 17 Sep 2014 06:02:22 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 845CF1A02F3 for ; Wed, 17 Sep 2014 06:02:22 -0700 (PDT) Received: from [10.0.1.15] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 9CF63CB52 for ; Wed, 17 Sep 2014 09:02:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <20140917091033.2240.qmail@joyce.lan> Date: Wed, 17 Sep 2014 09:02:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1023491C-AC6E-4F05-8C63-2093878CF264@eudaemon.net> References: <20140917091033.2240.qmail@joyce.lan> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AZrbz0nIrl9FomnCWszfq-gFjrE Subject: [dmarc-ietf] CIVILITY REMINDER - Re: yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 13:02:24 -0000 On Sep 17, 2014, at 5:10 AM, John Levine wrote: >> I would certainly suggest a thing independently of DMARC (thus "both=20= >> technically accurate and real-world-sensible") and, indeed, can't = even=20 >> claim credit for it: this has come up before in both the DKIM/ADSP=20 >> discussion and in the origin of the term "authoring list". I am=20 >> surprised to learn that you were not around for those discussions. >=20 > I was. Lists that rewrite the From: line were a bad idea then, and > are an equally bad idea now, for reasons that have been discussed to > death. >=20 > If we're just going to beat dead horses here, we can save a lot of > time and shut down the WG now. This is a friendly reminder to keep the discussions civil and = respectful. Everyone is free to summarize previous discussions and contrast them = with today's context for the benefit of the WG's chartered work. If = prior discussions are brought up, please take the time to summarize, = contrast with today's context, and make relevant to the WG's work. Last thing - the WG is chartered to perform specific work: https://datatracker.ietf.org/wg/dmarc/charter/ ..and the WG will continue until this work is done. Participation is = entirely voluntary. I'm asking everyone to please treat the volunteers = (including me!) with civility and respect. =3D- Tim 1 of 2 Chairs of this WG From nobody Wed Sep 17 06:43:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359351A0366 for ; Wed, 17 Sep 2014 06:43:18 -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 jOFM3-y3sjHk for ; Wed, 17 Sep 2014 06:43:16 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE3B1A01CB for ; Wed, 17 Sep 2014 06:43:16 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ge10so1897766lab.12 for ; Wed, 17 Sep 2014 06:43:14 -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=eg3gamFzGc49rg3M65Etmv3ANpasyVrYCyUPYgVdO4w=; b=pKaL5PTeA5jfO2dy3Is7Lm/p14GXxZDdqVcZlYK/7F5VGSwRHB2yoajbxOKKxd4ij9 QR7GK68oF2Bx7yOXYEQJNGGyYr4oOcs+pvBdlvFROBrbCmvv1HC956v96sZL0GqY1ncD NZ/la66wvLERYIbfF5DTw9mqvA1DrZ0d48Faw+k9P3pHDDcSlDfM1bA0fwZ0xLHP76ey 1ffpkTvQiRquQm2OJdArCBNJNvAuC3VqzSPCcsujVQAKiKOEjRQuFEGuHqmagCBaUJdP Zi3ECsUw+fDiXHCVC1G1LG83D/hA7hWDxaOYg/f1xgkpLnYQwGIeTfRcZyaVrNAE0c3r tOPQ== MIME-Version: 1.0 X-Received: by 10.152.206.35 with SMTP id ll3mr3623436lac.88.1410961393456; Wed, 17 Sep 2014 06:43:13 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Wed, 17 Sep 2014 06:43:13 -0700 (PDT) In-Reply-To: <541949CA.9070108@1und1.de> References: <20140916002328.94DDC182539@rfc-editor.org> <541949CA.9070108@1und1.de> Date: Wed, 17 Sep 2014 06:43:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sven Krohlas Content-Type: multipart/alternative; boundary=001a11348914a618c30503430cf0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MI_1n7WS5pWh1T1SLs3534WOmfs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 13:43:18 -0000 --001a11348914a618c30503430cf0 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 17, 2014 at 1:43 AM, Sven Krohlas wrote: > RFC 7372 proposes to use a 550 response code for reverse DNS auth > failures, see section 3.3. > > Reverse DNS checks are usually done early in the connection (like IP > blocks) in the connection establishment stage of the SMTP dialog. > > RFC 5321 allows only a 554 error response there, see section 4.3.2. > > So, shouldn't a 554 code be used here? Or does RFC 5321 need an update? > The definitions in 5321 are: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") 550 seems right to me. It's a rejection for policy reasons, not a general transaction failure or the total absence of SMTP service. -MSK --001a11348914a618c30503430cf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 17, 2014 at 1:43 AM, Sven Krohlas <sven.k= rohlas@1und1.de> wrote:

<= br> RFC 7372 proposes to use a 550 response code for reverse DNS auth
failures, see section 3.3.

Reverse DNS checks are usually done early in the connection (like IP
blocks) in the connection establishment stage of the SMTP dialog.

RFC 5321 allows only a 554 error response there, see section 4.3.2.

So, shouldn't a 554 code be used here? Or does RFC 5321 need an update?=

The definitions in 5321 are:

550 Requested action not taken: mailbox unavailable (e.g.= , mailbox not found, no access, or command rejected for policy reasons) 
   554  Transaction failed (Or, in the case of a conn=
ection-opening
      response, "No SMTP service here")

550 seems right to me.=C2=A0 It's a rejection for = policy reasons, not a general transaction failure or the total absence of S= MTP service.

-MSK
--001a11348914a618c30503430cf0-- From nobody Wed Sep 17 11:08:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8421A0ACA for ; Wed, 17 Sep 2014 11:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsbeSrowzCmI for ; Wed, 17 Sep 2014 11:08:21 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9171A071C for ; Wed, 17 Sep 2014 11:07:47 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z12so1199924lbi.8 for ; Wed, 17 Sep 2014 11:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OeFgc4Qj5iJzdqoCAY6sy7QG3cyS2dKGCyCi9PHLSjA=; b=eIuX6hX81kxHTOuE5AEp94obaGFYzb0yDE8Q0RbmDebgUjapit/eQ0Xp+hlYjXozPQ woJOD7Ta7kNHc1a6jiQfI4ypIpUX9c0Vedut54mAC/64YATXnTkmZ5daMzmRZQUQ4Lo4 o0GWCi4zJGsgHuFpqkmRZNZ497Z4IBWKj30V5DmmS9dpatmW0xcRpNfZ0UiSLcxQ45hS GahTg4WnqFR6uXvmLaueKMzlGjCngjYuithUXs7KytWGebVnw6aazqaXtWUXjDRQ1gWH JkEHb1/QRgnMH+Id7DvTk+K7lfGheV3bdX09T4nayaPrwezObVFu01JM4ajpuCmL/b4c /wwg== MIME-Version: 1.0 X-Received: by 10.112.34.78 with SMTP id x14mr43751123lbi.38.1410977265684; Wed, 17 Sep 2014 11:07:45 -0700 (PDT) Received: by 10.25.211.7 with HTTP; Wed, 17 Sep 2014 11:07:45 -0700 (PDT) Date: Wed, 17 Sep 2014 11:07:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5554fb2b51571050346beb4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5B9k-waPPJz5Ww4AzdcqJj1Onp4 Subject: [dmarc-ietf] draft-kucherawy-dmarc-base haircut X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:08:36 -0000 --bcaec5554fb2b51571050346beb4 Content-Type: text/plain; charset=UTF-8 Colleagues, As you know, the DMARC base draft is being processed via the Independent Stream. Procedurally it's ready to move forward toward publication, with the caveat that the prose in it needs a serious haircut. (There is also the option to split the document before publishing it, but I don't think we're going to go that route.) I'm in the process of doing a pass through it to get rid of prose we don't really need, or be less verbose in other areas, etc., to give it the trimming it needs. If anyone has any suggestions or would like to help with this work, please let me know privately. Note that absolutely no technical additions, changes, or deletions will be entertained. This is just about the descriptive text and maybe the examples, or anything we can rework or remove to lean the document without touching the technology. Technical changes are a potential later work item for this working group. Thanks, -MSK --bcaec5554fb2b51571050346beb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

As you know, = the DMARC base draft is being processed via the Independent Stream.=C2=A0 P= rocedurally it's ready to move forward toward publication, with the cav= eat that the prose in it needs a serious haircut.=C2=A0 (There is also the = option to split the document before publishing it, but I don't think we= 're going to go that route.)

I'm in the process of doi= ng a pass through it to get rid of prose we don't really need, or be le= ss verbose in other areas, etc., to give it the trimming it needs.=C2=A0 If= anyone has any suggestions or would like to help with this work, please le= t me know privately.

Note that absolutely no technical additio= ns, changes, or deletions will be entertained.=C2=A0 This is just about the= descriptive text and maybe the examples, or anything we can rework or remo= ve to lean the document without touching the technology.=C2=A0 Technical ch= anges are a potential later work item for this working group.

Thanks= ,
-MSK
--bcaec5554fb2b51571050346beb4-- From nobody Wed Sep 17 13:05:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2448B1A03CC for ; Wed, 17 Sep 2014 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 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_16=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 FAGDUBZr-TWQ for ; Wed, 17 Sep 2014 13:05:26 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id B84101A0AE3 for ; Wed, 17 Sep 2014 13:05:26 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3hysjx4Jwgz1L8f4; Wed, 17 Sep 2014 22:05:25 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3hysjx2xvyz1L8f3; Wed, 17 Sep 2014 22:05:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id ED9981233B0; Wed, 17 Sep 2014 22:05:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bYClHZ9YzQZl; Wed, 17 Sep 2014 22:05:15 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id D1304123341; Wed, 17 Sep 2014 22:05:14 +0200 (CEST) Message-ID: <5419E979.70705@sonnection.nl> Date: Wed, 17 Sep 2014 22:05:13 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1410984325; bh=HriQNUQns4SZfJncp4ODe1LqKvogiXOehOrnksvM6H0=; h=Message-ID:Date:From:To:Subject:From; b=a6osgDy3OQuyx0Q4SiY3ZfKhVwec0CgsOE2AbzAy1Nc/MzUeSMsKvnStI9qsJ71es yc11k7Q1ZmRKItlwesFrqcWeJ79z4koXscJiPT0gImCJhiI1ezm9lyuxs/YO/ikrEN cvmuFD90KdUz3mrRU4TjSho7bpPxpMKlh7t+lusE= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3hysjx4Jwgz1L8f4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SjSttBvs0DKzSjxF5VADk8NvAPE Cc: john.kelley@teamaol.com, henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:05:29 -0000 All, On 09/15/2014 07:39 PM, Henrik Schack wrote: > In Denmark we have a somewhat large (10K+ domains) anti-virus/spam > provider breaking DKIM signatures. > They break DKIM signatures on incoming email by adding a "Virus > scanned by xxxx" line to the body of the email. > > Not sure how to fix this, but perhaps some day they'll get tired of my > bi-monthly calls and emails complaining about how they do things. it's nice to see how many respondents in this thread gave all sorts of advise to Henrik how to deal with a problem, which basically cannot solved by him because it is caused by some 3rd party (modifying the body of a mail for adv. purposes). I interpreted Henrik's mail as a followup to the thread that John Kelly started, titled 'Indirect mail flows'. In my view both John and Henrik tried to make (a start of) an inventory of all sorts of real-life situations that potentially can break DKIM signatures or more in general: cause DMARC failures for legitimate mail flows where sending DMARC policy is p=reject. And before starting the discussion about possible solutions it may be better to first 'complete' [1] this inventory. /rolf [1] the inventory will never be 100% complete, of course. From nobody Wed Sep 17 13:39:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF411A6F0E for ; Wed, 17 Sep 2014 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.18 X-Spam-Level: X-Spam-Status: No, score=-101.18 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 gO1nySwHxje9 for ; Wed, 17 Sep 2014 13:39:10 -0700 (PDT) Received: from ftp.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 60FAB1A6F04 for ; Wed, 17 Sep 2014 13:39:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2195; t=1410986344; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=k28guV85w0t8HCc4AT4h0r5lulM=; b=kE3feJEPRm6F7Qw+OrBu qnemLOpf57h0ibBLQuXd22GhYOTE57bBxOTOZvUcOpE5BaONjv3JVdAZsDXibV4H yor8tPFMSmdOo24DvNmF+rkXZoLrf8EIXa23fH7UpWXkZnn7cOm7sifzXr/3wUTA khFVuQhTlrcW+xS9GmKuTzs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 17 Sep 2014 16:39:04 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1876433022.5039.5032; Wed, 17 Sep 2014 16:39:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2195; t=1410985999; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QI7s7XK v+uLOxJH0cIqBzUT7G3D+IQx4imr73rSB8fM=; b=LhsYuOiDmnpcjfAxHBNBRsX V9n7iUS8j5fFYchxJ8F9rOUJRkfH04TDUxE7pL/lcA5EzVV9367TbpIQsVHf8bS1 qscDlwOQ4g5+4/c3Hbg6BF6MzfDphQO7H4/PphYK29mtfoXCjmdv1MBPsKNHE3zP HNeOiL5sxXRwl45n4EaM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 17 Sep 2014 16:33:19 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 468879344.9.3476; Wed, 17 Sep 2014 16:33:18 -0400 Message-ID: <5419F168.6010702@isdg.net> Date: Wed, 17 Sep 2014 16:39:04 -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: Terry Zink , "dcrocker@bbiw.net" , "Murray S. Kucherawy" References: <20140915211615.2774.qmail@joyce.lan> <4c04e1fa52174dc08b717b68bb3a5524@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <4634fc4c6a16478ca725a79b67af1f5e@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <541783E2.2070002@dcrocker.net> <7db8f6390072485fbc1139deb3d6e7bd@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <7db8f6390072485fbc1139deb3d6e7bd@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CnI_g-rVGeWhI8FrmBNLFxl0u90 Cc: "dmarc@ietf.org" , "henrik@schack.dk" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:39:13 -0000 I recall during a few decades ago when there was stripping wars among mail packages which began to add/strip/replace the other guys tag/tear/brag lines and vice-versa. The MUA (mail reader/writer) had the ultimate last say on the matter. So a server side script to process the mail after the AV processor has touched it could do the same thing (strip the AV brag line). Of course, this would start Stripping Wars II. Of course the right way is to check the local country electronic mail tampering laws and send a letter to their chief council about tampering with mail. Since they are not the copyright owner of the message, they could be violating copyright and mail tampering laws by changing the display and security integrity of the message. This could provide legal argument for the STRIPPING ACTION (because they never own the mail in the first place). -- HLS On 9/15/2014 8:59 PM, Terry Zink wrote: > I'm not saying I agree that an A/V company is right to put their tagline into the message, especially if it breaks DKIM. If I owned an A/V company, I wouldn't do it [1]. > > However, I understand why A/V companies would do it - it (presumably) helps drive revenue because it increases visibility in a way that putting it into a header does not. > > -- Terry > > [1] This is easy for me to say because I don't own an A/V company and my revenue stream does not depend on it. > > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Monday, September 15, 2014 5:27 PM > To: Terry Zink; Murray S. Kucherawy > Cc: dmarc@ietf.org; John Levine; henrik@schack.dk > Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider > > On 9/15/2014 5:26 PM, Terry Zink wrote: >> Having the "Virus scanned by xxx" ***in a header*** defeats the purpose >> of advertising since most clients won't display it. A/V filters put >> those taglines in there to advertise, not just to tell the mail client >> that their mail has been scanned. > > > And having it displayed achieves what demonstrable benefit? > > Actual and measured, not theoretical and based on guesswork? > > d/ > From nobody Wed Sep 17 13:51:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51411A0047 for ; Wed, 17 Sep 2014 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 VFmTcm2oIaqA for ; Wed, 17 Sep 2014 13:51:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BABB1A6F1D for ; Wed, 17 Sep 2014 13:51:07 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCOXIWZQ5C004CWM@mauve.mrochek.com> for dmarc@ietf.org; Wed, 17 Sep 2014 13:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1410986774; bh=oDFeXMRgh7iBijsXDoIs61IJ6EbCfWB903K8IM7TzAg=; h=From:Cc:Date:Subject:In-reply-to:Reply-to:References:To; b=BrsTTG7uv0V84hRgzHH4zqOlq2h0arcJnTGYn+MoueO+6lqlQpoN1T3LVVzXtko23 xRSojVCK7X3saJGmocLF5UU7IkBMrRfW4ZLjFo/79Jbz9ATshNkBUT9HF1gCRFqWpW ddb2oRmGqV/6nFmfS4KO7CDP41EZmP5PNYsIePo0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCOWTDV5VK002WQY@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 17 Sep 2014 13:46:00 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PCOXIV3WWK002WQY@mauve.mrochek.com> Date: Wed, 17 Sep 2014 13:41:30 -0700 (PDT) In-reply-to: "Your message dated Wed, 17 Sep 2014 10:43:54 +0200" <541949CA.9070108@1und1.de> References: <20140916002328.94DDC182539@rfc-editor.org> <541949CA.9070108@1und1.de> To: Sven Krohlas Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Bfv1_uM8guRH5CC5Ag55uvCRZEQ Cc: dmarc@ietf.org, ietf-smtp@ietf.org Subject: Re: [dmarc-ietf] Fwd: RFC 7372 on Email Authentication Status Codes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf-smtp@ietf.org List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:51:08 -0000 > Hi, > On 09/16/14 05:08, Murray S. Kucherawy wrote: > > URL: https://www.rfc-editor.org/rfc/rfc7372.txt > > > > This document registers code points to allow status codes to be > > returned to an email client to indicate that a message is being > > rejected or deferred specifically because of email authentication > > failures. > > > > This document updates RFC 7208, since some of the code points > > registered replace the ones recommended for use in that document. > I hope this is not off topic here: (chair hat on) It is. I've cc'ed and directed replies to the ietf-smtp list, where this sort of discussion belongs. (chair hat off) > RFC 7372 proposes to use a 550 response code for reverse DNS auth > failures, see section 3.3. Correct. > Reverse DNS checks are usually done early in the connection (like IP > blocks) in the connection establishment stage of the SMTP dialog. > RFC 5321 allows only a 554 error response there, see section 4.3.2. You're misreading RFC 5321. Nowhere does it say that its lists of possible responses are exhaustive. So it is perfectly permissible for RFC 7372 to specify additional possible responses as long as they fit into the overal theory of reply codes. This sort of thing has been done many times. > So, shouldn't a 554 code be used here? Or does RFC 5321 need an update? Neither. See above. Ned From nobody Wed Sep 17 22:12:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CD51A01E0 for ; Wed, 17 Sep 2014 22:12:27 -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 wdgK-B7IL0fd for ; Wed, 17 Sep 2014 22:12:26 -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 E064A1A0680 for ; Wed, 17 Sep 2014 22:12:25 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6AEF51C39FF; Thu, 18 Sep 2014 14:12:24 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5EDC01A28C8; Thu, 18 Sep 2014 14:12:24 +0900 (JST) From: "Stephen J. Turnbull" To: R.E.Sonneveld@sonnection.nl In-Reply-To: <5419E979.70705@sonnection.nl> References: <5419E979.70705@sonnection.nl> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 18 Sep 2014 14:12:24 +0900 Message-ID: <87fvfp1phj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3BZNtWw9X7deaYipSdcoGDX3Ir8 Cc: john.kelley@teamaol.com, dmarc@ietf.org, henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 05:12:28 -0000 Rolf E. Sonneveld writes: > started, titled 'Indirect mail flows'. In my view both John and Henrik > tried to make (a start of) an inventory of all sorts of real-life > situations that potentially can break DKIM signatures or more in > general: cause DMARC failures for legitimate mail flows where sending > DMARC policy is p=reject. IMO, the place to record the inventory is the wiki. Mailing lists are not a good place to keep such records. > And before starting the discussion about possible solutions it may be > better to first 'complete' [1] this inventory. The suggested solutions, if they can be implemented without standardizing additional protocols, are useful fodder for the proposed BCP, which I think is on-topic at the moment. I suppose they might also be added to the wiki on a separate page or as footnotes, or something. So the discussions are useful IMO. I hope Somebody[tm] is adding such ideas to the wiki. One of these days[tm] I'll do a run through the list archives for that purpose, but I don't claim a patent on that idea! Steve From nobody Wed Sep 17 22:33:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890651A6F68 for ; Wed, 17 Sep 2014 22:33:10 -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 wJT17ClSoiR6 for ; Wed, 17 Sep 2014 22:33:09 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884041A6F63 for ; Wed, 17 Sep 2014 22:33:09 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn15so1481475igb.3 for ; Wed, 17 Sep 2014 22:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L1975yTyPHRO7w1RAsAWf7GWxt4AeSFjjydZ+YyWYY8=; b=pOHbs7USgAQkiUN5gJ9/B3gpYX/5kTutt3O8asxqhqII5Y6DXotcmvinwMGBRdZRzU J5VvrmRORdiU7hK/fwwxTrX4PFkBgPA00uHh/jiRiWT98I+1kmTfxsW9qkjA/A1fIck2 p0HHx0qiRWKy6KassNi4rBaLMnug44hQZb+QmCwe0NjD1HlJ1bpvTSQM33wMDkd6lUyY yWnaYpgajF6LGFHMoszUuCgQpispSfwRi0B2lSEH0l5bai55JVue+EY8jxs3JyoW2nho pHuD02Cl3Sem+N2/At0B/N1JfCkPtfS6mdEBo+BKtgFVWROVbtwIdvTxVY9A5CiRKYTe lUoA== MIME-Version: 1.0 X-Received: by 10.50.164.167 with SMTP id yr7mr44126876igb.37.1411018388815; Wed, 17 Sep 2014 22:33:08 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Wed, 17 Sep 2014 22:33:08 -0700 (PDT) In-Reply-To: <5419E979.70705@sonnection.nl> References: <5419E979.70705@sonnection.nl> Date: Thu, 18 Sep 2014 07:33:08 +0200 Message-ID: From: Henrik Schack To: R.E.Sonneveld@sonnection.nl Content-Type: multipart/alternative; boundary=089e0122a7fcd64c4c0503505182 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/alqM_AjhU4nP6w6XZbpc18G0RBE Cc: john.kelley@teamaol.com, "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrik@schack.dk List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 05:33:10 -0000 --089e0122a7fcd64c4c0503505182 Content-Type: text/plain; charset=UTF-8 > > >it's nice to see how many respondents in this thread gave all sorts of > advise to Henrik how to deal with a problem, which basically cannot solved > by him because it is caused by some 3rd party (modifying the body of a mail > for adv. purposes). > > > >I interpreted Henrik's mail as a followup to the thread that John Kelly > started, titled 'Indirect mail flows'. In my view both John and Henrik > tried to make (a start of) an inventory of all sorts of real-life > situations that potentially can break DKIM signatures or more in general: > cause DMARC failures for legitimate mail flows where sending DMARC >policy > is p=reject. > > That's right, that was my original intention. /Henrik --089e0122a7fcd64c4c0503505182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>it's nice to see how many respondents in= this thread gave all sorts of advise to Henrik how to deal with a problem,= which basically cannot solved by him because it is caused by some 3rd part= y (modifying the body of a mail for adv. purposes).
>
>I interpreted Henrik's mail as a followup to the thread tha= t John Kelly started, titled 'Indirect mail flows'. In my view both= John and Henrik tried to make (a start of) an inventory of all sorts of re= al-life situations that potentially can break DKIM signatures or more in ge= neral: cause DMARC failures for legitimate mail flows where sending DMARC &= gt;policy is p=3Dreject.

That's right, that was my original intention.

/Henrik=C2=A0
--089e0122a7fcd64c4c0503505182-- From nobody Wed Sep 17 22:35:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4091D1A7000 for ; Wed, 17 Sep 2014 22:35: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 lCptMkyO92SW for ; Wed, 17 Sep 2014 22:35:22 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468F51A6FFF for ; Wed, 17 Sep 2014 22:35:22 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id r10so124797igi.5 for ; Wed, 17 Sep 2014 22:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=f4APgRNBE+G54KmHr+PX+TPjHMsuCoqaYprqbXvmUEc=; b=SJv340VWWgK2ZgWAghKLQcz0wNAJ5jla47UV0x+QpX/NK/eW+KHNbM3riu8bPqDjSx pqZ1YECAtHI9AuTgCjtjXvsijbSeL4XYwI5vSll7m43ainUMlo+MJkGApWN3f7vt2dcj KDm5cDLK/iilXXXp10EhOXGJzi21vbNBZFBBVwyJJ6+KyLxh3KbiFaN3kNWOFR8dPrOf v7II6nbK0qT6gyc8BGdEtUMSqBBd63aytXtO8wUXLMdnfHLJ+Ek3yy/P2leNdZuam+xd RPve3DiPsde90x86/+vo7QjaHCf3mF91mTv1GbVyZfNuz/cKhprzMisTDnKUgjNPx3X+ Ze6Q== MIME-Version: 1.0 X-Received: by 10.43.129.138 with SMTP id hi10mr106234icc.73.1411018521612; Wed, 17 Sep 2014 22:35:21 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Wed, 17 Sep 2014 22:35:21 -0700 (PDT) In-Reply-To: <87fvfp1phj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5419E979.70705@sonnection.nl> <87fvfp1phj.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 18 Sep 2014 07:35:21 +0200 Message-ID: From: Henrik Schack To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=001a11c1df2cc09afc05035059f3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QbF5yyE0LBVu4J6TkPgQr1kcg0c Cc: R.E.Sonneveld@sonnection.nl, john.kelley@teamaol.com, "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrik@schack.dk List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 05:35:51 -0000 --001a11c1df2cc09afc05035059f3 Content-Type: text/plain; charset=UTF-8 > > > >IMO, the place to record the inventory is the wiki. Mailing lists are > >not a good place to keep such records. > I would love to add it to the Wiki, unfortunately the Wiki signup features > seems to be broken, wont accept any of my email addresses. > And the person responsible does not respond when asking for help. /Henrik --001a11c1df2cc09afc05035059f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>IMO, the place to record the inventory is the wiki.=C2=A0 Mailin= g lists are
>not a good place to keep such records.
I would love to add it to the Wiki, unfortunately the Wiki= signup features seems to be broken, wont accept any of my email addresses.=
And the person responsible does not respond wh= en asking for help.

/Henrik=C2=A0
--001a11c1df2cc09afc05035059f3-- From nobody Wed Sep 17 22:38:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B211A0385 for ; Wed, 17 Sep 2014 22:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, 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 rEs09Peh7Kgq for ; Wed, 17 Sep 2014 22:38:30 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D3D1A6F82 for ; Wed, 17 Sep 2014 22:38:30 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k14so312352wgh.24 for ; Wed, 17 Sep 2014 22:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Z7xNUUlqqRhApwEsi8M6hlRuxNfmMQX40ANesY0g1ZQ=; b=ZTKhc8N1hcs2ZVAPMgsNt3ueui5MajVczTiNarLVpyUFc7INAe2NHG/OozziGY2M3w pOljr4V5ZdQUWE5O6+Ap1xVaKDYZi9jYE7K8pCTz1TD/xdHtl3+h819CPfMydhryd6/M PDp/xAtACphVX/BZj4hoKu6SqQEr+ETfhbVPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z7xNUUlqqRhApwEsi8M6hlRuxNfmMQX40ANesY0g1ZQ=; b=dLHJP1v90/2/tB77I90HK31pO3B3l2JzFv7G+rFQoPiolqGffMVk2dzOdLThw6Hbqt c0KLieoUlHcc95o/O1oq6bgM5iekCLteEbqvQmuXC44nBdxY4ZtqFF8H15fDk5aL3U9O jSWws9mzhMM2bH8zLlwR8Pl+TVHwUncyw4mgbOSz+3fk4DZEsNCZyHMlXUQ5sxQv21kt VA4xKF3FsXjZkACekv3vmjNMS3HnUN5cECpKU2DVs2spalj5FRCX/+4Ccuh5czm/2gfK FXfma1kGiSdnZ0UwjhwubZM7O+h3zrOAxUZUMquxZI0Rd7J64exTp18IkjRaS9R+EhM7 M8xQ== X-Gm-Message-State: ALoCoQnvG1XGh1C7zVYaR69Og3rI8wFifTpzyb8FBOqm6v8UhIL3k9d3r5ST6Vxu8o5Gur0v2ybf MIME-Version: 1.0 X-Received: by 10.195.17.170 with SMTP id gf10mr1754418wjd.111.1411018708882; Wed, 17 Sep 2014 22:38:28 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.237.133 with HTTP; Wed, 17 Sep 2014 22:38:28 -0700 (PDT) In-Reply-To: References: <5419E979.70705@sonnection.nl> Date: Wed, 17 Sep 2014 22:38:28 -0700 X-Google-Sender-Auth: HTGj1f5fEb-hi8KaMkrTfZ-tpOA Message-ID: From: Kurt Andersen To: henrik@schack.dk Content-Type: multipart/alternative; boundary=089e016817dcea298305035064c3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hZwkpD-Ksi3ZIMVKGYPRedBqV4k Cc: R.E.Sonneveld@sonnection.nl, john.kelley@teamaol.com, "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 05:38:31 -0000 --089e016817dcea298305035064c3 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 17, 2014 at 10:33 PM, Henrik Schack wrote: > > >it's nice to see how many respondents in this thread gave all sorts of >> advise to Henrik how to deal with a problem, which basically cannot solved >> by him because it is caused by some 3rd party (modifying the body of a mail >> for adv. purposes). >> > >> >I interpreted Henrik's mail as a followup to the thread that John Kelly >> started, titled 'Indirect mail flows'. In my view both John and Henrik >> tried to make (a start of) an inventory of all sorts of real-life >> situations that potentially can break DKIM signatures or more in general: >> cause DMARC failures for legitimate mail flows where sending DMARC >policy >> is p=reject. > > IMO, DMARC and the policy assertions made thereby is entirely beside the point here - does nobody care that mail authentication signatures (DKIM in other words) is being willfully damaged by clueless vendors? Invalid DKIM signatures may not be a "negative" reputation factor, but they certainly aren't a positive one either. . ."would all interested volunteers please step forward" :-) --Kurt --089e016817dcea298305035064c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 17, 2014 at 10:33 PM, Henrik Schack <h= enrik.schack@gmail.com> wrote:
=
=

=
>it's nice to see how many respondent= s in this thread gave all sorts of advise to Henrik how to deal with a prob= lem, which basically cannot solved by him because it is caused by some 3rd = party (modifying the body of a mail for adv. purposes).
>
>I interpreted Henrik's mail as a followup to the thread tha= t John Kelly started, titled 'Indirect mail flows'. In my view both= John and Henrik tried to make (a start of) an inventory of all sorts of re= al-life situations that potentially can break DKIM signatures or more in ge= neral: cause DMARC failures for legitimate mail flows where sending DMARC &= gt;policy is p=3Dreject.
=

IMO, DMARC and the policy assertions made thereby is en= tirely beside the point here - does nobody care that mail authentication si= gnatures (DKIM in other words) is being willfully damaged by clueless vendo= rs?

Invalid DKIM signatures may not be a "negative&= quot; reputation factor, but they certainly aren't a positive one eithe= r. . ."would all interested volunteers please step forward" :-)
--Kurt
--089e016817dcea298305035064c3-- From nobody Thu Sep 18 01:42:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0900F1A6FBB for ; Thu, 18 Sep 2014 01:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_3uHhTquD0k for ; Thu, 18 Sep 2014 01:42:08 -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 CEDF41A0402 for ; Thu, 18 Sep 2014 01:42:07 -0700 (PDT) Received: (qmail 29970 invoked from network); 18 Sep 2014 08:42:06 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 18 Sep 2014 08:42:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9bf.541a9ae1.k1409; i=johnl@user.iecc.com; bh=Q2lJbDfSi8dEExEc47ZULVVpNuQk9iT++4m68J1oGyw=; b=fqSVd7OJrN7yxox8aEzi396Q9nY01l/6GIKoBw/Bxzu50AVdCUtu0M3oYE1HHYb/ZddzqLm42XvWAXAdLUe7N70oEpvdcmkQM5bcEE1tkiJ1sC87RnDePGceEJn0hZ8AD/Vm81M3kqsIM7S09tPvqRwj+L636Tw+fqDVCRVlxaCvHYmInegproe+IxSdHUpdPTetxRwtJVvEDCzu9KgyWeQVofpDpIER5fnEdtPZvukcVGsV9tnR8nzMJKqgR/5z DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9bf.541a9ae1.k1409; olt=johnl@user.iecc.com; bh=Q2lJbDfSi8dEExEc47ZULVVpNuQk9iT++4m68J1oGyw=; b=llQVHXp9sCgFxRfsq8AapqMo2VAPQDZxePgnQQrayOloKicEID5OXNeCL8nESYxfGjYhwmjK2JjmY7EDZu8z2/5ZV6QSXnU/rCNkCxhb/yM4H3QD4XML0ZFkpF7OjiRuc/MB+VHEiEu5cTj8ijIcwFBjfH19+tI9n8ApaJM3SL6Ifkn+S8UytIDhbRIzoPgXXyPFdR9bPOge8oFlir+HXLkLyy4BGRUfmaOS44vODIhWsPs2U19923VqxAhbLE+H Date: 18 Sep 2014 08:41:47 -0000 Message-ID: <20140918084147.2494.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p-5waL_OAmsS4YNuJrOQrWr90QU Cc: henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 08:42:09 -0000 I've added an indirect mail flow page to the ASRG wiki. If you don't have a password to log in and edit, write to me and I'll give you one. >> >IMO, the place to record the inventory is the wiki. Mailing lists are >> >not a good place to keep such records. >> I would love to add it to the Wiki, unfortunately the Wiki signup features >> seems to be broken, wont accept any of my email addresses. >> >And the person responsible does not respond when asking for help. If you're referring to the ASRG wiki, the person responsible for it is me. I am unaware of any signup problems, and there are multiple people contributing to it. Feel free to contact me directly for help. R's, John From nobody Thu Sep 18 04:30:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63921A873D for ; Thu, 18 Sep 2014 04:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.909 X-Spam-Level: ** X-Spam-Status: No, score=2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MANGLED_SPAM=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOZM-qBG11d3 for ; Thu, 18 Sep 2014 04:30: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 C7D351A014D for ; Thu, 18 Sep 2014 04:30:31 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 80A9B1C396B; Thu, 18 Sep 2014 20:30:29 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 752ED1A28C8; Thu, 18 Sep 2014 20:30:29 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140918084147.2494.qmail@joyce.lan> References: <20140918084147.2494.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 18 Sep 2014 20:30:29 +0900 Message-ID: <877g1117ze.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BOZMCvrBoIJz-0aV2kD1z2OfXGs Cc: dmarc@ietf.org, henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:30:34 -0000 John Levine writes: > If you're referring to the ASRG wiki, the person responsible for it is > me. I am unaware of any signup problems, and there are multiple > people contributing to it. I'm not sure what ASRG refers to, perhaps http://wiki.asrg.sp.am/? I was referring to http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Sorry for not providing the URL in the first place. From nobody Thu Sep 18 04:40:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3541A01FF for ; Thu, 18 Sep 2014 04:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 E2VGuhOosMs8 for ; Thu, 18 Sep 2014 04:39:59 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E881A0166 for ; Thu, 18 Sep 2014 04:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=WqBjXjru1pT9tuNagCJqMiGTEwOxNc2GqXt8a6+nAwM=; b=H8nRnfvBwhZRVTA/gNusumIp4sFBkwis3Ku2PtQcbupHLIq8jxCSn9YPOZ0DIuc3dYOWh8k2oEdh1Z4LLK43Azw5ZzfYeQ9kZqFiad62XYWzcUTUEgC/8i8hFnkafj5XO5MZk5xv3Dmcl/n40apN0r7pg/lceIMfFMGvLl0DViY=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=49.128.61.72 Received: from [49.128.61.72] (port=56134 helo=[192.168.6.52]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XUa41-0006X1-0H; Thu, 18 Sep 2014 11:39:55 +0000 Message-ID: <541AC488.5040607@rolandturner.com> Date: Thu, 18 Sep 2014 19:39:52 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "Stephen J. Turnbull" , John Levine References: <20140918084147.2494.qmail@joyce.lan> <877g1117ze.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <877g1117ze.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/x56QNv1dhAh1jX8LY5Xx70MKeNc Cc: dmarc@ietf.org, henrik@schack.dk Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:40:00 -0000 On 09/18/2014 07:30 PM, Stephen J. Turnbull wrote: > I was referring to > > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki > I had no trouble working through the automated sign-up. What trouble (error message?) are you having with your email address(es)? - Roland From nobody Thu Sep 18 05:30:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF0E1A8788 for ; Thu, 18 Sep 2014 05:30: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 G5mrbDJh1uPA for ; Thu, 18 Sep 2014 05:30:50 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0EE1A8755 for ; Thu, 18 Sep 2014 05:30:49 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id a13so1269874igq.1 for ; Thu, 18 Sep 2014 05:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I9ovfbsKHBRGSL/YqeNM78bZIIqBe+IDdhM1b7+96jA=; b=x0WZk6hbz0p2g0v3Ml4170Dig5ACT0RvcMoMiHkwpGLRIdNzQsMXiFDurV7rX5W8F7 wSZlLiAdjbLoUBQWXnp8Pkk4jd0c5xy/Ik4c4ZVA5SWx+J5OmNuIPia7vdjBtb3H6CIT aTCvWNRrP9RDrb6kTQruIADlv+kaEYi742ItoOZR3C6fRMdNn69PEA4V070pkPextAKa 6r4BkCsbXFS2vhrk3uqkn0xmrM+dtVBEX7IW2kuwR+6LYbNh3LSIwLKA0eVZa0TgS2eC wgPpdv3dG48nkLDwIb8Y3rcqa+s72jyKSwSK8RCCVReajbtvzzBoneXct4/UPvJIqNo3 oETQ== MIME-Version: 1.0 X-Received: by 10.43.154.145 with SMTP id le17mr1481330icc.71.1411043449264; Thu, 18 Sep 2014 05:30:49 -0700 (PDT) Received: by 10.64.246.73 with HTTP; Thu, 18 Sep 2014 05:30:49 -0700 (PDT) In-Reply-To: <541AC488.5040607@rolandturner.com> References: <20140918084147.2494.qmail@joyce.lan> <877g1117ze.fsf@uwakimon.sk.tsukuba.ac.jp> <541AC488.5040607@rolandturner.com> Date: Thu, 18 Sep 2014 14:30:49 +0200 Message-ID: From: Henrik Schack To: Roland Turner Content-Type: multipart/alternative; boundary=001a11c30c6e8e669d0503562778 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Av3yRihOXY9bPnFZ7bcPqi6kNSc Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrik@schack.dk List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 12:30:51 -0000 --001a11c30c6e8e669d0503562778 Content-Type: text/plain; charset=UTF-8 I used to get this error message no matter what email address I typed in : --cut-- Password request failed The automatic login and password service failed; manual intervention is needed. Please send a mail to webmaster@tools.ietf.org and explain the situation for further assistance. --cut-- Gave it another try just now, and my Gmail address was accepted :-) /Henrik On Thu, Sep 18, 2014 at 1:39 PM, Roland Turner wrote: > On 09/18/2014 07:30 PM, Stephen J. Turnbull wrote: > > I was referring to >> >> http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki >> >> > I had no trouble working through the automated sign-up. What trouble > (error message?) are you having with your email address(es)? > > - Roland > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Mvh/Best regards Henrik Schack ICQ: 889295 http://henrik.schack.dk/ http://links.schack.dk/ --001a11c30c6e8e669d0503562778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I used to get this error message no matter what email addr= ess I typed in :

--cut--
Password request= failed

The automatic login and password service f= ailed; manual intervention is needed. Please send a mail to webmaster@tools.ietf.org and explain the s= ituation for further assistance.
--cut--

Gave it another try just now, and my Gmail address was accepted :-)<= /div>

/Henrik

=
On Thu, Sep 18, 2014 at 1:39 PM, Roland Turner <= span dir=3D"ltr"><roland@rolandturner.com> wrote:
On 09/18/2014 07:30 PM, Stephen J. Turnbull = wrote:

I was referring to

http://trac.tools.ietf.org/wg/dmarc/trac/wiki/<= /u>MilestoneOneWiki


 I had no trouble working through the automated sign-up. What trouble (error= message?) are you having with your email address(es)?

- Roland


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



--
= Mvh/Best regards
Henrik Schack
ICQ: 889295
http://henrik.schack.dk/
http://links.schack.dk/
--001a11c30c6e8e669d0503562778-- From nobody Thu Sep 18 06:08:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95591A879E for ; Thu, 18 Sep 2014 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 qtB8o63lWVGp for ; Thu, 18 Sep 2014 06:08:31 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F151A879B for ; Thu, 18 Sep 2014 06:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Ufh47IuBMqUWAyufK1BWXxkrtR7ldLktxX/UI3PEsK4=; b=M/SlHw+Sg8fpXtTCNdaEWYIarOLV9DbVNzDDkOygYHTy72HmMpQDQ7yJBUe0x5eUpRKVvdPM8iItIqbmoNevh/Uyjikx6SnliwOFnvUFKZn/LhQGxZZq9c/W4ITjOJs5J0olb06nYQ27aO8+e1orkpol7OMHOXTKlITRHEQKBbs=; Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=202.156.168.100; iprev=pass policy.iprev=202.156.168.100 (cm100.gamma168.maxonline.com.sg) Received: from [202.156.168.100] (port=51115 helo=[10.105.1.101]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XUbRk-0006dI-Oz for dmarc@ietf.org; Thu, 18 Sep 2014 13:08:29 +0000 Message-ID: <541AD947.8010509@rolandturner.com> Date: Thu, 18 Sep 2014 21:08:23 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: multipart/alternative; boundary="------------060309000001050208070000" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DpU_NXZ0SYm4agld8fouI_NCd1E Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:08:33 -0000 This is a multi-part message in MIME format. --------------060309000001050208070000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/17/2014 08:55 AM, Stephen J. Turnbull wrote: > I believe that "Mediator" is the currently standardized generic term > (RFC 5598), so "mediating list" would be the best such term. For the > present discussion, although Mediators are indeed Authors (as defined > by RFC 5598), the important specialization is that a Mediator > "attempts to preserve the original Author's information in the message > it reformulates". Sounds good. I'd note that the Mediator's Authorship trumps the poster's in any situation in which they clash (poster wants to include an attachment, Mediator removes attachments -> the forwarded messages will have no attachments) but yes, can see the sense in describing delivered list posts as having joint authorship. That said, the specifying of a List-Poster: header doesn't require determining which author is _*the*_ author for DMARC and 5322 purposes, I'd suggest that it's simply about describing an appropriate mechanism to use to indicate the author of the message prior to its passing through the Mediator for those operators who have decided to change the From: header to refer to themselves. It is hardly realistic to assume that no Mediators will make this choice, nor that all will. It would seem desirable to have a standardised method of specifying the poster for those who do. - Roland --------------060309000001050208070000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 09/17/2014 08:55 AM, Stephen J. Turnbull wrote:

I believe that "Mediator" is the currently standardized generic term
(RFC 5598), so "mediating list" would be the best such term.  For the
present discussion, although Mediators are indeed Authors (as defined
by RFC 5598), the important specialization is that a Mediator
"attempts to preserve the original Author's information in the message
it reformulates".

Sounds good.

I'd note that the Mediator's Authorship trumps the poster's in any situation in which they clash (poster wants to include an attachment, Mediator removes attachments -> the forwarded messages will have no attachments) but yes, can see the sense in describing delivered list posts as having joint authorship.

That said, the specifying of a List-Poster: header doesn't require determining which author is the author for DMARC and 5322 purposes, I'd suggest that it's simply about describing an appropriate mechanism to use to indicate the author of the message prior to its passing through the Mediator for those operators who have decided to change the From: header to refer to themselves. It is hardly realistic to assume that no Mediators will make this choice, nor that all will. It would seem desirable to have a standardised method of specifying the poster for those who do.

- Roland
--------------060309000001050208070000-- From nobody Thu Sep 18 06:17:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37A1A02D5 for ; Thu, 18 Sep 2014 06:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 slRL173zsXGZ for ; Thu, 18 Sep 2014 06:17:05 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BB71A011B for ; Thu, 18 Sep 2014 06:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=5O7Zf5VibNEsTUrKikBubU/MGLjnr3duISHmPxrGkVE=; b=e2e8GHqravvq6giZ3NhwkpGNjc/DuzfnCBKjoet8mQLghNVTh3pOO3ND9sohoP/VTSLAvdglYfflfJQmIC1TXhbVbxEnnSCEK0eYrQ18E4ZNfelr3ukC2BaSmgxM5AKE2RNA5V9R3DD5L1Ae/78Y2Kpwn39YmG0+Chi2s7c/7QY=; Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=202.156.168.100; iprev=pass policy.iprev=202.156.168.100 (cm100.gamma168.maxonline.com.sg) Received: from [202.156.168.100] (port=51133 helo=[10.105.1.101]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XUba3-0006du-UW for dmarc@ietf.org; Thu, 18 Sep 2014 13:17:04 +0000 Message-ID: <541ADB4A.2000500@rolandturner.com> Date: Thu, 18 Sep 2014 21:16:58 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140917091033.2240.qmail@joyce.lan> In-Reply-To: <20140917091033.2240.qmail@joyce.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lPwadwpOtS3WpxEDCZscb1gqHz4 Subject: Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:17:06 -0000 On 09/17/2014 05:10 PM, John Levine wrote: > Lists that rewrite the From: line were a bad idea then, and are an > equally bad idea now, for reasons that have been discussed to death. Your position on that debate is well known. I'd suggest that arguing over whether or not anyone should rewrite the From: header or not would be rather wasteful at this point as it is now abundantly clear that will be significant fractions of list-forwarding conducted both with and without From: header rewrites for the foreseeable future. The opportunity for this WG would appear to be to spell out sensible practices for use in the two situations, and perhaps to spell out the trade-offs for deciding between the two, assuming that we are able to do so without devolving into further equine abuse. I'd suggest that specifying a List-Poster: header for use in the rewrite case is an appropriate example of the former. - Roland From nobody Thu Sep 18 06:31:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54CD1A87BB for ; Thu, 18 Sep 2014 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 790AE860PptR for ; Thu, 18 Sep 2014 06:31:15 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916A11A87B8 for ; Thu, 18 Sep 2014 06:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=EZZS1WbHtsUTeY9ZGG+9lmL4iDrAQmvjomeqb3yklzM=; b=cUt6HhCuS/MBwq3N5WM96kTEkBEG1q9EZjLOLwFj6hgiX3Nmm+QkpTVYaiIDQtLj/O5afr9aOxeFaeajGBX6K4ZM0Y8zsI/DCtlTpVba4Bdd9jfhnhyiQlKYh/P6WSnNOx9Di17yiEKLC5XhfwF3Ly80XR/Tw86nFsNoKjsyS6c=; Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=202.156.168.100; iprev=pass policy.iprev=202.156.168.100 (cm100.gamma168.maxonline.com.sg) Received: from [202.156.168.100] (port=51149 helo=[10.105.1.101]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XUbnl-0006fe-Vt for dmarc@ietf.org; Thu, 18 Sep 2014 13:31:14 +0000 Message-ID: <541ADE9C.6000707@rolandturner.com> Date: Thu, 18 Sep 2014 21:31:08 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <878ult6vcq.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppf45ed1.fsf@uwakimon.sk.tsukuba.ac.jp> <1E8C87A0-0A33-4E7B-B129-5EC68BBB3DE0@isdg.net> In-Reply-To: <1E8C87A0-0A33-4E7B-B129-5EC68BBB3DE0@isdg.net> Content-Type: multipart/alternative; boundary="------------090309020405050405030704" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cT27BkqRUo21hUUNQocR42qzdrc Subject: Re: [dmarc-ietf] Indirect mail flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:31:17 -0000 This is a multi-part message in MIME format. --------------090309020405050405030704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/11/2014 07:41 PM, Hector Santos wrote: > For multiple decades, starting with mail systems predating RFC822, with everyone one of them there was a common mail engineering taboo, "thou shall not tamper with mail" and one of the primary anchoring fields, the author of the message was a principle field you didn't screw around with. You either get it or you don't. I would suggest that accepting Subject: header tagging, footer addition, attachment stripping, etc. but then objecting to From: header rewrites to identify the [second] author who made all these changes is not merely straining at a gnat having swallowed an entire herd of camels, it's missing the point: * The "forward it clean" crowd would have messages unmodified right down to byte-stream level, but for the pre-pending of trace headers. Messages handled this way have various desirable properties, particularly including passing DKIM effortlessly, and therefore DMARC likewise. * Other forwarders change stuff. DKIM makes heroic efforts to compensate - and it would be sensible to specify further mitigations if there remain workable ones to specify - but the fact remains that once you start changing stuff - particularly big things like stripping attachments, adding advertisements, etc. - you're no longer in the "forward it clean" category; it's no longer even a relevant question. - Roland --------------090309020405050405030704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 09/11/2014 07:41 PM, Hector Santos wrote:

For multiple decades, starting with mail systems predating RFC822, with everyone one of them there was a common mail engineering taboo, "thou shall not tamper with mail" and one of the primary anchoring fields, the author of the message was a principle field you didn't screw around with.   You either get it or you don't.

I would suggest that accepting Subject: header tagging, footer addition, attachment stripping, etc. but then objecting to From: header rewrites to identify the [second] author who made all these changes is not merely straining at a gnat having swallowed an entire herd of camels, it's missing the point:
  • The "forward it clean" crowd would have messages unmodified right down to byte-stream level, but for the pre-pending of trace headers. Messages handled this way have various desirable properties, particularly including passing DKIM effortlessly, and therefore DMARC likewise.
  • Other forwarders change stuff. DKIM makes heroic efforts to compensate - and it would be sensible to specify further mitigations if there remain workable ones to specify - but the fact remains that once you start changing stuff - particularly big things like stripping attachments, adding advertisements, etc. - you're no longer in the "forward it clean" category; it's no longer even a relevant question.


- Roland

--------------090309020405050405030704-- From nobody Thu Sep 18 06:44:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E481A87D2 for ; Thu, 18 Sep 2014 06:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPRSMG7WXSHU for ; Thu, 18 Sep 2014 06:44:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C51A00B2 for ; Thu, 18 Sep 2014 06:44:47 -0700 (PDT) Received: (qmail 79960 invoked from network); 18 Sep 2014 13:44:45 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 18 Sep 2014 13:44:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=804.541ae1c6.k1409; i=johnl@user.iecc.com; bh=tbP2Fj5UnXBQalG9JtnR50HgKyOnUU93YCPGx8UIhR0=; b=ApdjAzakTJYdlDUdeoalx+3Ugp879I2YxcHVdmKIum4gC8CPZWisifq/UnIhhx3VM4Mbc6TlBmGS6x7qs37Td+l007FEkwKAEoVqvuZ9uvGVq16LrAXjZQ5bnsLdGe8mRoEmy2XP7vfadO+SOXsFOQ2zvMiK3r24ArhPCAcAGo2iEGezUSiyrA38a7WtrrljnzojNVdfgALQ0fT1RDWDjW9W0YP6AT1ndqJlyR71yw8q7CbVctWbxCEkJf55TbvL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=804.541ae1c6.k1409; olt=johnl@user.iecc.com; bh=tbP2Fj5UnXBQalG9JtnR50HgKyOnUU93YCPGx8UIhR0=; b=sqT0t6MiPD04JgzNv6pmimOYPitXg4z2BLpDzbsSG769htkR9k9qc/hs132lM+e3J+8c2OCPTO/r5+kLUlgEwdWvQIQMlZpU8JmlU2+8AoHZ5/uGx1AfbQ2N3HwLu+r6cjLe2F3Na3Ce+WLBzLFcbzU+1SQeTpd+ZAtfA2+YKJxzRFguu6BlAmbsScOzuwxaa7CGTZ0W76H46AV04gqGOb35uhonQtbH/GFivnpMkR+z+w2Z9vw7fjuqqFamgYqa Date: 18 Sep 2014 13:44:16 -0000 Message-ID: <20140918134416.2051.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <541ADB4A.2000500@rolandturner.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SecZjugFPCvYXoE6hpg5SIi7DSw Cc: roland@rolandturner.com Subject: Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:44:48 -0000 >The opportunity for this WG would appear to be to spell out sensible >practices for use in the two situations, and perhaps to spell out the >trade-offs for deciding between the two, assuming that we are able to do >so without devolving into further equine abuse. I'd suggest that >specifying a List-Poster: header for use in the rewrite case is an >appropriate example of the former. While I realize that the enormous market power of the DMARC group has given mailing lists no choice but to use various workarounds, I don't think you'll find any consensus in this WG that From: rewriting or anything similar is a fait accompli. I also haven't seen anyone seriously address the concern that List-Poster: and its ilk are a short term workaround with the long term effect of training users to be phished, even more than they are already. I would much rather look at technical approaches that allow mailing lists and other forwarding agents to continue operating as they have for the past 30 years, in as secure a way as possible, without inventing new giant holes for the use of the criminals that DMARC is supposed to deter. That's what my two-level DMARC forwarding signature proposal is supposed to do. I don't claim it's perfect, but I think it's within tweaking distance of being workable. I'm not wedded to it, there are other approaches that might work, too. It also has the advantage that the implementation effort is primarily by large users of DMARC, who I would expect are aware of this WG and might actually do it, rather than makers of MUAs, who aren't, and won't. R's, John From nobody Thu Sep 18 07:44:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9271A8821 for ; Thu, 18 Sep 2014 07:44:12 -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 oUN7JHHnaUTv for ; Thu, 18 Sep 2014 07:44: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 C51811A040E for ; Thu, 18 Sep 2014 07:44:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 59DF91C3A94; Thu, 18 Sep 2014 23:44:06 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 41A981A28C8; Thu, 18 Sep 2014 23:44:06 +0900 (JST) From: "Stephen J. Turnbull" To: Roland Turner In-Reply-To: <541AD947.8010509@rolandturner.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 18 Sep 2014 23:44:06 +0900 Message-ID: <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TEeVYdPyNHtg5wHElBAz62eusQg Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:44:13 -0000 Roland Turner writes: > It is hardly realistic to assume that no Mediators will make this > choice [to munge From], nor that all will. Agreed. > It would seem desirable to have a standardised method of specifying > the poster for those who do. Not at all clear to me. The From field currently is the standardized method of specifying the poster, and I'm not sure it's a good idea to have another. Especially since it doesn't solve many other indirect mail issues, and would clearly be inappropriate to deal with, say, the "virus checker breaks DKIM signatures." Don't get me wrong -- an answer to Life, the Universe, and Everything is *not* a necessary condition. But I find the idea of a new standard Really-Truly-From-for-Indirect-Channel-X for each channel X quite distressing, and I'd rather not start down that path if there are less ugly alternatives available. Regards, From nobody Thu Sep 18 21:06:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8650B1A9167 for ; Thu, 18 Sep 2014 21:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 s1_HdJfym3YK for ; Thu, 18 Sep 2014 21:06:48 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7219F1A916A for ; Thu, 18 Sep 2014 21:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=TU9SdFq2qDizdhdQykRTK7Oy5cIetK+kb1uPHIYO8hI=; b=kXVR3+8HspsmmaLbAfOiOOaiYzI0DMLTU8xZfa/1nsXc8eMIJQ0GPzXpnctBhM+n+cgZ9KC9uRUf8ktetduPFAcChefmZlXT2prtveys34iH5PzoyQ06occ72tWU6k5b46MUFal0MKCwdqqUrND1MOweOHkD3r5I2rN6rsmXHUU=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=46715 helo=[10.100.1.110]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XUpT0-0007aJ-Sc for dmarc@ietf.org; Fri, 19 Sep 2014 04:06:44 +0000 Message-ID: <541BABD0.10506@rolandturner.com> Date: Fri, 19 Sep 2014 12:06:40 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140918134416.2051.qmail@joyce.lan> In-Reply-To: <20140918134416.2051.qmail@joyce.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/i9kVkFPQgSsOANVILTPUjb5iKFQ Subject: Re: [dmarc-ietf] yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 04:06:53 -0000 On 09/18/2014 09:44 PM, John Levine wrote: >> The opportunity for this WG would appear to be to spell out sensible >> practices for use in the two situations, and perhaps to spell out the >> trade-offs for deciding between the two, assuming that we are able to do >> so without devolving into further equine abuse. I'd suggest that >> specifying a List-Poster: header for use in the rewrite case is an >> appropriate example of the former. > While I realize that the enormous market power of the DMARC group has > given mailing lists no choice but to use various workarounds, You've already pointed out the inappropriateness of rehashing this argument. The appropriate response here would appear to be to agree to disagree and, therefore, to avoid attempts to pick a winner. Using pejorative language to describe the actions of legitimate participants in the email system would appear to be out of scope. > I don't > think you'll find any consensus in this WG that From: rewriting or > anything similar is a fait accompli. I did point this out. The WG need not involve itself in trying to pick a winner. > I also haven't seen anyone > seriously address the concern that List-Poster: and its ilk are a > short term workaround with the long term effect of training users to > be phished, even more than they are already. I have yet to see a credible threat model (plenty of hand-waving, to be sure). > I would much rather look at technical approaches that allow mailing > lists and other forwarding agents to continue operating as they have > for the past 30 years, in as secure a way as possible, without > inventing new giant holes for the use of the criminals that DMARC is > supposed to deter. Your personal preferences are [very] well understood, and aren't appropriate here. As you have already pointed out, rehashing these arguments is not appropriate.[1] > That's what my two-level DMARC forwarding signature proposal is > supposed to do. I don't claim it's perfect, but I think it's within > tweaking distance of being workable. I'm not wedded to it, there are > other approaches that might work, too. I'd be happy to review it; got a URL? - Roland 1: I accept Tim's point about in-context summaries in relevant contexts. From nobody Thu Sep 18 21:28:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8722D1A092F for ; Thu, 18 Sep 2014 21:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652, 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 pFbu3N_GRLXe for ; Thu, 18 Sep 2014 21:28:21 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A231A045E for ; Thu, 18 Sep 2014 21:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=gvWNq/j/4xAowhBNbppG4YrXBqFdE2Bg3o9s4xJhR+A=; b=Nyjg7DggRHNo5L4xgZ0uJYVmqUuphYD7ktcZKqToWGFAgl/NkMl3Psb6cq2jsFOrNroroWZFhP4J0dTlleJFQhfhIGoUvoyL+zgrzs/pKyElvFtZ4nnelzu/qgvOfyYib58MJe3NU2ydWRwgo6FlD3cqtBkq8hbAg8TLMJwGWxY=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=47413 helo=[10.100.1.110]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XUpnv-0007dB-IC for dmarc@ietf.org; Fri, 19 Sep 2014 04:28:20 +0000 Message-ID: <541BB0E2.9090509@rolandturner.com> Date: Fri, 19 Sep 2014 12:28:18 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Eb3z_ZjIrFexV7W9675ywzRcv8U Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 04:28:23 -0000 On 09/18/2014 10:44 PM, Stephen J. Turnbull wrote: > Roland Turner writes: > > > It is hardly realistic to assume that no Mediators will make this > > choice [to munge From], nor that all will. > > Agreed. > > > It would seem desirable to have a standardised method of specifying > > the poster for those who do. > > Not at all clear to me. The From field currently is the standardized > method of specifying the poster, and I'm not sure it's a good idea to > have another. Not quite: it's the standardised method of specifying the author(s) (RFC 5322 3.6.2), however specifying both authors in the From: header in Mediated mail is problematic because (a) DMARC recommends rejecting messages listing multiple authors (so far, this recommendation is not contentious) and (b) the listing of multiple authors in the From: field is vanishingly rare in real-world email. For mailing lists, the use of From: to specify the poster in preference to the Mediator is specifically not standardised. It has of course been customary for a long time, however a substantial volume of Mediated email now identifies the Mediator in the From: field instead of the poster. It is correctly observed that much of this shift is in response to DMARC, but that does not make it any less real. > Especially since it doesn't solve many other indirect mail issues, and > would clearly be inappropriate to deal with, say, the "virus checker > breaks DKIM signatures." > > Don't get me wrong -- an answer to Life, the Universe, and Everything > is *not* a necessary condition. But I find the idea of a new standard > Really-Truly-From-for-Indirect-Channel-X for each channel X quite > distressing, and I'd rather not start down that path if there are less > ugly alternatives available. This is unduly burdening the proposal. If mailing lists were some obscure corner case then, sure, but (a) they're not (you may have noticed their being mentioned occasionally in discussions around SPF, DKIM, ADSP, ...) and (b) they're an important enough special case that two draft standards already exist to specify additional List-* headers to identify list traffic (RFC 2919) and to state list commands (RFC 2369). If some more general mechanism comes up in this WG that deals with the mailing list case as well then, certainly, let's consider adopting it. Until or unless that occurs, the fact that it doesn't solve all of the known cases (let alone as-yet-undiscovered cases) is not an argument against it. - Roland From nobody Fri Sep 19 03:10:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112171A007D for ; Fri, 19 Sep 2014 03:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.108 X-Spam-Level: *** X-Spam-Status: No, score=3.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 bO8uXw9bJLxM for ; Fri, 19 Sep 2014 03:10: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 D04471A0079 for ; Fri, 19 Sep 2014 03:10:04 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1CDE11C3AF2; Fri, 19 Sep 2014 19:10:03 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0E5E11A28C8; Fri, 19 Sep 2014 19:10:03 +0900 (JST) From: "Stephen J. Turnbull" To: Roland Turner In-Reply-To: <541BABD0.10506@rolandturner.com> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 19 Sep 2014 19:10:02 +0900 Message-ID: <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/C8SJvsD31inGlEHdlR1-uigTKoE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 10:10:07 -0000 Roland Turner writes: > I have yet to see a credible threat model (plenty of hand-waving, > to be sure). "Credible" is obviously subjective and inappropriate in describing a threat *model*. You're certainly welcome to provide evidence that it's more or less likely to be realized, of course. The threat model is simple: to be useful to mail readers, the List-Poster field must be displayed in addition to (and I would say, *instead* of) the From field. For maximal effect from the *reader*'s perspective, not only "instead of", but it should also be given the same treatment by the MUA as the From field, starting with automatic addressing in replies, and proceeding to display of preferred full name and "avatars" from contact lists, etc. Of course, to attack users of such MUAs, all a spammer or phisher needs to do to subvert DMARC is to use a bad-guy-controlled domain in the From field, DKIM sign per DMARC rules, and use the stolen contact information in the List-Poster field. If necessary, add other RFC 2369 headers to further emulate the form of list traffic. There is no way to prevent or reduce the effectiveness of such attacks that doesn't simultaneously have the same effects on the usefulness of List-Poster. Note that it is exactly this form of attack that induced Yahoo! and AOL to turn to p=reject. From nobody Fri Sep 19 03:27:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F971A00C2 for ; Fri, 19 Sep 2014 03:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pquRMuMzyZKz for ; Fri, 19 Sep 2014 03:27:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC541A00B7 for ; Fri, 19 Sep 2014 03:27:36 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id AF4F8D046DF; Fri, 19 Sep 2014 06:27:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1411122455; bh=b8oXrrlLA58N6pZYzwW53PUbIoQlVhu9/uCFU2dElBc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=NNLL5RHS1W04mtXRPPQW+Ue5yA1yfbM9BEb0tUeJCm9Y2DSBDQQgPIIdlgvwGumFF K9sSGq/GBbt0FKZGBnqKHfhXFxcLA0Ug0ZnH59eEZS+Is8U6tqc1JaHXAn3C/8naSF 9Oj2Fz7vDLdTzPhmHdFoGUN/B5Z9Xm8NW5AP2ZH4= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6F955D045DA; Fri, 19 Sep 2014 06:27:35 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Fri, 19 Sep 2014 06:27:26 -0400 To: dmarc@ietf.org Message-ID: <2593bcb3-63f6-449c-9494-f5b2bce00081@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n26686WKKST5TShHqCDOPWvPxhk Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 10:27:39 -0000 On September 19, 2014 6:10:02 AM EDT, "Stephen J. Turnbull" wrote: >Roland Turner writes: > > > I have yet to see a credible threat model (plenty of hand-waving, > > to be sure). > >"Credible" is obviously subjective and inappropriate in describing a >threat *model*. You're certainly welcome to provide evidence that >it's more or less likely to be realized, of course. > >The threat model is simple: to be useful to mail readers, the >List-Poster field must be displayed in addition to (and I would say, >*instead* of) the From field. For maximal effect from the *reader*'s >perspective, not only "instead of", but it should also be given the >same treatment by the MUA as the From field, starting with automatic >addressing in replies, and proceeding to display of preferred full >name and "avatars" from contact lists, etc. Not at all. You are now objecting to something other than what I originally proposed. It would be the opposite for the reasons you say and more. The point is to provide a mechanism to facilitate a reply to the original author when desired (reply-to is problematic since it's rather unconditional). There is no need to display it. To do so would be contradictory and confusing. Scott K From nobody Fri Sep 19 04:13:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688131A00C2 for ; Fri, 19 Sep 2014 04:12:59 -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 MXlrIzxhdiUQ for ; Fri, 19 Sep 2014 04:12:57 -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 87C2C1A00B8 for ; Fri, 19 Sep 2014 04:12:57 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3C5D21C3AF9; Fri, 19 Sep 2014 20:12:56 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 29B2A1A28C8; Fri, 19 Sep 2014 20:12:56 +0900 (JST) From: stephen@xemacs.org To: Scott Kitterman In-Reply-To: <2593bcb3-63f6-449c-9494-f5b2bce00081@email.android.com> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <2593bcb3-63f6-449c-9494-f5b2bce00081@email.android.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 19 Sep 2014 20:12:56 +0900 Message-ID: <87vbojzww7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IbOvxuR8iuSf8lYX0hyFcjh8gzM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 11:12:59 -0000 Scott Kitterman writes: > The point [of X-Original-From/List-Poster] is to provide a > mechanism to facilitate a reply to the original author when desired > (reply-to is problematic since it's rather unconditional). There > is no need to display it. Need, no. But we are having this conversation precisely because people use header fields (not to forget the DNS!) in ways not intended by standards authors. Why would List-Poster be exempt? > To do so would be contradictory and confusing. Can you expand on this confusion? I can't imagine why displaying List-Poster as the address of the author of the post would be confusing, especially in cases where the post did not provide a display name in the From field. From nobody Fri Sep 19 04:28:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290CF1A00CA for ; Fri, 19 Sep 2014 04:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7npMvxxkt-H for ; Fri, 19 Sep 2014 04:28:02 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826AE1A00EB for ; Fri, 19 Sep 2014 04:28:02 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 789ADD04623; Fri, 19 Sep 2014 07:28:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1411126081; bh=B6dr9DrQNEOOMpCHzV5CkjeKSz2+6t2RiDIqPzRY594=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pn7c/5liJD1AV1y1FxdUg4/m65bwUgjHMXGSQpEzw2XYRy5rT0vSQKDD8UCRwbvVw rbexHESH7MoCP5eKzHroCeS8wuR43NmqXR8laGIlQnZS5gA+IEJV1ZW1juulH5zS9l 5i/TfZmKvmhEiEzYW4Lbqf9aesPkunBN2xVkWK2A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4811AD042EE; Fri, 19 Sep 2014 07:28:01 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 19 Sep 2014 07:27:58 -0400 Message-ID: <1464786.DVd5fcaWpy@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87vbojzww7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140918134416.2051.qmail@joyce.lan> <2593bcb3-63f6-449c-9494-f5b2bce00081@email.android.com> <87vbojzww7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/buVOsGU-52WCF8w0T8CdTbBrAeM Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 11:28:06 -0000 On Friday, September 19, 2014 20:12:56 stephen@xemacs.org wrote: > Scott Kitterman writes: > > The point [of X-Original-From/List-Poster] is to provide a > > mechanism to facilitate a reply to the original author when desired > > (reply-to is problematic since it's rather unconditional). There > > is no need to display it. > > Need, no. But we are having this conversation precisely because > people use header fields (not to forget the DNS!) in ways not intended > by standards authors. Why would List-Poster be exempt? It wouldn't be exempt, but display isn't necessary to achieve the intended objective. While I can't exclude the possibility that someone will write an MUA that exposes this, the MUAs that most people use (either via a traditional application or a web U/I) are written by the companies that have developed DMARC. I expect them to resist the temptation. > > To do so would be contradictory and confusing. > > Can you expand on this confusion? I can't imagine why displaying > List-Poster as the address of the author of the post would be > confusing, especially in cases where the post did not provide a > display name in the From field. First, I expect display names to be less commonly displayed in the future. They make it much too easy to trick people into being confused about who sent a message. I don't think that no display name if From will drive anything. Second, you snipped the key part I was replying to: > >The threat model is simple: to be useful to mail readers, the > >List-Poster field must be displayed in addition to (and I would say, > >*instead* of) the From field. I was replying to your primary point of "in addition to". Having two entities the messages is "from" is inherently confusing. Scott K From nobody Sat Sep 20 04:41:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3001A00F2 for ; Sat, 20 Sep 2014 04:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 F4SYF9uMSBF0 for ; Sat, 20 Sep 2014 04:41:42 -0700 (PDT) Received: from wmail.tana.it (www.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 498181A00E2 for ; Sat, 20 Sep 2014 04:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1411213296; bh=tt8F4GdskqXfYLumrSEhIfA+88oZG/iQdw3xSGk6aOI=; l=3124; h=Date:From:To:References:In-Reply-To; b=wmJnfgcLva4WgYgsBNpNV9ZUEcLGEPkYZmrp1urCevq6DfA2QtOHAObrDCDkpdqMf FDpvlMNszzC+T2asC3sM1/59Ej723HYciA1E76rBdQVpox8cCuiX/5FhNMKr7zpSuv 7UadE8LCPblIbYG+P+QoGTKk+PL5JofeGEBWgGbc= 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) by wmail.tana.it with ESMTPA; Sat, 20 Sep 2014 13:41:36 +0200 id 00000000005DC045.00000000541D67F0.000005C9 Message-ID: <541D67F0.5070800@tana.it> Date: Sat, 20 Sep 2014 13:41:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yv4Mlj34TglJoKIeZPlTacoLNZs Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 11:41:44 -0000 [I refrain from swapping Subject: and display-phrase in an attempt to evoke some more brainstorming, because of the mess that possible replies would make if I did.] On Fri 19/Sep/2014 12:10:02 +0200 Stephen J. Turnbull wrote: > Roland Turner writes: > >> I have yet to see a credible threat model (plenty of hand-waving, >> to be sure). > > "Credible" is obviously subjective and inappropriate in describing a > threat *model*. > > [...Description of credible threat model elided...] > > There is no way to prevent or reduce the effectiveness of such attacks > that doesn't simultaneously have the same effects on the usefulness of > List-Poster. Note that it is exactly this form of attack that induced > Yahoo! and AOL to turn to p=reject. Of course we wouldn't have been having this discussion if DMARC had taken care of mailing lists needs. Now we have to specify a possible MLM behavior, such that list participants are not affected by their domains' DMARC policy decisions. If the model is phish-proof, all the better. IMHO, we should specify a credible MLM model, even if that can be slightly off topic for the WG, in order to maximize its probability of being adopted. The rest of this message has some notes to this end. *Field Name* List-Poster: is too similar to List-Post:, especially for foreigners; List-Author: would be clearer. X-Original-From: conveys a precise meaning --if we specify that-- and pairs nicely with X-Original-Authentication-Results:. *Rewritten Display Phrase* It seems to be going without saying that the display phrase of the rewritten From: is taken from the original. That allows the omission to display the latter, while still keeping the least-surprise principle when users click reply-to-poster. *Rewritten Domain* The address domain shall be that of the MLM. That's what rewriting From: is all about. Reasons why that is semantically correct have been discussed already. *Rewritten Local Part* It is appropriate to specify the role of the local part too, for our spec to make sense. I'd suggest some sort of thread-id, so that the "normal" reply buttons works as expected. Subscribers can choose whether they want private notifications on thread replies, much like they do for blog comments. Currently, this choice is made by replying authors on a per-post basis. Note that this obsoletes reply-to-list buttons. List-Post: is only useful to start new threads, in this model. Although the poster intention can be inferred from other message details, it may be convenient to replace that field with List-Post-New:. Besides disabling obsolete buttons, the mere presence of the latter field may hint to MUAs not to store the From: address upon replying. *Conclusion* I outlined an idea for a new model of mailing list where From: is rewritten smoothly for all posters, irrespectively of their domains' DMARC settings. There are certainly zillions alternatives. Differently from Netnews, MLM behavior was never specified. Had it been, maybe DMARC could have taken it into account. Ale From nobody Sun Sep 21 21:51:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109CF1A1A1A for ; Sun, 21 Sep 2014 21:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.786, 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 Vl_OuCDr2QiD for ; Sun, 21 Sep 2014 21:51:45 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D741A1A18 for ; Sun, 21 Sep 2014 21:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=1k90inkQOQsKNj1cS5DR4GGb11pc4XJ5zkTltYXFtZk=; b=u0G10pu+hr1WJ/m9+HSnP0LW7SIQXFpfS0vKy29X6Eg1PegAbuU6XkdlNpvCJCArJjlcQj4Y6dLsW2i6gC/LpRfOJ2tvpiGdKRiXsNuHm7naOJiX9/OxZQRovqXyxxz/MHxs81uRjseMCJ2v+oMAscFo8F5OZ1FOo7XQoeuOtMI=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=58462 helo=[10.100.1.110]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1XVvb9-0003M8-NR for dmarc@ietf.org; Mon, 22 Sep 2014 04:51:42 +0000 Message-ID: <541FAADB.2080409@rolandturner.com> Date: Mon, 22 Sep 2014 12:51:39 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: multipart/alternative; boundary="------------080509080002090601080602" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dnkW1Um7qgkF5q63yRbgoc1BmkE Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 04:51:47 -0000 This is a multi-part message in MIME format. --------------080509080002090601080602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/19/2014 06:10 PM, Stephen J. Turnbull wrote: > Roland Turner writes: > > > I have yet to see a credible threat model (plenty of hand-waving, > > to be sure). > > "Credible" is obviously subjective and inappropriate in describing a > threat *model*. You're certainly welcome to provide evidence that > it's more or less likely to be realized, of course. "Credible" is not subjective, but to be more precise: sufficiently concrete to assess, and can be assessed as a realistic threat. > The threat model is simple: to be useful to mail readers, the > List-Poster field must be displayed It is not a requirement that adding a List-Poster: field be useful to mail readers. The existing use of X-Original-From is an existence proof of [perceived] utility, despite the absence of widespread (any?) MUA display of this data. It is certainly interesting to pursue what happens if MUA developers/vendors see utility in displaying this information. > in addition to (and I would say, > *instead* of) the From field. For maximal effect from the *reader*'s > perspective, not only "instead of", but it should also be given the > same treatment by the MUA as the From field, Setting aside John Levine's argument that MUA developers won't implement this stuff at all, your model is only realistic if the MUA developer is seeking to maximally confuse the reader, or more charitably: is somehow utterly ignorant of DMARC's existence and impact. It would also only be sensible to display the List-Poster: (or in any other sense make use of it) in the context of being via the list (which is more-or-less the rationale behind changing the From: display-name to "Poster via List"). As Scott points out, the overlap between developers/vendors of MUAs in widespread use and the creators of DMARC is significant. In concrete terms, as at September 2012 by user count: * DMARC creators: ~50% * Apple: ~40% * Other: ~10% Given Apple's recent ...involuntary progress on the security front, I'd suggest that the developers of the MUAs in use by ~90% of people are strongly motivated to act in a way which does not cause the problem that you're describing. The rest are likely to be motivated to adjust their behaviour when encouraged and/or can be disregarded as being too small to present a worthwhile attack surface. (To be clear: I'm not suggesting that it is reasonable to stomp on the little guy, only that ignorance at such a small scale is not a significant concern. Also: yes, the data is two years old, however if the "other" category has moved at all, it hasn't grown enough to alter the argument.) ... > Of course, to attack users of such MUAs, all a spammer or phisher > needs to do to subvert DMARC is to use a bad-guy-controlled domain in > the From field, DKIM sign per DMARC rules, and use the stolen contact > information in the List-Poster field. If necessary, add other RFC > 2369 headers to further emulate the form of list traffic. A List-Poster: header should not be displayed at all unless there is some reason to trust the MLM identified in the From: header (and authenticated) and, as above, should be displayed alongside the list identifier. There is precedent for this, e.g. only honouring List-Unsubscribe: for authenticated senders who have a solid track record of reliable behaviour. As John Levine has pointed out repeatedly, the trustworthy set of list operators is small and slow changing; keeping track of this is not a serious problem. For the reasons described above, it is not necessary to worry about MUA vendors getting this wrong and/or failing to correct it once it's pointed out. > There is no way to prevent or reduce the effectiveness of such attacks > that doesn't simultaneously have the same effects on the usefulness of > List-Poster. Note that it is exactly this form of attack that induced > Yahoo! and AOL to turn to p=reject. That was purely about spoofing From: headers for direct delivery to victims, there was no involvement of known-to-be-well-behaved lists. - Roland --------------080509080002090601080602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 09/19/2014 06:10 PM, Stephen J. Turnbull wrote:

Roland Turner writes:

 > I have yet to see a credible threat model (plenty of hand-waving,
 > to be sure).

"Credible" is obviously subjective and inappropriate in describing a
threat *model*.  You're certainly welcome to provide evidence that
it's more or less likely to be realized, of course.

"Credible" is not subjective, but to be more precise: sufficiently concrete to assess, and can be assessed as a realistic threat.

The threat model is simple: to be useful to mail readers, the
List-Poster field must be displayed

It is not a requirement that adding a List-Poster: field be useful to mail readers. The existing use of X-Original-From is an existence proof of [perceived] utility, despite the absence of widespread (any?) MUA display of this data.

It is certainly interesting to pursue what happens if MUA developers/vendors see utility in displaying this information.

in addition to (and I would say,
*instead* of) the From field.  For maximal effect from the *reader*'s
perspective, not only "instead of", but it should also be given the
same treatment by the MUA as the From field,

Setting aside John Levine's argument that MUA developers won't implement this stuff at all, your model is only realistic if the MUA developer is seeking to maximally confuse the reader, or more charitably: is somehow utterly ignorant of DMARC's existence and impact. It would also only be sensible to display the List-Poster: (or in any other sense make use of it) in the context of being via the list (which is more-or-less the rationale behind changing the From: display-name to  "Poster via List").

As Scott points out, the overlap between developers/vendors of MUAs in widespread use and the creators of DMARC is significant. In concrete terms, as at September 2012 by user count:

  • DMARC creators: ~50%
  • Apple: ~40%
  • Other: ~10%

Given Apple's recent ...involuntary progress on the security front, I'd suggest that the developers of the MUAs in use by ~90% of people are strongly motivated to act in a way which does not cause the problem that you're describing. The rest are likely to be motivated to adjust their behaviour when encouraged and/or can be disregarded as being too small to present a worthwhile attack surface.

(To be clear: I'm not suggesting that it is reasonable to stomp on the little guy, only that ignorance at such a small scale is not a significant concern. Also: yes, the data is two years old, however if the "other" category has moved at all, it hasn't grown enough to alter the argument.)


...

Of course, to attack users of such MUAs, all a spammer or phisher
needs to do to subvert DMARC is to use a bad-guy-controlled domain in
the From field, DKIM sign per DMARC rules, and use the stolen contact
information in the List-Poster field.  If necessary, add other RFC
2369 headers to further emulate the form of list traffic.

A List-Poster: header should not be displayed at all unless there is some reason to trust the MLM identified in the From: header (and authenticated) and, as above, should be displayed alongside the list identifier. There is precedent for this, e.g. only honouring List-Unsubscribe: for authenticated senders who have a solid track record of reliable behaviour. As John Levine has pointed out repeatedly, the trustworthy set of list operators is small and slow changing; keeping track of this is not a serious problem.

For the reasons described above, it is not necessary to worry about MUA vendors getting this wrong and/or failing to correct it once it's pointed out.

There is no way to prevent or reduce the effectiveness of such attacks
that doesn't simultaneously have the same effects on the usefulness of
List-Poster.  Note that it is exactly this form of attack that induced
Yahoo! and AOL to turn to p=reject.

That was purely about spoofing From: headers for direct delivery to victims, there was no involvement of known-to-be-well-behaved lists.

- Roland
--------------080509080002090601080602-- From nobody Mon Sep 22 14:02:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26B51A1AE4 for ; Mon, 22 Sep 2014 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 LNcitEUZgBcd for ; Mon, 22 Sep 2014 14:02:09 -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 95B851A1A7B for ; Mon, 22 Sep 2014 14:02:09 -0700 (PDT) Received: from [10.10.10.101] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s8ML1vcE049997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 22 Sep 2014 14:02:06 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s8ML1vcE049997 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1411419727; bh=qbkDkUqUmjI7j+jUp/S23kIvRBdDGAOWyu0mToijEHY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=Fe0EOAb/L/OuLi2IISZeZB1ZIXLqvGEVCjh0FMtMo8/vB4g120ajO1nK6gQhqByHe ZEZm7FOUUmioSGIO6Mm4Ojl+52Qjv0uUhf/XTk9I8nLhX5qOATR4P4li02XUGFfXzD DU8NWUmsAMecO6BF7wi9mQw7k2+ONMX7SFI6/QZk= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.101] Message-ID: <54208E47.9000705@crash.com> Date: Mon, 22 Sep 2014 14:01:59 -0700 From: Steve Jones User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/d_-HExxfmXdcDZExy6V_79xH18g Subject: [dmarc-ietf] Cataloging MLM manipulations of messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:02:11 -0000 Somebody suggested that we should catalog common manipulations that MLMs perform on the messages they handle. I took a first pass but it would surely benefit from wider review and input. I've put what I have so far on the DMARC WG wiki, as that seemed like a more convenient way to maintain it. Commentary is welcome here on the mailing list, and anybody who has registered can access the wiki to make changes or log comments. Link: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki/MLM-Manipulations Is this useful? Hopeless? Somewhere in between? Milestone 1 editors & chairs: If this not to your liking, please move as appropriate or advise as necessary. --Steve. From nobody Mon Sep 22 14:13:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2E1A6EE7 for ; Mon, 22 Sep 2014 14:13: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 vsr5ONeKn7_i for ; Mon, 22 Sep 2014 14:13: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 825371A1B0E for ; Mon, 22 Sep 2014 14:13:41 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8MLCoAr019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Sep 2014 14:12:53 -0700 Message-ID: <542090CE.7010102@dcrocker.net> Date: Mon, 22 Sep 2014 14:12:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Jones , dmarc@ietf.org References: <54208E47.9000705@crash.com> In-Reply-To: <54208E47.9000705@crash.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 22 Sep 2014 14:12:53 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SkSr3V8ZHMyF6J36IDmiJ0g9jd0 Subject: Re: [dmarc-ietf] Cataloging MLM manipulations of messages 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, 22 Sep 2014 21:13:42 -0000 On 9/22/2014 2:01 PM, Steve Jones wrote: > > Is this useful? Hopeless? Somewhere in between? /Very/ useful, IMO. I suggest that we target developing this -- with assistance from the rest of the email community -- and eventually publish it as an informational RFC. Its utility probably goes beyond DMARC and might provide a reference for other discussions about mailing list behavior. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 22 14:15:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20C1A1B0E for ; Mon, 22 Sep 2014 14:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM-HxAU7UV_M for ; Mon, 22 Sep 2014 14:15:55 -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 C8F8E1A1A7B for ; Mon, 22 Sep 2014 14:15:54 -0700 (PDT) Received: (qmail 75126 invoked from network); 22 Sep 2014 21:15:53 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 22 Sep 2014 21:15:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cf20.54209189.k1409; i=johnl@user.iecc.com; bh=UhcA5m1eeVrbPmbZkvLs4SuIq2EXWC3oEJum/yXMHJY=; b=Wpdg+R7CEaE918E16So/mEtaQPP8Y+gopGEBG3Zt4X4NeVwag9GNVjwEveDUmDWFaXwvLVX+xcXl6ak+41gFS0vacwdv6c+NlZ9Gun0CxSa0VWYTLpUHjNp1rSP48hSyxFJpwmt2XyXUCul5uNu/C+M2ZwesITJlC17PW7dvrMkpd9I4RFqrrsU8b39BafbQ/4jTS1i+Htr9ZIJpzaisqlvDA0q8JCnZRJuiGnKi6oIZHyDifFOFGwWVUhKQm7Vb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=cf20.54209189.k1409; olt=johnl@user.iecc.com; bh=UhcA5m1eeVrbPmbZkvLs4SuIq2EXWC3oEJum/yXMHJY=; b=ylCv5zoXIla0JREPb5XOsPwskLolAWz5b16f6DuAMOX//GIVtXOHEYRPxt4LOnlAy54vJQ1QLjpbz3XDgoiZwtYLJINY/K2biWzB6cGrrjEbaX/iRx5jl172uZK8oRL0sU0zfeGq0NeaFYMTEsY/xvODazkTZKNEAMqZtV7wSMvVIv8oo8E2bxpo2W3KkkXFXk2zPNG4tPp/UlfuY+c83Qp5mP84nin7lbe04OMBUl0/Oroh+5GYOWb1wT68uhOA Date: 22 Sep 2014 21:15:30 -0000 Message-ID: <20140922211530.53023.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <541FAADB.2080409@rolandturner.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RuVNN0uYrelf_n-fXpieeaFvz7I Cc: roland@rolandturner.com Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:15:56 -0000 >mail readers. The existing use of X-Original-From is an existence proof >of [perceived] utility, despite the absence of widespread (any?) MUA >display of this data. Who uses X-Original-From ? This is a real question, I'm not aware of anyone who does. R's, John PS: >and the creators of DMARC is significant. >In concrete terms, as at September 2012 by user count: > > * DMARC creators: ~50% > * Apple: ~40% > * Other: ~10% Yes, we're aware of the enormous market power of the DMARC group. From nobody Mon Sep 22 14:55:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559B91A1B14 for ; Mon, 22 Sep 2014 14:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 77fv2uEiifzT for ; Mon, 22 Sep 2014 14:55:32 -0700 (PDT) Received: from articuno.alameth.org (articuno.alameth.org [IPv6:2600:3c01::f03c:91ff:fe70:755c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8CF1A1B0E for ; Mon, 22 Sep 2014 14:55:29 -0700 (PDT) Received: from clavinova.eng.sonicwall.com (users.sonicwall.com [67.115.118.5]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by articuno.alameth.org (Postfix) with ESMTPS id A6D30851D; Mon, 22 Sep 2014 22:00:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alameth.org; s=n01; t=1411423243; bh=DortuaG0oopf69bxThLUoo8A6zLQEnH0OOjhNDQUZco=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=OdkiHrIEy7xebaaj+JeWVrvkCWrgrpvhuRL7nrxCVTUaw6U8nhskJLa6mLZSHg39x 5n60eSBiwIZDvnNfKlxvU3IJhKn+do4j/TEayIysXa9hCHeWA4iyUZ4afDfXKakON9 Gegt+0EIObADHtgI7K9hUaMpM4JV7xrzamlXh0Y4= Message-ID: <54209AE9.70100@alameth.org> Date: Mon, 22 Sep 2014 14:55:53 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140922211530.53023.qmail@joyce.lan> In-Reply-To: <20140922211530.53023.qmail@joyce.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xlg__Trzm1UsbNntM2Znb4sm5RY Cc: roland@rolandturner.com Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:55:34 -0000 On 09/22/2014 02:15 PM, John Levine wrote: >> mail readers. The existing use of X-Original-From is an existence proof >> of [perceived] utility, despite the absence of widespread (any?) MUA >> display of this data. > Who uses X-Original-From ? This is a real question, I'm not aware of > anyone who does. In my experience, the utility of X-Original-From has been for humans diagnosing mistakes in the mail router's rewriting rules. Since this was implemented independently by many vendors, the contents and semantics of the field have varied considerably, ranging from the original 821.MailFrom, to the original 822.From, to the sending user's login credentials. Don't get me started on the X- prefix. From nobody Mon Sep 22 15:01:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25781A1B36 for ; Mon, 22 Sep 2014 15:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 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_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 v0mtbzWUmibp for ; Mon, 22 Sep 2014 15:01:00 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903BC1A1A69 for ; Mon, 22 Sep 2014 15:00:57 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8354DD045F9; Mon, 22 Sep 2014 18:00:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1411423256; bh=D40x+23qzVGOlv8CIPoEXSCpG8ci6z9wcQGtUFOdRxE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SBa03zH/J8T1/j2cR4GAJ5MgYFP6Zy5rkl4YwCHlf9+9eSmYvMKzx8O7aNuptGp3Z sic0ScdVV8/mcEXwyi1jv/KBmsLMqhnmsex17bYNg8iMP2VMUGBN0BVVR1UqNbXjB7 pF9jpwuyqy14f1PvzxYZFmwMoWIkZ+l05pIozGss= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5AE56D043E8; Mon, 22 Sep 2014 18:00:56 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 22 Sep 2014 18:00:55 -0400 Message-ID: <1561541.nWppMeomLX@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-35-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20140922211530.53023.qmail@joyce.lan> References: <20140922211530.53023.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lyoJOHtcJuIR4Nddh2m2qFKx9CA Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:01:01 -0000 On Monday, September 22, 2014 21:15:30 John Levine wrote: > >mail readers. The existing use of X-Original-From is an existence proof > >of [perceived] utility, despite the absence of widespread (any?) MUA > >display of this data. > > Who uses X-Original-From ? This is a real question, I'm not aware of > anyone who does. Google (at least Groups) does when it rewrites the From address for messages from a DMARC p=reject domain. I have mail that has X-Original-From: user@yahoo.com in it. It also has X-Original-Sender: user@yahoo.com, which the mail from non-rewritten domains also has. The non-rewritten domains don't have X-Original-From. This is what got me started on "let's pick a standard name". Scott K From nobody Mon Sep 22 15:17:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5484F1A1AAD for ; Mon, 22 Sep 2014 15:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, 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 X28isIh-8erW for ; Mon, 22 Sep 2014 15:17:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1138B1A1AA1 for ; Mon, 22 Sep 2014 15:17:52 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id r20so3810351wiv.6 for ; Mon, 22 Sep 2014 15:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=3vniBanzUHShQQq3gG7+Gvnt9uYqwYftXOU6uPI/eCE=; b=MT0Z2DSjB/EM4tkXEHuP1HDh2E8UbRN4L7TwKiuFKFQFQ5ebGx8IE2dYEBo4KgZ6+2 65HcF1wRbe2H4Cb75x7Ru3ThgtPCmg/2jHtLtYdLRwLqt11oMFh33ucItvPzwuy5yTs8 boq8xtP71JVLGB75dTMs99UIqqaOPYuSEcSKU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=3vniBanzUHShQQq3gG7+Gvnt9uYqwYftXOU6uPI/eCE=; b=CgyX+D0L8SIWT0RcVviO+pxtzVIxBGqhVQxcjXYHYJHzONYgC4CKuNDj1jtqbDI67x BWasKEAa7h9QH0Pn79Mt1vharMws27kyotNkhmGHf+1JJGkZTYQkIJSEjelWXcKP8jin lt0F9VWSJ6QqSBLcVEyHmFGVOUI8RymyIAEUwbk/e4oBqUg2sVAjn/p/gzk16w1is+mt 43bLAOSFppAT45os7JikCVovbF47K0T38ANYZiLzLoq+xk5VL8w8jPD8ioa5tSablNFB A+gXdVfl5h7TLcpkR80wWpYNo+IOpCnvwX0a9MrIfrpJny7XiNT8QN/N+YT36xGiG+Gf QnnQ== X-Gm-Message-State: ALoCoQm2Mg32ofRItWOAstig52N52Aq9Kv9vcRa6ZAPaOYk/Mz/KO7E3BEdM1h8I4eKdoxHvN/2P X-Received: by 10.180.80.198 with SMTP id t6mr11695759wix.6.1411424271600; Mon, 22 Sep 2014 15:17:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.103.227 with HTTP; Mon, 22 Sep 2014 15:17:31 -0700 (PDT) In-Reply-To: <1561541.nWppMeomLX@scott-latitude-e6320> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> From: Josh Aberant Date: Mon, 22 Sep 2014 15:17:31 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=f46d044287ee5621de0503aed283 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NnPyedHEwGDlduERJPZPOTdJ1h8 Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:17:54 -0000 --f46d044287ee5621de0503aed283 Content-Type: text/plain; charset=UTF-8 > Who uses X-Original-From ? This is a real question, I'm not aware of > anyone who does. At Twitter we use the X-Original-From to route our security tickets with users within our ticketing system Salesforce. Users can open and reply to tickets by emailing what is a Google Groups alias. Google Groups (takes ownership of the From per our #RejectPolicy) and then forwards those emails to Salesforce where they are automatically turned into support tix where we key off of the user's email address in the X-Original-From header. Josh On Mon, Sep 22, 2014 at 3:00 PM, Scott Kitterman wrote: > On Monday, September 22, 2014 21:15:30 John Levine wrote: > > >mail readers. The existing use of X-Original-From is an existence proof > > >of [perceived] utility, despite the absence of widespread (any?) MUA > > >display of this data. > > > > Who uses X-Original-From ? This is a real question, I'm not aware of > > anyone who does. > > Google (at least Groups) does when it rewrites the From address for > messages > from a DMARC p=reject domain. I have mail that has X-Original-From: > user@yahoo.com in it. It also has X-Original-Sender: user@yahoo.com, > which > the mail from non-rewritten domains also has. The non-rewritten domains > don't > have X-Original-From. > > This is what got me started on "let's pick a standard name". > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d044287ee5621de0503aed283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Who uses X-Original-From ?=C2=A0 This= is a real question, I'm not aware of
> anyone who does.

At Twitter we use the X-Ori= ginal-From to route our security tickets with users within our ticketing sy= stem Salesforce. Users can open and reply to tickets by emailing what is a = Google Groups alias. Google Groups (takes ownership of t= he From per our #RejectPolicy) and then forwards those emails to Sal= esforce where they are automatically turned into support tix where we key o= ff of the user's email address in the X-Original-From header.

Josh




On Mon, Sep 22, 2014 at 3:00 PM, Scott Kitte= rman <sklist@kitterman.com> wrote:
On Monday, September 22, 2014 21:15:= 30 John Levine wrote:
> >mail readers. The existing use of X-Original-From is an existence = proof
> >of [perceived] utility, despite the absence of widespread (any?) M= UA
> >display of this data.
>
> Who uses X-Original-From ?=C2=A0 This is a real question, I'm not = aware of
> anyone who does.

Google (at least Groups) does when it rewrites the From address for = messages
from a DMARC=C2=A0 p=3Dreject domain.=C2=A0 I have mail that has X-Original= -From:
user@yahoo.com in i= t.=C2=A0 It also has X-Original-Sender: user@yahoo.com, which
the mail from non-rewritten domains also has.=C2=A0 The non-rewritten domai= ns don't
have X-Original-From.

This is what got me started on "let's pick a standard name".<= br>
Scott K

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

--f46d044287ee5621de0503aed283-- From nobody Mon Sep 22 15:56:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DAF1A6F42 for ; Mon, 22 Sep 2014 15:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 dL4Dk_twJGqo for ; Mon, 22 Sep 2014 15:56:36 -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 1F1241A1B10 for ; Mon, 22 Sep 2014 15:56:34 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s8MMuPGK051051 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 22 Sep 2014 15:56:31 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s8MMuPGK051051 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1411426591; bh=IB/T7+6mV+XUt7I6tRCg6bsvIGiwuejklc+wx73KsiY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=U5nUcq21TVEOHSrpARj+1JtuIox/afpc69ciUB+3KOurENTT+8KtFC+ET9KAVpDJi X14U2CBQnISWDOmwb3y++AoLRfdgoK+KFTGmtEfPF06NEmysQn9HYLgvISvcuMkJZW hFqHQajAGLaXfdgAV9NN4p4S6vbJdQxPiTIZ6xG4= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <5420A91B.2070102@crash.com> Date: Mon, 22 Sep 2014 15:56:27 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/z5FdGc4BRwxkMWugjGbd3vi2OZ4 Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:56:41 -0000 On 09/22/2014 03:17 PM, Josh Aberant wrote: > > Who uses X-Original-From ? This is a real question, I'm not aware of > > anyone who does. > > At Twitter we use the X-Original-From to route our security tickets > with users within our ticketing system Salesforce. Users can open and > reply to tickets by emailing what is a Google Groups alias. Google > Groups (takes ownership of the From per our #RejectPolicy) and then > forwards those emails to Salesforce where they are automatically > turned into support tix where we key off of the user's email address > in the X-Original-From header. Interesting use case. Presumably the messages are flowing from Google Groups to Salesforce over the Internet. Certainly an example of how Google Groups can be configured to manipulate headers. However I would consider everything that happens after Salesforce receives the messages as an application workflow. Messages the customer sees would be in-scope; I'm not so sure about things happening between Google Groups and Salesforce, or within Salesforce. If we consider all the ways email messages are spindled, folded and mutilated when they become part of an application workflow, I expect we'd see an absolute explosion of additional weirdness... --Steve. From nobody Mon Sep 22 16:43:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899F01A02C0 for ; Mon, 22 Sep 2014 16:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 tVTYgG3CADfV for ; Mon, 22 Sep 2014 16:43:19 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975341A6F7F for ; Mon, 22 Sep 2014 16:43:07 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id l13so3696134iga.12 for ; Mon, 22 Sep 2014 16:43:06 -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=IfWR86ii7bGS0LAbuMPje8kNh9z/I8LEMAa+NFp4KMQ=; b=gDfALljZdveltJ3i1fyEGKDqLBr8W82DuCiGdXnzF6XgFzM3EMhkvBUbR6rjZu5gUE oNlN2o+acBN6CE1g8DliOPHfBnWRj8bfcw75qbq//mlS8xF0cN3TybHOAipMdMmOsfTj nqs6XzaNdOgJnKgsEPI4bUmutBouFE975WbrIWj2bdh3mmuAGiF78U3kGZBTYW6vHgSD 5v/tQ6WWyoIsAqHeKb7bCR8551xB/bbWH4si4jNAUTRITp/tzV4sRTysv3Qg1fK+n8QR Jyfz3WJfnBYWJ/3/2WfOkoWUqYTKx+brSfYVVuWmcAIONdzAZOsopmClkGx2c++GHVyT r3Vg== 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=IfWR86ii7bGS0LAbuMPje8kNh9z/I8LEMAa+NFp4KMQ=; b=ODK2FqoFoqPKdg+sKumgHVg8loeEdliAxsDq8ZAeeMATEqc4BICoN8fWTho9wXhajB 1DaH+/+gnb54T6Bxi/pzS4azIRibXedFOvBDsdIH3A5asfa4Xz5Il5Ezs5NWuFGl0ei/ WmozFEgEQDqJgUOVJs4LsZQuU1vMF70J6dnEe8PONyWSbcwwiosk1Nvki9oUzB1iaGP5 SGp/scLsfAihLnDF5IsLye7n4+dkOS+SKXSM5YyUP8ZzHI3nYipZInhWDdB22MiG4aCz uXqj2F8p4Pu2lxHQSJMsQsat8rMlsA2eI+IdKLgP8HHA2iUJUSU2m1svbbTZntni/rM/ hu1A== X-Gm-Message-State: ALoCoQlfiRGd38Wd68z219T5bosUPy75y7bYmA6kBZIu/xUm1sKqGgKXEbPF6ZbSMsP6zWZ9PaYD MIME-Version: 1.0 X-Received: by 10.42.83.81 with SMTP id g17mr19411141icl.45.1411429386847; Mon, 22 Sep 2014 16:43:06 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Mon, 22 Sep 2014 16:43:06 -0700 (PDT) In-Reply-To: <541BB0E2.9090509@rolandturner.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> Date: Mon, 22 Sep 2014 16:43:06 -0700 Message-ID: From: Brandon Long To: Roland Turner Content-Type: multipart/alternative; boundary=90e6ba613a3c3ac1240503b003b5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YqhNU5VedkcJreR55UFtzVekgYg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 23:43:21 -0000 --90e6ba613a3c3ac1240503b003b5 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 18, 2014 at 9:28 PM, Roland Turner wrote: > On 09/18/2014 10:44 PM, Stephen J. Turnbull wrote: > > Roland Turner writes: >> >> > It is hardly realistic to assume that no Mediators will make this >> > choice [to munge From], nor that all will. >> >> Agreed. >> >> > It would seem desirable to have a standardised method of specifying >> > the poster for those who do. >> >> Not at all clear to me. The From field currently is the standardized >> method of specifying the poster, and I'm not sure it's a good idea to >> have another. >> > > Not quite: it's the standardised method of specifying the author(s) (RFC > 5322 3.6.2), however specifying both authors in the From: header in > Mediated mail is problematic because (a) DMARC recommends rejecting > messages listing multiple authors (so far, this recommendation is not > contentious) and (b) the listing of multiple authors in the From: field is > vanishingly rare in real-world email. > > For mailing lists, the use of From: to specify the poster in preference to > the Mediator is specifically not standardised. It has of course been > customary for a long time, however a substantial volume of Mediated email > now identifies the Mediator in the From: field instead of the poster. It is > correctly observed that much of this shift is in response to DMARC, but > that does not make it any less real. But note that "similar" tools, such as bulletin-boards, have almost always used the mediator as the From header on notification messages. Mailing lists which provide an "anonymous" function also use the list/mediator address as the From in order to hide the original poster's email address. Brandon --90e6ba613a3c3ac1240503b003b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 18, 2014 at 9:28 PM, Roland Turner <roland@rolandtur= ner.com> wrote:
On 09/18/2014 10:44 PM, Stephen J. Turnbull wrote:

Roland Turner writes:

=C2=A0 > It is hardly realistic to assume that no Mediators will make th= is
=C2=A0 > choice [to munge From], nor that all will.

Agreed.

=C2=A0 > It would seem desirable to have a standardised method of specif= ying
=C2=A0 > the poster for those who do.

Not at all clear to me.=C2=A0 The From field currently is the standardized<= br> method of specifying the poster, and I'm not sure it's a good idea = to
have another.

 Not quite: it's the standardised method of specifying the author(s) (RF= C 5322 3.6.2), however specifying both authors in the From: header in Media= ted mail is problematic because (a) DMARC recommends rejecting messages lis= ting multiple authors (so far, this recommendation is not contentious) and = (b) the listing of multiple authors in the From: field is vanishingly rare = in real-world email.

For mailing lists, the use of From: to specify the poster in preference to = the Mediator is specifically not standardised. It has of course been custom= ary for a long time, however a substantial volume of Mediated email now ide= ntifies the Mediator in the From: field instead of the poster. It is correc= tly observed that much of this shift is in response to DMARC, but that does= not make it any less real.

But note that &= quot;similar" tools, such as bulletin-boards, have almost always used = the mediator as the From header on notification messages.=C2=A0 Mailing lis= ts which provide an "anonymous" function also use the list/mediat= or address as the From in order to hide the original poster's email add= ress.

Brandon=C2=A0
--90e6ba613a3c3ac1240503b003b5-- From nobody Tue Sep 23 10:09:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17C1A8721 for ; Tue, 23 Sep 2014 10:09:24 -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 ODiqPbaoULzv for ; Tue, 23 Sep 2014 10:09: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 14B091A876A for ; Tue, 23 Sep 2014 10:09:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 8F7F01C3942; Wed, 24 Sep 2014 02:09:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4CB881A325F; Wed, 24 Sep 2014 02:09:21 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <542090CE.7010102@dcrocker.net> References: <54208E47.9000705@crash.com> <542090CE.7010102@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 24 Sep 2014 02:09:21 +0900 Message-ID: <87zjdqxnzy.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5FHRvjrygQSNfuRtB9-fIe7QpHc Cc: dmarc@ietf.org, Steve Jones Subject: Re: [dmarc-ietf] Cataloging MLM manipulations of messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 17:09:24 -0000 > On 9/22/2014 2:01 PM, Steve Jones wrote: > > > > Is this useful? Hopeless? Somewhere in between? FWIW I am planning something similar, mining the archives here for suggestions for dealing with specific indirect mail issues. Mailing lists are my main area of expertise, so your work will complement mine. I'm wondering about the structure of such documents. Is it better to have separate pages or sections for them? Dave Crocker writes: > /Very/ useful, IMO. > > I suggest that we target developing this -- with assistance from the > rest of the email community -- and eventually publish it as an > informational RFC. I suspect such a thing will quickly become obsolete. I know that GNU Mailman, historically a "pure" mailing list manager, is gradually heading in the direction of an "enterprise communications solution", with a message store that can be accessed or added to from the web, mail, NNTP, or what have you. As it becomes more flexible in those ways, I suspect we're going to see more "semantic mail" (to coin a phrase) aspects. I'm not against it in principle, but I wonder if it's worth the effort. From nobody Tue Sep 23 10:16:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FFE1A86F5 for ; Tue, 23 Sep 2014 10:16:24 -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 m_Pd1SIQahDh for ; Tue, 23 Sep 2014 10:16:23 -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 50DD61A87E6 for ; Tue, 23 Sep 2014 10:14:28 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8NHDbiF017329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Sep 2014 10:13:40 -0700 Message-ID: <5421AA3B.3080607@dcrocker.net> Date: Tue, 23 Sep 2014 10:13:31 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" , dcrocker@bbiw.net References: <54208E47.9000705@crash.com> <542090CE.7010102@dcrocker.net> <87zjdqxnzy.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87zjdqxnzy.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]); Tue, 23 Sep 2014 10:13:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wkYfuX36lpineYfVGVnzjE2nw-E Cc: dmarc@ietf.org, Steve Jones Subject: Re: [dmarc-ietf] Cataloging MLM manipulations of messages 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, 23 Sep 2014 17:16:24 -0000 On 9/23/2014 10:09 AM, Stephen J. Turnbull wrote: > I suspect such a thing will quickly become obsolete. I'm sure it will. The point is that I think it can have utility to get folks thinking in terms of a potentially wide /range/ of choice, with the document giving a snapshot in time of choices that have been made. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 23 10:26:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA47C1A87BB for ; Tue, 23 Sep 2014 10:26:40 -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 7D6wwDmY37nN for ; Tue, 23 Sep 2014 10:26:39 -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 B740D1A87C4 for ; Tue, 23 Sep 2014 10:26:39 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 158471C3947; Wed, 24 Sep 2014 02:26:39 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 011791A325F; Wed, 24 Sep 2014 02:26:38 +0900 (JST) From: "Stephen J. Turnbull" To: Steven M Jones In-Reply-To: <5420A91B.2070102@crash.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <5420A91B.2070102@crash.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 24 Sep 2014 02:26:38 +0900 Message-ID: <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/htMH65YY8oOz6zOLpQUlMYycLjo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 17:26:41 -0000 Steven M Jones writes: > On 09/22/2014 03:17 PM, Josh Aberant wrote: > > > Who uses X-Original-From ? This is a real question, I'm not > > > aware of anyone who does. > > > > At Twitter we use the X-Original-From to route our security > > tickets with users within our ticketing system Salesforce. Users > > can open and reply to tickets by emailing what is a Google Groups > > alias. Google Groups (takes ownership of the From per our > > #RejectPolicy) and then I don't understand "our #RejectPolicy". What are you talking about? Surely not DMARC? That reject policy would be related to the From Domain of the user, not anything about Twitter. Or do users use an @twitter address for email they send? > > forwards those emails to Salesforce where they are automatically > > turned into support tix where we key off of the user's email > > address in the X-Original-From header. > > Interesting use case. Presumably the messages are flowing from Google > Groups to Salesforce over the Internet. So what we have is SMTP SMTP Customer (Author) ---> Google Group (Mediator) ---> Twitter (Destination) right? > However I would consider everything that happens after Salesforce > receives the messages as an application workflow. Indeed. But as long as these message don't leave the Twitter workflow, I'd consider all of this a private protocol that isn't really any of the IETF's business. > Messages the customer sees would be in-scope; Not if they don't go back through the Google Group. Nothing so far suggests that they do, and the word "security" suggests that they do not, to me anyway. > I'm not so sure about things happening between Google Groups and > Salesforce, In scope. > or within Salesforce. Not. > If we consider all the ways email messages are spindled, folded and > mutilated when they become part of an application workflow, I > expect we'd see an absolute explosion of additional weirdness... Not our business, though. Some of the specific mutilations may be, but the whole collection surely is not. We would consider specific instances case-by-case. From nobody Tue Sep 23 10:33:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2523D1A87C6 for ; Tue, 23 Sep 2014 10:33:03 -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 C3KGxHTD6cTh for ; Tue, 23 Sep 2014 10:33:01 -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 B48331A8739 for ; Tue, 23 Sep 2014 10:33:01 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2EED61C394C; Wed, 24 Sep 2014 02:33:01 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 185B31A325F; Wed, 24 Sep 2014 02:33:01 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 24 Sep 2014 02:33:00 +0900 Message-ID: <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ja1-TLUiNZlwE9OhnmICwpmtLKY Cc: "dmarc@ietf.org" , Roland Turner Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 17:33:03 -0000 Brandon Long writes: > But note that "similar" tools, such as bulletin-boards, have almost > always used the mediator as the From header on notification > messages. I'm not sure what you mean by "notification". I would take that to be things like a regular FAQ, Hold notification from moderation, DSNs for delivery issues, scheduled downtime, posting policy, and so on. These actually are authored by the BBS (or MLM). I don't understand what is interesting about "From is Author" in this context. Subscribers might confuse user posts with "official" notifications? > Mailing lists which provide an "anonymous" function also use the > list/mediator address as the From in order to hide the original > poster's email address. This is a private agreement between the MLM and the poster; the From munging is done on the authority of the poster. But this has never caused confusion that I know of. From nobody Tue Sep 23 10:47:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E301A1B76 for ; Tue, 23 Sep 2014 10:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, 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 VnHCKnssPaxD for ; Tue, 23 Sep 2014 10:47:30 -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 247751A1B6D for ; Tue, 23 Sep 2014 10:47:30 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s8NHlL9N079594 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2014 10:47:27 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s8NHlL9N079594 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1411494447; bh=xhgbwsl4oDlH30OSK+POqK5cApfudbR+J6uoT3r9uFw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=k3bBk3ptM53E/wfvHM2++7AVAErWJYP7AjI3R2saB51PBNm3N8rptf4zwIIuTGWu5 tcEjuH++yBiv53Nb83YZzmd6zAzwawSwoWoIZwPddkBg4mfoA95D3Z0paCiQsM4GKh cMZpCn63javj9UEkAMrNctC4nTNS/WU0yVcxY2Qs= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <5421B22C.40001@crash.com> Date: Tue, 23 Sep 2014 10:47:24 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <5420A91B.2070102@crash.com> <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/d4qzJUZgT5hyBQDFmG11U5tOGlw Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 17:47:31 -0000 On 09/23/2014 10:26 AM, Stephen J. Turnbull wrote: > On 09/22/2014 03:17 PM, Josh Aberant wrote: > > > > alias. Google Groups (takes ownership of the From per our > > > #RejectPolicy) and then > > I don't understand "our #RejectPolicy". What are you talking about? > Surely not DMARC? That reject policy would be related to the From > Domain of the user, not anything about Twitter. My reading was that this was some kind of configuration item within Google Groups. Therefore it's interesting if it is a normally available feature that any Google Group might use to alter the RFC5322.From or add an X-Original-From: header. Josh, anybody, feel free to correct/amplify... --S. From nobody Tue Sep 23 14:44:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA981A1BDA for ; Tue, 23 Sep 2014 14:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 fw3n27aQMsA0 for ; Tue, 23 Sep 2014 14:44:27 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3881A1BD2 for ; Tue, 23 Sep 2014 14:44:07 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id at20so10435123iec.37 for ; Tue, 23 Sep 2014 14:44:06 -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=QP/Un5p1vwcYmxjdNhr49p1T2K9RH1pEk7a2juVIndM=; b=Hmcju37jwXo3w+jT2hduq7TyfOm8c2l+cuefkeiCdONnzIQ+cMsdizwHSi/7YJ91s8 pvt2AI+9jTBmeDvF5mzrbaOYYVPx2iLB1H9iuTD67ZGzNEomz+CNdk7bF0KoMLwFuR4V 41hXSjAv1oZPPKmZfl5Z7JocnlxEeE0bDcHX/+iCpI8UKLlmqjc5vOreqkEKMiAZ01qy h7jU03XIJocL0poMEw+LhkUXh9YzQhWkvDLiyl1CmQmbNdS2mkOckHpq90fDvRt9+zNa 0i4IN1ElzRWOU026+ledRdGi9HA/vTMeNyDjZz1eNYrPw7D3okVu0GpubfTzYix4LSWs 50jw== 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=QP/Un5p1vwcYmxjdNhr49p1T2K9RH1pEk7a2juVIndM=; b=iwt1VSGp0xPeJYCp7lXdQwKgs4HIMm/hXnq2pp8VLEAsZbTBlVb2jbnOFS6eQE2EyO 8bO/xnzxAd2d+VUjYRLW6yrIo8/E9aY2Zw+DmFrTlINjXLPueRoRx8Ka2qB2zC0EyKpu kownuQEK6ira1urd6z5KUqGNcGYfYZsEzlZaalNva96ktHFaZD0RV4i9xnqlr4RFMuXT cwc8I89DJMWFnkt4Rhxtckyj75DiV0IzZPvdWWGg/oDyvSeRwZTao/G4KYyU2xpl/F6D jDqEuCKxGHQVo3FEbkkufTZHRRVdOe0I9cJKnMo9QDvE9fd1M2VXGUDAXOnpNac9VGMx DaFw== X-Gm-Message-State: ALoCoQnyhBEc77vF6fOlMSdKl9eEY/jOKARk0mgFxlJF6L9HwuuUaA8cm37ZTlUFK063+9axUBEV MIME-Version: 1.0 X-Received: by 10.42.121.146 with SMTP id j18mr5237060icr.48.1411508646543; Tue, 23 Sep 2014 14:44:06 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Tue, 23 Sep 2014 14:44:06 -0700 (PDT) In-Reply-To: <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 23 Sep 2014 14:44:06 -0700 Message-ID: From: Brandon Long To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=20cf301b694b79f2c00503c2773a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mpNmjD5vxwlpfIGPFg5kv9By4oc Cc: "dmarc@ietf.org" , Roland Turner Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 21:44:29 -0000 --20cf301b694b79f2c00503c2773a Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 10:33 AM, Stephen J. Turnbull wrote: > Brandon Long writes: > > > But note that "similar" tools, such as bulletin-boards, have almost > > always used the mediator as the From header on notification > > messages. > > I'm not sure what you mean by "notification". I would take that to be > things like a regular FAQ, Hold notification from moderation, DSNs for > delivery issues, scheduled downtime, posting policy, and so on. These > actually are authored by the BBS (or MLM). > > I don't understand what is interesting about "From is Author" in this > context. Subscribers might confuse user posts with "official" > notifications? > Sorry, they often term the messages as "notifications" instead of posts, when they actually contain the full post and author information/etc. Others only say "there has been a post" which is more a notification. I guess my overall point here is that some mailing lists evolved into BBS style hybrids (Y!Groups/GGroups), while some BBS's have evolved more mailing list type functionality "receive posts via email, respond to posts via email". The ones that started as MLM tend to use "from is author" and the ones that started as a BBS tend to use "from is mediator". Brandon --20cf301b694b79f2c00503c2773a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 23, 2014 at 10:33 AM, Stephen J. Turnbull <stephen@xemacs= .org> wrote:
Brandon Long writes:

=C2=A0> But note that "similar" tools, such as bulletin-boards= , have almost
=C2=A0> always used the mediator as the From header on notification
=C2=A0> messages.

I'm not sure what you mean by "notification".=C2=A0 I = would take that to be
things like a regular FAQ, Hold notification from moderation, DSNs for
delivery issues, scheduled downtime, posting policy, and so on.=C2=A0 These=
actually are authored by the BBS (or MLM).

I don't understand what is interesting about "From is Author"= in this
context.=C2=A0 Subscribers might confuse user posts with "official&quo= t;
notifications?

Sorry, they often term t= he messages as "notifications" instead of posts, when they actual= ly contain=C2=A0
the full post and author information/etc.=C2=A0 = Others only say "there has been a post" which is more
a= notification.

I guess my overall point here is th= at some mailing lists evolved into BBS style hybrids (Y!Groups/GGroups),
while some BBS's have evolved more mailing list type functional= ity "receive posts via email, respond to posts via email".=C2=A0 = The ones that started as MLM tend to use "from is author" and the= ones that started as a BBS tend to use "from is mediator".
=

Brandon
--20cf301b694b79f2c00503c2773a-- From nobody Tue Sep 23 14:58:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD9B1A2130 for ; Tue, 23 Sep 2014 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 YDWpOVIjI_wd for ; Tue, 23 Sep 2014 14:58:39 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74A81A01EF for ; Tue, 23 Sep 2014 14:58:38 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id r10so5429404igi.5 for ; Tue, 23 Sep 2014 14:58:38 -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=NLHoyZoVITHLjCBv5FTGQchpstJHEnywUPn9fZcEIWA=; b=VrDBYusXKSl1VqrDA5UV62reozb6jnl25Pnm+2wbuU1VyGP9pHzDvPsi0eZtkwb15+ zduxyKaJ5HsQ7ViAhY26XFMBHe0sfSLAwI87zy7GnCxP8vY0LfrlgC8eJ/bXOlQaa6D/ 3xQyuktPQiSSE8hVjh/ej8NDkR+D5J6dzYzBlJN7hsWqLtrFPZMNO4hslT3pAZvwHy6F P80Cpf2LM+E0JttAVn1E3cMF9gUfDRwDNfCYDyyB348NMRL9RV7Y4WDyEJDz5YyB95/J NL1ByS9Aeg3tLK1S3s3Km/XxPZdcNDV/uF09ypO6l0rPXhfq5O04TVq5Kh1gGZC2t0uD ptKg== 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=NLHoyZoVITHLjCBv5FTGQchpstJHEnywUPn9fZcEIWA=; b=DCO5Ud2Wqi+57Wx5VcDprj/yY/ylDrz1mn/WFdcxMh5h05UsLTcD/u6kTRgYXqe30t 09gjmeKLlmzSXWt4oBsbBaoV3B32PyAyJh0f5cALODSf7PT7dU/1NOe2l9CSqq6Ekp1s kypKvfKh6wtLlPcGIdkucOnaiYeIVT2Qjoi8S2PnT21HtooEV4emqsY4Hyfjv3Egv9iZ mkvJzocuWCsE8GmQGngl1k0eypL3rjji4YUvlMj/4XRzhwRhJ0jq6seVEjKOZ3tordcS yJU3vk9nO8shxyI9ODJNFhnLNW9Kskks9HLEBRaXMlq479lXccrHRP5o2uOXwHt9lLVc aDbw== X-Gm-Message-State: ALoCoQnJO+KyZY0jJ/oQIR4x7Fwrqnqx8TTf0JYcyVkPwFC78Q46Ekv3aGK/Xyu7ztXDjSXFyUvi MIME-Version: 1.0 X-Received: by 10.50.78.70 with SMTP id z6mr25894183igw.23.1411509518203; Tue, 23 Sep 2014 14:58:38 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Tue, 23 Sep 2014 14:58:38 -0700 (PDT) In-Reply-To: <5421B22C.40001@crash.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <5420A91B.2070102@crash.com> <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> <5421B22C.40001@crash.com> Date: Tue, 23 Sep 2014 14:58:38 -0700 Message-ID: From: Brandon Long To: Steven M Jones Content-Type: multipart/alternative; boundary=089e0112cfb06e3b8a0503c2abfb Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ql24idIHCpond8bobVdt8mkBgrg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 21:58:45 -0000 --089e0112cfb06e3b8a0503c2abfb Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 10:47 AM, Steven M Jones wrote: > On 09/23/2014 10:26 AM, Stephen J. Turnbull wrote: > > On 09/22/2014 03:17 PM, Josh Aberant wrote: > > > > > > alias. Google Groups (takes ownership of the From per our > > > > #RejectPolicy) and then > > > > I don't understand "our #RejectPolicy". What are you talking about? > > Surely not DMARC? That reject policy would be related to the From > > Domain of the user, not anything about Twitter. > > My reading was that this was some kind of configuration item within > Google Groups. Therefore it's interesting if it is a normally available > feature that any Google Group might use to alter the RFC5322.From or add > an X-Original-From: header. > Google Apps currently implements "aliases" as Google Groups (this has been true for a number of years now, prior to that there were separate aliases and groups). Because of this, a "support@twitter.com" address that redirects to internal users or an external CRM tool (salesforce) would be getting a groups rewritten message. These messages will not pass DKIM due to the rewriting, and so if they're from a DMARC p=REJECT/QUARANTINE domain such as yahoo.com, the from header will be rewritten to be the group name ( support@twitter.com) and the x-original-from will be the original sender. Its technically possible with Google Apps domain routing rules to reroute support@twitter.com to another address without passing through Groups and therefore DKIM would still pass... obviously SPF wouldn't, however. Doing this for a number of addresses would probably be more complicated than using Groups as the alias. Currently, Groups rewrites messages even if the group has no footer or subject prefix. We're investigating having an "alias" like mode for Groups which would allow DKIM messages to pass unscathed. In any case, support folks, especially when dealing with paying customers, tend to want to get all of the email, they don't want their nicely paying customers to not get support just because of spam false positives or the mail routing breaking dkim. I'm not sure if any of this is particularly relevant except to say that if one does from header rewriting, it is generally useful for there to be a machine readable and potentially standard place to find the original sender. That said, I also agree that displaying that address directly to the end user, especially without verification through some mechanism like OAR, would defeat the purpose of DMARC in the first place. If we knew how to display from addresses to users without making them phishing targets, we wouldn't have needed DMARC. Brandon --089e0112cfb06e3b8a0503c2abfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 23, 2014 at 10:47 AM, Steven M Jones <= smj@crash.com> wrote:
On 09/23/201= 4 10:26 AM, Stephen J. Turnbull wrote:
>=C2=A0 On 09/22/2014 03:17 PM, Josh Aberant wrote:
>
>=C2=A0 > > alias. Google Groups (takes ow= nership of the From per our
>=C2=A0 > > #RejectPolicy) and then
>
> I don't understand "our #RejectPolicy".=C2=A0 What are y= ou talking about?
> Surely not DMARC?=C2=A0 That reject policy would be related to the Fro= m
> Domain of the user, not anything about Twitter.

My reading was that this was some kind of configuration item within<= br> Google Groups. Therefore it's interesting if it is a normally available=
feature that any Google Group might use to alter the RFC5322.From or add an X-Original-From: header.

Google Apps= currently implements "aliases" as Google Groups (this has been t= rue for a number of years now, prior to that there were separate aliases an= d groups).=C2=A0 Because of this, a "support@twitter.com" address that redirects to internal user= s or an external CRM tool (salesforce) would be getting a groups rewritten = message.=C2=A0 These messages will not pass DKIM due to the rewriting, and = so if they're from a DMARC p=3DREJECT/QUARANTINE domain such as yahoo.com, the from header will be rewritten to b= e the group name (support@twitter.co= m) and the x-original-from will be the original sender.

<= /div>
Its technically possible with Google Apps domain routing rules to= reroute support@twitter.com to = another address without passing through Groups and therefore DKIM would sti= ll pass... obviously SPF wouldn't, however.=C2=A0 Doing this for a numb= er of addresses would probably be more complicated than using Groups as the= alias.

Currently, Groups rewrites messages even i= f the group has no footer or subject prefix.=C2=A0 We're investigating = having an "alias" like mode for Groups which would allow DKIM mes= sages to pass unscathed.

In any case, support folk= s, especially when dealing with paying customers, tend to want to get all o= f the email, they don't want their nicely paying customers to not get s= upport just because of spam false positives or the mail routing breaking dk= im.

I'm not sure if any of this is particularl= y relevant except to say that if one does from header rewriting, it is gene= rally useful for there to be a machine readable and potentially standard pl= ace to find the original sender.=C2=A0 That said, I also agree that display= ing that address directly to the end user, especially without verification = through some mechanism like OAR, would defeat the purpose of DMARC in the f= irst place.=C2=A0 If we knew how to display from addresses to users without= making them phishing targets, we wouldn't have needed DMARC.

Brandon=C2=A0
--089e0112cfb06e3b8a0503c2abfb-- From nobody Tue Sep 23 16:31:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAFE1A88AB for ; Tue, 23 Sep 2014 16:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-0P_f97ergG for ; Tue, 23 Sep 2014 16:31:16 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB0F1A1BC4 for ; Tue, 23 Sep 2014 16:31:16 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so156941pab.28 for ; Tue, 23 Sep 2014 16:31:16 -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 :message-id:references:to; bh=O9HNczRF4Q/TlGnOvXhT1Nv2B2oD6/lYhpc5Lx7oRRU=; b=aRg5eilFfYqViVYLvf37bu/gC1XuKttAIJj6SeeGGXHToWdGIyAZCLMaW9SH2V1JAo R+MUOqHdR+5YXFJTyoKcVJMO8NwWXN3v9nHCeRU6D8dUCYWeUwK9sNgG4KGhjfnnbA8L VAI2xYCA8AEhcVJHnA5acfxMhfHg5cp+KAlMHFWb5MY//dGtUcwGHx9zUBSJ8Aik6dx2 F2K7x1+lqK86BugoYLrKmq9S6JughQFz3Y5Gag8x+MxOy50vTBHFQwemei6sEP7SEBhN mabgbmkY7z/BCDrhMSxI7UmW2dcQrj/lKVD1iZDH17TZKkzkfjxRkx/pnD/w/c42hA+G BMcA== X-Received: by 10.66.234.105 with SMTP id ud9mr3969834pac.52.1411515076025; Tue, 23 Sep 2014 16:31:16 -0700 (PDT) Received: from [192.168.2.231] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id a14sm13026678pbu.32.2014.09.23.16.31.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 16:31:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_243AD75E-84D3-4E4E-BEEC-98F6E0EE60E0" From: Douglas Otis In-Reply-To: Date: Tue, 23 Sep 2014 16:31:13 -0700 Message-Id: <68F0BE02-BD21-46D7-9504-9B9A8ABE2DFA@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <5420A91B.2070102@crash.com> <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> <5421B22C.40001@crash.com> To: Brandon Long X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DClAJ53wtXV_sRJPBZWovBIRs7o Cc: "dmarc@ietf.org" , Douglas Otis , Steven M Jones Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Sep 2014 23:31:19 -0000 --Apple-Mail=_243AD75E-84D3-4E4E-BEEC-98F6E0EE60E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Brandon, The goal of DMARC is to ensure MTA rejection allows recipients of = messages containing a particular =46rom header better retains their = trust of not being a spoof. Any effort to constrain =46rom header fields handled by filtering rules = from other sources requires an authentication process that specifically = authorizes these various sources. Without an additional extension, = retaining a recognizable and trusted =46rom header field without = devolving back into unbounded spoofing is not possible. Having all = possible sources modify =46rom header fields in conflict with simplistic = DMARC assertions creates unproductive work without direct benefit likely = seen as being analogous to rearranging deck chairs. A few decades ago we managed all of AOL's inbound email along with = several other large ISPs. In comparison, minor resources would be = required to handle exceptions needed for AOL or other ISPs wishing to = implement DMARC while still permitting messages from various sources = such as IETF.org mailing-lists or Intuit.com invoices. This approach = ensures recognition of their =46rom is not tainted by abuse beyond their = control. http://tools.ietf.org/html/draft-otis-tpa-label-04 We would be happy to work with any interested ISPs. Only =46rom domain = owners receive DMARC feedback and know through examining domains which = third-party services are employed by their users. This would offer a = much safer scheme than that provided by munging the =46rom header field = which creates greater recipient confusion while lessening email's = general utility. Regards, Douglas Otis On Sep 23, 2014, at 2:58 PM, Brandon Long wrote: > On Tue, Sep 23, 2014 at 10:47 AM, Steven M Jones = wrote: > On 09/23/2014 10:26 AM, Stephen J. Turnbull wrote: > > On 09/22/2014 03:17 PM, Josh Aberant wrote: > > > > > > alias. Google Groups (takes ownership of the =46rom per our > > > > #RejectPolicy) and then > > > > I don't understand "our #RejectPolicy". What are you talking about? > > Surely not DMARC? That reject policy would be related to the From > > Domain of the user, not anything about Twitter. >=20 > My reading was that this was some kind of configuration item within > Google Groups. Therefore it's interesting if it is a normally = available > feature that any Google Group might use to alter the RFC5322.=46rom or = add > an X-Original-From: header. >=20 > Google Apps currently implements "aliases" as Google Groups (this has = been true for a number of years now, prior to that there were separate = aliases and groups). Because of this, a "support@twitter.com" address = that redirects to internal users or an external CRM tool (salesforce) = would be getting a groups rewritten message. These messages will not = pass DKIM due to the rewriting, and so if they're from a DMARC = p=3DREJECT/QUARANTINE domain such as yahoo.com, the from header will be = rewritten to be the group name (support@twitter.com) and the = x-original-from will be the original sender. >=20 > Its technically possible with Google Apps domain routing rules to = reroute support@twitter.com to another address without passing through = Groups and therefore DKIM would still pass... obviously SPF wouldn't, = however. Doing this for a number of addresses would probably be more = complicated than using Groups as the alias. >=20 > Currently, Groups rewrites messages even if the group has no footer or = subject prefix. We're investigating having an "alias" like mode for = Groups which would allow DKIM messages to pass unscathed. >=20 > In any case, support folks, especially when dealing with paying = customers, tend to want to get all of the email, they don't want their = nicely paying customers to not get support just because of spam false = positives or the mail routing breaking dkim. >=20 > I'm not sure if any of this is particularly relevant except to say = that if one does from header rewriting, it is generally useful for there = to be a machine readable and potentially standard place to find the = original sender. That said, I also agree that displaying that address = directly to the end user, especially without verification through some = mechanism like OAR, would defeat the purpose of DMARC in the first = place. If we knew how to display from addresses to users without making = them phishing targets, we wouldn't have needed DMARC. >=20 > Brandon=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_243AD75E-84D3-4E4E-BEEC-98F6E0EE60E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Brandon,

The goal of DMARC is to ensure MTA rejection = allows recipients of messages containing a particular =46rom header = better retains their trust of not being a = spoof.

Any effort to constrain =46rom header = fields handled by filtering rules from other sources requires an = authentication process that specifically authorizes these various = sources.  Without an additional extension, retaining a recognizable = and trusted =46rom header field without devolving back into unbounded = spoofing is not possible.  Having all possible sources modify =46rom = header fields in conflict with simplistic DMARC assertions creates = unproductive work without direct benefit likely seen as being analogous = to rearranging deck chairs.

A few decades ago = we managed all of AOL's inbound email along with several other large = ISPs.  In comparison, minor resources would be required to handle = exceptions needed for AOL or other ISPs wishing to implement DMARC while = still permitting messages from various sources such as IETF.org mailing-lists or Intuit.com invoices.  This approach = ensures recognition of their =46rom is not tainted by abuse beyond their = control.


We = would be happy to work with any interested ISPs.  Only =46rom = domain owners receive DMARC feedback and know through examining domains = which third-party services are employed by their users.  This would = offer a much safer scheme than that provided by munging the =46rom = header field which creates greater recipient confusion while lessening = email's general = utility.

Regards,
Douglas = Otis

On Sep 23, 2014, at 2:58 PM, Brandon Long = <blong@google.com> = wrote:

On Tue, Sep 23, 2014 at = 10:47 AM, Steven M Jones <smj@crash.com> wrote:
On 09/23/2014 10:26 AM, Stephen = J. Turnbull wrote:
>  On 09/22/2014 03:17 PM, Josh Aberant wrote:
>
>  > > alias. Google Groups (takes = ownership of the =46rom per our
>  > > #RejectPolicy) and then
>
> I don't understand "our #RejectPolicy".  What are you talking = about?
> Surely not DMARC?  That reject policy would be related to the = From
> Domain of the user, not anything about Twitter.

My reading was that this was some kind of configuration item = within
Google Groups. Therefore it's interesting if it is a normally = available
feature that any Google Group might use to alter the RFC5322.=46rom or = add
an X-Original-From: header.

Google = Apps currently implements "aliases" as Google Groups (this has been true = for a number of years now, prior to that there were separate aliases and = groups).  Because of this, a "support@twitter.com" address = that redirects to internal users or an external CRM tool (salesforce) = would be getting a groups rewritten message.  These messages will = not pass DKIM due to the rewriting, and so if they're from a DMARC = p=3DREJECT/QUARANTINE domain such as yahoo.com, the from header will be = rewritten to be the group name (support@twitter.com) and the = x-original-from will be the original = sender.

Its technically possible with Google = Apps domain routing rules to reroute support@twitter.com to another = address without passing through Groups and therefore DKIM would still = pass... obviously SPF wouldn't, however.  Doing this for a number = of addresses would probably be more complicated than using Groups as the = alias.

Currently, Groups rewrites messages even = if the group has no footer or subject prefix.  We're investigating = having an "alias" like mode for Groups which would allow DKIM messages = to pass unscathed.

In any case, support folks, = especially when dealing with paying customers, tend to want to get all = of the email, they don't want their nicely paying customers to not get = support just because of spam false positives or the mail routing = breaking dkim.

I'm not sure if any of this is = particularly relevant except to say that if one does from header = rewriting, it is generally useful for there to be a machine readable and = potentially standard place to find the original sender.  That said, = I also agree that displaying that address directly to the end user, = especially without verification through some mechanism like OAR, would = defeat the purpose of DMARC in the first place.  If we knew how to = display from addresses to users without making them phishing targets, we = wouldn't have needed = DMARC.

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

= --Apple-Mail=_243AD75E-84D3-4E4E-BEEC-98F6E0EE60E0-- From nobody Tue Sep 23 17:22:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0BB1A8963 for ; Tue, 23 Sep 2014 17:22:45 -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 ruzyxTsN7Ldd for ; Tue, 23 Sep 2014 17:22: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 B37E51A898A for ; Tue, 23 Sep 2014 17:22:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3BD541C3944; Wed, 24 Sep 2014 09:22:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 28E4B1A3260; Wed, 24 Sep 2014 09:22:42 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 24 Sep 2014 09:22:41 +0900 Message-ID: <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NP_Bygf-wDcRCnq8F7bKXp564mc Cc: "dmarc@ietf.org" , Roland Turner Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 24 Sep 2014 00:22:46 -0000 Brandon Long writes: > Sorry, they often term the messages as "notifications" instead of > posts, when they actually contain the full post and author > information/etc. I guess I'd need to see one to decide how I would classify them and how they fit into this WG as use cases. Examples? The only thing I can think of that fits that description is a bug tracker, and there the message is usually only one component of the information conveyed, and often is missing. In that case I would consider the actual message to be encapsulated in the outer message as delivered by the service, similar to the way I quoted you above -- this message is *from* me, *quoting* you. (Note that some authors/MUAs using a quoting style that looks much like RFC 822 headers, increasing the similarity.) I would consider that mode of operation to be deficient in a discussion list. I don't recall Groups using that mode, though -- they always have the author in From IIRC. From nobody Tue Sep 23 17:35:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9C71A898E for ; Tue, 23 Sep 2014 17:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.708 X-Spam-Level: *** X-Spam-Status: No, score=3.708 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_110=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 1G1cTOXNVmGn for ; Tue, 23 Sep 2014 17:35: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 29E891A898B for ; Tue, 23 Sep 2014 17:35:32 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9D2421C3931; Wed, 24 Sep 2014 09:35:31 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8E8AB1A3260; Wed, 24 Sep 2014 09:35:31 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <5420A91B.2070102@crash.com> <87y4taxn75.fsf@uwakimon.sk.tsukuba.ac.jp> <5421B22C.40001@crash.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 24 Sep 2014 09:35:31 +0900 Message-ID: <87r3z1yhws.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mE8CcYjs8cJzICYsdyu2G1XLQPY Cc: "dmarc@ietf.org" , Steven M Jones Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 24 Sep 2014 00:35:33 -0000 Brandon Long writes: > In any case, support folks, especially when dealing with paying > customers, tend to want to get all of the email, they don't want > their nicely paying customers to not get support just because of > spam false positives or the mail routing breaking dkim. Sure, but this isn't a problem if the support site ignores p=reject or treats it as p=quarantine. I think this is a twitter-side problem, not a Google-side problem or IETF problem. The "recipient MUST reject" aspect of DMARC is broken as far as I'm concerned. I personally consider "p=reject" to be informational, with preferred recipient semantics of "as far as we're concerned you can black-hole this message, and for your own good you probably should if you don't have *very* good reason to do otherwise *and* your own strong defenses against inauthentic mail." Support staff also can be trained not to get phished (is that really even necessary?) Presumably the remaining problem here would be the amount of inauthentic mail that gets through. Yahoo! admins speak of millions of messages per minute, which I find entirely plausible, and it certainly would knock down not just my tiny host, but probably my employer's whole network. From nobody Tue Sep 23 18:16:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F571A89A1 for ; Tue, 23 Sep 2014 18:16:48 -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 5502GqThHCuh for ; Tue, 23 Sep 2014 18:16:47 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF31D1A899A for ; Tue, 23 Sep 2014 18:16:46 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 13FAC956029; Tue, 23 Sep 2014 21:16:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1411521406; bh=B0wL2G1w0UWg14vszBo+m0q28FPyRTrGgClyW4g0tTo=; h=In-Reply-To:References:Subject:From:Date:To:From; b=0yjdWs96UmWoDe46Q7e9Gl3o1WdJSkOoaib330esR7vkJJ5RPMECNr9iKdkXS1hng UfR+DOzeeR2a61kiw3R45jIpyDOASw1IoQgVCJyzJuTiObsMMR4uHMi3eFxBpW3kMC y6RvvcCzl5EJwJBtDZoFOLSXF6c3oCmT4m8Pg6nA= Received: from [IPV6:2600:1003:b120:832e:38b0:eabb:5677:3002] (unknown [IPv6:2600:1003:b120:832e:38b0:eabb:5677:3002]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AA8B195601A; Tue, 23 Sep 2014 21:16:45 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 23 Sep 2014 21:16:42 -0400 To: "dmarc@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/U7AxLKOhUpMXj9jtOQthLjJmwhQ Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 24 Sep 2014 01:16:48 -0000 On September 23, 2014 8:22:41 PM EDT, "Stephen J. Turnbull" wrote: >Brandon Long writes: > > > Sorry, they often term the messages as "notifications" instead of > > posts, when they actually contain the full post and author > > information/etc. > >I guess I'd need to see one to decide how I would classify them and >how they fit into this WG as use cases. Examples? > >The only thing I can think of that fits that description is a bug >tracker, and there the message is usually only one component of the >information conveyed, and often is missing. In that case I would >consider the actual message to be encapsulated in the outer message as >delivered by the service, similar to the way I quoted you above -- >this message is *from* me, *quoting* you. (Note that some >authors/MUAs using a quoting style that looks much like RFC 822 >headers, increasing the similarity.) > >I would consider that mode of operation to be deficient in a >discussion list. I don't recall Groups using >that mode, though -- they always have the author in From IIRC. Except at the very least Google Groups. Scott K From nobody Tue Sep 23 22:09:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA91A8A82 for ; Tue, 23 Sep 2014 22:09: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 8ytuPaW5FohQ for ; Tue, 23 Sep 2014 22:09:41 -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 932191A19FD for ; Tue, 23 Sep 2014 22:09:41 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2A8E51C39CE; Wed, 24 Sep 2014 14:09:40 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1E96B1A3260; Wed, 24 Sep 2014 14:09:40 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 24 Sep 2014 14:09:39 +0900 Message-ID: <87ppely57w.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rgTdpzeJmFumcwsVp5TztRI5iW8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 24 Sep 2014 05:09:43 -0000 Scott Kitterman writes: > On September 23, 2014 8:22:41 PM EDT, "Stephen J. Turnbull" wrote: > >I don't recall Groups using that mode, though > >-- they always have the author in From IIRC. > > Except at the very least Google Groups. If you are talking about their workaround for DMARC p=reject From Domains, that's irrelevant to my point. This subthread was discussing how modern lists/bbses/forums have evolved over time. What I am saying is that in the absence of DMARC p=reject at public mailbox providers, as far as I know Google Groups and Yahoo Groups normally put the poster's name and address in the From field. This is 100% confirmed by a sample of nearly 100 of my personal archives of GG and YG mailing lists.[1] If you have a counterexample, I'd love to hear about it, in enough detail to determine whether the From-munging was done with at least implicit authorization by the posters. Eg, subscribing to an anonymous mailing list described as such on its information page constitutes implicit authorization. Posting to a list which changed to from-munging as a DMARC mitigation, without an explicit announcement of this ToS change, is not. Footnotes: [1] As it turns out, my GG lists have *zero* Yahoo and AOL posters, and my YG lists most recent post was 2008/8/12, so mostly irrelevant to recent policy. From nobody Tue Sep 23 22:10:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6D1A8A88 for ; Tue, 23 Sep 2014 22:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.786, 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 8YAGpY5BAi-k for ; Tue, 23 Sep 2014 22:09:59 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93551A19FD for ; Tue, 23 Sep 2014 22:09:58 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id x19so10442418ier.8 for ; Tue, 23 Sep 2014 22:09:57 -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=qQYdSVtY5xxFlR3Ao60ToOieD7ujawPXA/pa12LB2Bk=; b=WTOeKkIIjsH0NGBwUzbGZihJtzoPXHVPQai52cJCcfDcAcuhIU+71EOWv1qmEnLFpE 6bxj4JaY63mWqCIGLOd/ZYdZF3xBGa/pY8awQlDRKB0bakOHyMgqPL9QAvoMRrTu+kgs MJ+Dy+E8pmKJUHmW+BXNAsU0nhyXAwmuJGiB0u4eSkuS1Cudr/1VnSzGIKkbt556zR2q qp2qJLUwbX4tpDT3A13mcz3l0zeelkIneTF4/1hvgIx8/3cLBuSYGWFQAkALa1+pl1yW TJJR7KJpk710/4h9k+zlVwVOs+vo58/kJoQps3IoQ/4nE709oRBRT0CVtAAQpH3w1p28 gTrg== 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=qQYdSVtY5xxFlR3Ao60ToOieD7ujawPXA/pa12LB2Bk=; b=XfKr4f1OSAE0u6kCQ1giZ8qk+Xw0wgbEo3uAErs8JDrrumM5vX3Gb1ZqoXdUjC966t 3ZdQupsEjnMW3NZ5xIJ8dScCYaEZEPVOR0aNvjYUvHZ2kxxI9S/vQrTYjLtcDyrhnl05 8IRItTfTu8n4cWnMmmsfqTWQyiLt/3Qdz6/dXbTYOQbc6svu/CKGp2XRUEOkQgG7V/BT 3VSR5pZU3LN7+e5FawClav7lnVsqp7usUSJP6ArUjFdP6+DjaAOy6XC5RBWwIB3Rwzeb jDLi+irIJl5uBhr5AiaxwXcNjdMC9MsmZ6VVHnAeSc9YDGChO/X0T8s8lUYz7aZ5zz6Q ciMQ== X-Gm-Message-State: ALoCoQlt69DwE+D9ytIRJk6Vp6nVXJwLFkio4foin1HKdOIfNj9NeLAITgLw7vVrIyDBOl1Zdble MIME-Version: 1.0 X-Received: by 10.42.227.10 with SMTP id iy10mr8226482icb.3.1411535397797; Tue, 23 Sep 2014 22:09:57 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Tue, 23 Sep 2014 22:09:57 -0700 (PDT) In-Reply-To: References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 23 Sep 2014 22:09:57 -0700 Message-ID: From: Brandon Long To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c3e50ef974f10503c8b1cf Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ro0MJHrVK6rlbQz6f0YhFKmCRrQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 24 Sep 2014 05:10:00 -0000 --001a11c3e50ef974f10503c8b1cf Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 6:16 PM, Scott Kitterman wrote: > On September 23, 2014 8:22:41 PM EDT, "Stephen J. Turnbull" < > stephen@xemacs.org> wrote: > >Brandon Long writes: > > > > > Sorry, they often term the messages as "notifications" instead of > > > posts, when they actually contain the full post and author > > > information/etc. > > > >I guess I'd need to see one to decide how I would classify them and > >how they fit into this WG as use cases. Examples? > I'll see if I can find some, its been years since I used any of them. >The only thing I can think of that fits that description is a bug > >tracker, and there the message is usually only one component of the > >information conveyed, and often is missing. In that case I would > >consider the actual message to be encapsulated in the outer message as > >delivered by the service, similar to the way I quoted you above -- > >this message is *from* me, *quoting* you. (Note that some > >authors/MUAs using a quoting style that looks much like RFC 822 > >headers, increasing the similarity.) > Sure, a bunch of bug / case / support type systems work like that. Notifications from FB, G+ and Google document comments also work like that. >I would consider that mode of operation to be deficient in a > >discussion list. I don't recall Groups using > >that mode, though -- they always have the author in From IIRC. > > Except at the very least Google Groups. > Google Groups has had "private" groups where email addresses are private, so messages always came "from" the group. The product forums in our help center work in this mode, for example. Yahoo Groups has a similar feature. I'm not sure if you can actually post to the groups via email in that mode, however. Obviously, more recently, both Google and Yahoo have started re-writing the >From header for messages posted from DMARC domains. I think Y!Groups is actually doing this for all messages now, not just DMARC affected domains... and it also uses an X-Original-From header. Brandon --001a11c3e50ef974f10503c8b1cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 23, 2014 at 6:16 PM, Scott= Kitterman <sklist@kitterman.com> wrote:=
= On September 23, 2014 8:22:41 PM EDT, "Stephen J. Turnbull" <<= a href=3D"mailto:stephen@xemacs.org" class=3D"cremed">stephen@xemacs.org> wrote:
>Brandon Long writes:
>
> > Sorry, they often term the messages as "notifications" = instead of
> > posts, when they actually contain the full post and author
> > information/etc.
>
>I guess I'd need to see one to decide how I would classify them and=
>how they fit into this WG as use cases.=C2=A0 Examples?
=

I'll see if I can find some, its been = years since I used any of them.

>The only thing I can think of that fits that description is a bug
>tracker, and there the message is usually only one component of the
>information conveyed, and often is missing.=C2=A0 In that case I would<= br> >consider the actual message to be encapsulated in the outer message as<= br> >delivered by the service, similar to the way I quoted you above --
>this message is *from* me, *quoting* you.=C2=A0 (Note that some
>authors/MUAs using a quoting style that looks much like RFC 822
>headers, increasing the similarity.)
<= br>
Sure, a bunch of bug / case / support type systems work like = that.

Notifications from FB, G+ and Google documen= t comments also work like that.

>I would consider that mode of operation to be deficient in a
>discussion list.=C2=A0 I don't recall <commercial service> Gr= oups using
>that mode, though -- they always have the author in From IIRC.

Except at the very least Google Groups.
Google Groups has had "private" groups where email a= ddresses are private, so messages always came "from" the group.= =C2=A0 The product forums in our help center work in this mode, for example= .=C2=A0 Yahoo Groups has a similar feature.=C2=A0 I'm not sure if you c= an actually post to the groups via email in that mode, however.
<= br>
Obviously, more recently, both Google and Yahoo have started = re-writing the From header for messages posted from DMARC domains.=C2=A0 I = think Y!Groups is actually doing this for all messages now, not just DMARC = affected domains... and it also uses an X-Original-From header.
<= br>
Brandon
--001a11c3e50ef974f10503c8b1cf-- From nobody Wed Sep 24 19:25:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB4A1A1B9E for ; Wed, 24 Sep 2014 19:25:35 -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 fzG-SwaHdgkN for ; Wed, 24 Sep 2014 19:25:34 -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 44A161A6F04 for ; Wed, 24 Sep 2014 19:25:34 -0700 (PDT) Received: (qmail 5227 invoked from network); 25 Sep 2014 02:25:33 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Sep 2014 02:25:33 -0000 Date: 25 Sep 2014 02:25:10 -0000 Message-ID: <20140925022510.51780.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: http://mailarchive.ietf.org/arch/msg/dmarc/0ZkCHPNb0nI3tO9wQxmcsjI_f2g Cc: blong@google.com Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 25 Sep 2014 02:25:35 -0000 >while some BBS's have evolved more mailing list type functionality "receive >posts via email, respond to posts via email". The ones that started as MLM >tend to use "from is author" and the ones that started as a BBS tend to use >"from is mediator". Having been there at the time, I'm fairly confident that the BBS mail gateways that put the list name on the From: line did so out of expedience on tiny computers with terrible programming environments, rather than any metaphysical belief that the list was somehow Frommier than the author. We've been using mailing lists on the Internet and other systems (uucp and such) for close to 40 years. We wrote our own software, and at any point we could easily have put the list name on the From: line, if we thought it was a good idea. It wasn't in the 1970s, 1980s, 1990s, and 2000s, and it still isn't now. I don't see any utility in beating this particular equine corpse any more. It's possible that it may turn out to be the least bad of a set of unpleasant options, but that still doesn't make it a good idea. R's, John From nobody Fri Sep 26 18:12:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564621A00CA for ; Fri, 26 Sep 2014 18:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 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, 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 iidNn4nfg6u1 for ; Fri, 26 Sep 2014 18:12:08 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2F71A00BB for ; Fri, 26 Sep 2014 18:12:08 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fb1so2239822pad.39 for ; Fri, 26 Sep 2014 18:12:07 -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=OaCfAMJpYsMGVdvX2hcIHOEROG2CC4zA3tNPpyIKUYk=; b=ptxUISKPLQVioqxW211MNwN+xFmn21/sHiMQVCRWg7oc8HeyU9l4PEeFA5svRTWtLH A5fOPnrzBcGg5xhU/ukTx9aLKorcuKfa83GIIcHq3g3HZvFbMrpJlSwF0yw7x+WBAWVe pET8DEOtMWAXt6OoMw5zgEVvoeFks6VmITMvmtpj0sXvExkT/2VfoxPF6+yxFqGKFo/w bjNW288URpnXU5XsQj8RiKMg2rMLQHMnrKxqzBHMQFxjNuNaUcFVAQGKltdvVjxFOfxR HkQS71gAAhFM3x9D9jhKKu3WtuO7ubrxxia5vg8w+4v5n6+5BkKA5aHEduvdE7lsYKDC YWeA== X-Received: by 10.68.218.234 with SMTP id pj10mr18772091pbc.27.1411780327409; Fri, 26 Sep 2014 18:12:07 -0700 (PDT) Received: from [192.168.2.225] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id ty8sm6065947pab.26.2014.09.26.18.12.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Sep 2014 18:12:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Fri, 26 Sep 2014 18:12:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B713372-8B6C-4D43-9868-E0C3F4374634@gmail.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> To: Brandon Long X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xopTj_0MuPs0nHqrnxrfeo8hOkk Cc: "dmarc@ietf.org" , Scott Kitterman , Douglas Otis Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 27 Sep 2014 01:12:09 -0000 On Sep 23, 2014, at 10:09 PM, Brandon Long wrote: > Obviously, more recently, both Google and Yahoo have started = re-writing the =46rom header for messages posted from DMARC domains. I = think Y!Groups is actually doing this for all messages now, not just = DMARC affected domains... and it also uses an X-Original-=46rom header. Dear Brandon, X-Original-=46rom is not standard and is misleading. Perhaps we should = attempt to standardize this header. Doing so could provide people a = better idea where this change is headed. For example, instead of X-Original-From: this could be Submitter: = Rather than defining this header field per RFC4405, simply state it = should represent the original author and ignore PRA concepts based on = users re-introducing messages where tracking its path proved = ineffective.=20 It seems the proper approach for making such a change would have been to = expect those benefiting to carry the resulting burden and suffer through = the transition. For example, instead of restricting the =46rom header = field and changing its role, a new header could have been added such as = Submitting-Domain: restricted by DMARC policy. Of course many would = argue the phishing problem must be addressed by restricting a normally = visible and trusted header-field; Hence the use of From. Defining a Submitter header field would give mailing lists, and invoice = and notification vendors a clear and concise indication what change is = needed. It will take several years before this new header is likely = visible and for that header field to then become a phishing target. = Just perhaps filtering rules for mailing lists will tend to thwart its = abuse. A means to informally federate third-party domains might also be = effective at defending this new header if needed.=20 Regards, Douglas Otis =20 >=20 > Brandon > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Sep 27 01:15:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2231A1A67 for ; Sat, 27 Sep 2014 01:15:25 -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 jDYgK9NawVy8 for ; Sat, 27 Sep 2014 01:15: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 1DE8C1A0052 for ; Sat, 27 Sep 2014 01:15:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 827491C392C; Sat, 27 Sep 2014 17:15:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 746E51A3260; Sat, 27 Sep 2014 17:15:21 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <5B713372-8B6C-4D43-9868-E0C3F4374634@gmail.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> <5B713372-8B6C-4D43-9868-E0C3F4374634@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 27 Sep 2014 17:15:21 +0900 Message-ID: <87y4t5wkbq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9kKH8YtU5TZHbqtT_xRSHjMNh4Y Cc: Brandon Long , "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 27 Sep 2014 08:15:25 -0000 Douglas Otis writes: > X-Original-From is not standard and is misleading. Aside from BCP 178, I don't see what is unclear about it. It quite obviously indicates the originator's From field has been altered, and the [X-]Original-From field contains what the originator put in the >From field. Later alterations would leave [X-]Original-From alone, I suppose, unless they actually want to claim authorship, in which case they would delete. If you want a history in the case of not claiming authorship, use a References-like mechanism and call the field "From-History". But that seems pointless to me. > For example, instead of X-Original-From: this could be Submitter: I thought we already had Submitter semantics, but in RFC 5322 the field is spelled "Sender". In any case, that confusion seems far more problematic to me than any that could arise from Original-From. > Rather than defining this header field per RFC4405, Now you're seriously confusing me. RFC 4405 is an SMTP extension and defines no header fields at all. The concept of "responsible submitter" defined there does not correspond accurately to an RFC 5322 originator field (specifically in the case where RFC4405.SUBMITTER is not the RFC5322.Sender, and does not wish to represent itself as author of the message). > Defining a Submitter header field would give mailing lists, and > invoice and notification vendors a clear and concise indication > what change is needed. No change is needed. This is useless to indirect mailers until MUAs display it. Scott assures us they never will, and because of lags in adoption by MUA maintainers and then further lags in upgrading by users, I would expect a large minority of users to be unable to see this field after a decade even if his prediction is falsified. > A means to informally federate third-party domains might also be > effective at defending this new header if needed. If we had "federation" we'd just "defend" the From field. From nobody Sat Sep 27 14:42:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FF31A19F3 for ; Sat, 27 Sep 2014 14:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4xhfw1BfYlEP for ; Sat, 27 Sep 2014 14:42:28 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818B51A0406 for ; Sat, 27 Sep 2014 14:42:28 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id kx10so989123pab.23 for ; Sat, 27 Sep 2014 14:42:28 -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=jPiU+XNNI95m4/5JVwwiraA8xE4DmnRWQewhWFaOEVQ=; b=K8H3+wuhazAZon848z7B66F3m+HNpVpYMIpjnPSgFXHv8JCXXoTr7VIvtbelVO+VMm +wLXtI8Nb3gDLpVlzjQTllvUUClsBaLqQmBCZlqWCr997Hmp1UQMnWWkp9R6GHS/0uEk myNN+xoAWQrm34K+4lp1La42DcM4qUf51GgN0a8amTHDp+2S0XFuaBDRx1ufhoUZ0Z28 eVbQ9d/xjCXAN8z3DQtL98WFcbokqjaQWfJqWYHNcMCANVBuGbu0TpkTKwxdyWfLeMy8 5hCTLpyGyQe5Miz8VSqrz+hwrCh/IuXTy6+j2CFHQK5rLD0n0zYeogSilPapCHZJNGCr puOg== X-Received: by 10.70.126.9 with SMTP id mu9mr58576813pdb.151.1411854148160; Sat, 27 Sep 2014 14:42:28 -0700 (PDT) Received: from [192.168.2.131] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id uu17sm3049308pab.43.2014.09.27.14.42.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Sep 2014 14:42:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <87y4t5wkbq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 27 Sep 2014 14:42:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B262963-4698-42CD-9498-E2F320F64B2E@gmail.com> References: <1619146.fJgkRhlbM5@scott-latitude-e6320> <63AEE13F-7EF4-4999-A347-8628FD10107C@wordtothewise.com> <5095831.vR8OcjAh40@scott-latitude-e6320> <5417A8CC.9070204@rolandturner.com> <20E2F109-FBBE-477C-BDBB-1288BF39E40B@wordtothewise.com> <5418B1C5.5030604@rolandturner.com> <877g132hgi.fsf@uwakimon.sk.tsukuba.ac.jp> <541AD947.8010509@rolandturner.com> <874mw50z0p.fsf@uwakimon.sk.tsukuba.ac.jp> <541BB0E2.9090509@rolandturner.com> <87wq8uxmwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87sijhyii6.fsf@uwakimon.sk.tsukuba.ac.jp> <5B713372-8B6C-4D43-9868-E0C3F4374634@gmail.com> <87y4t5wkbq.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ncuyd75QTzCPucOBvY5US_Oh1mQ Cc: Brandon Long , "dmarc@ietf.org" , Scott Kitterman , Douglas Otis Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 27 Sep 2014 21:42:32 -0000 On Sep 27, 2014, at 1:15 AM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> X-Original-=46rom is not standard and is misleading. >=20 > Aside from BCP 178, I don't see what is unclear about it. It quite > obviously indicates the originator's =46rom field has been altered, = and > the [X-]Original-=46rom field contains what the originator put in the > =46rom field. Later alterations would leave [X-]Original-=46rom = alone, I > suppose, unless they actually want to claim authorship, in which case > they would delete. >=20 > If you want a history in the case of not claiming authorship, use a > References-like mechanism and call the field "From-History". But that > seems pointless to me. Dear Stephen, Thank you for your thoughtful response, however there are a few = problematic points. Use of DMARC on non-transactional email, without acceptable alternatives = to ensure delivery, requires the =46rom originator field definition to = represent that of a third-party without clarity where or when this = occurred, which might happen more than once within a delivery path. = With =46rom now muddled, From-History, Original-From, Resent-=46rom or = any term suggesting a version of a =46rom field carried forward can not = offer role clarity. >> For example, instead of X-Original-From: this could be Submitter: > =20 > I thought we already had Submitter semantics, but in RFC 5322 the > field is spelled "Sender". In any case, that confusion seems far more > problematic to me than any that could arise from Original-From. True, but DMARC specifically does not use Sender. It only uses =46rom = with the intent of Sender being ignored. Nor does Original-=46rom shed = any light on this header-field's role once =46rom has been muddled. >> Rather than defining this header field per RFC4405, >=20 > Now you're seriously confusing me. RFC 4405 is an SMTP extension and > defines no header fields at all. The concept of "responsible > submitter" defined there does not correspond accurately to an RFC 5322 > originator field (specifically in the case where RFC4405.SUBMITTER is > not the RFC5322.Sender, and does not wish to represent itself as > author of the message). Should have said please completely ignore RFC4405. Call the header field = Originator or On-Behalf-Of, if you don't like Submitter or you find it = too confusing. The basic point is there should not be a rote carrying = forward of a potentially muddled =46rom header field into a newly = defined header field attempting to preserve originator roles played by = its contained identifiers. DMARC does not use this new field, so it can = safely carry forward this critical role. In other words, carry forward = the Originator header if present rather than a now questionable From.=20 >> Defining a Submitter header field would give mailing lists, and >> invoice and notification vendors a clear and concise indication >> what change is needed. >=20 > No change is needed. This is useless to indirect mailers until MUAs > display it. Scott assures us they never will, and because of lags in > adoption by MUA maintainers and then further lags in upgrading by > users, I would expect a large minority of users to be unable to see > this field after a decade even if his prediction is falsified. Unfortunately DMARC when not restricted to transactional messaging, = requires some kind of change, but X-Original-=46rom represents a poorly = considered choice. You really mean =46rom has become useless for = indirect mailers. Sender does not handle what might be contained = within the =46rom header field nor is this header field always seen. = Originator can act as a safer alternative where Sender is unable to = convey the appropriate role anyway.=20 >> A means to informally federate third-party domains might also be >> effective at defending this new header if needed. >=20 > If we had "federation" we'd just "defend" the =46rom field. Agreed. For any large ISP interested, we would be happy to setup the = needed infrastructure for them to make this happen. Alas, these large = vendor's dominance can force change on others who will suffer through = the transition rather than on those instigating the change. The = justification might be market dominance makes right. :^( For OS X Mail, Choose Mail > Preferences, click Viewing, then choose All = from the =93Show header detail=94 pop-up menu. To customize header details, choose Custom from the pop-up menu, click = Add (+), enter the field name, then click OK. For Outlook, iOS Mail or others there are fewer options without changing = email clients. It seems this will make someone some money. Some clients = can only show all headers which would be unfriendly for those wanting to = know who authored the message after circumnavigating all the DMARC foo = aimed at keeping them safe with their high value transactional messages. Regards, Douglas Otis From nobody Mon Sep 29 11:23:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557E21A1BFA for ; Mon, 29 Sep 2014 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13OaW0zeYFTN for ; Mon, 29 Sep 2014 11:23:02 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272171A90F7 for ; Mon, 29 Sep 2014 11:23:02 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id g10so289821pdj.18 for ; Mon, 29 Sep 2014 11:23:01 -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=tIdDSr+3Re3aJFJg6HNMEoEY7pGc7iKDyAZklho5Qv0=; b=fQ3nlnrM0BzPQdkXonjdD+PEX0qHMbLc4y/Tn0k3VmbGvYIe8MhzeiBAkWgM+Q103C XrBwDjO0LjnzdeXTSK4+RkvwpyafNd1vXCb3Gx72u8a9iYS5512lxhPQqipE2S7UuWyA U0TsWufrwvYCp50Rl4t9YiWgoAfSMq8Yei35b8TUlkmHrNxUjjNR1WvWEcHkEyRl80Bt ST4uytP2CQXu+8dkcuGLTyUFQVDsMigc/n4+As6Nb147ffhxJKHl+xA/xmlRtbdHqRw+ DiGWk5JM1SBLONW7iNi9IRsRyMf3xuh4Mba0zcZ/7VYGT8P6DvOi2PtpivYaT8PWR3RS fo/Q== X-Received: by 10.67.14.165 with SMTP id fh5mr2828462pad.2.1412014981850; Mon, 29 Sep 2014 11:23:01 -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 dq10sm394392pac.7.2014.09.29.11.22.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 11:23:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Mon, 29 Sep 2014 11:22:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> To: Josh Aberant X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mRGcyOO17dZct6uRGtRV586uiv0 Cc: dmarc@ietf.org, Douglas Otis Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 Sep 2014 18:23:03 -0000 On Sep 22, 2014, at 3:17 PM, Josh Aberant wrote: > > Who uses X-Original-=46rom ? This is a real question, I'm not aware = of > > anyone who does. >=20 > At Twitter we use the X-Original-=46rom to route our security tickets = with users within our ticketing system Salesforce. Users can open and = reply to tickets by emailing what is a Google Groups alias. Google = Groups (takes ownership of the =46rom per our #RejectPolicy) and then = forwards those emails to Salesforce where they are automatically turned = into support tix where we key off of the user's email address in the = X-Original-=46rom header. Dear Josh, =46rom (normally contains a mailbox representing the author) might be = substituted for a proxy domain to satisfy DMARC acceptance requirements = typically needed for non-transactional email. As DMARC affects normal = use of From, greater care is required to retain the original role = defined for From. In other words, the replacement header field should = not be seen to represent a Resent-=46rom or a trace header structure, = since this should occur only once within the path of a message since the = identifier for the original role will not have changed. This is a working group, so we should be thinking in terms of doing what = is proper and right. As has been pointed out by BCP178 or RFC6648, = X-Original-=46rom creates other problems specifically due to a lack of = defined roles and how or when this new header is to be added and used. = Any new header field should be properly defined. Should this header be = introduced every time a change is made to satisfy DMARC acceptance = requirements? What are the security threats related to its use? = Alternatively, should DMARC define a re-writing scheme such as = dmarc-noncompliant: where perhaps the =46rom is presented by RFC6854 = defined group syntax? It might be nice to have DMARC embracing use of a = special group syntax, since it seems recognizable special group would be = fairly unlikely to be useful spoofing users. From: Dmarc-Noncompliant:ben@example.com; Regards, Douglas Otis =20 =20= From nobody Mon Sep 29 23:58:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549CE1A0242 for ; Mon, 29 Sep 2014 23:58:47 -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 c2Gc5c33Cvwz for ; Mon, 29 Sep 2014 23:58:45 -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 0255E1A0240 for ; Mon, 29 Sep 2014 23:58:44 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 76E141C38FA; Tue, 30 Sep 2014 15:58:43 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 62B561A2697; Tue, 30 Sep 2014 15:58:43 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 30 Sep 2014 15:58:43 +0900 Message-ID: <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yFEls2M4bNYGKIAWfn3G_M4rDyk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:58:47 -0000 Douglas Otis writes: > >From (normally contains a mailbox representing the author) might > >be substituted for a proxy domain to satisfy DMARC acceptance > >requirements typically needed for non-transactional email. As > >DMARC affects normal use of From, This is rather inaccurate description of the situation. First, "From" doesn't just "normally" represent the author -- that is the RFC definition of this REQUIRED field. Second, DMARC is basically an informational protocol. Only the "p" attribute defines "acceptance requirements", and only if non-default. Third, even "p=reject" does not "affect use of From". It affects *delivery* of syntacticly and semantically conformant Internet messages. (DMARC is a private protocol by agreement between MXes, and absent a change to the author's host's terms of service, I don't see why anybody other than participating MXs should be expected to know or do anything about it.) > It might be nice to have DMARC embracing use of a special group > syntax, A reasonable suggestion in context of other proposals. > since it seems recognizable special group would be fairly unlikely > to be useful spoofing users. But I have to disagree with your premise. To the extent that it *is* recognizable, it is likely to be "recognized" as an alternative form of "From" applied to some *authentic* authors for unknown reason, not as evidence of inauthenticity. Because spam filtering removes many inauthentic messages and mailing lists generate large numbers of authentic messages, the conservative assumption (from the point of view of security against phishing) is that, as seen by recipients, most authors so marked will indeed be authentic. Furthermore, I believe spoofable users *will* get spoofed through such devices. For example, in Japan, where I live, a standard fraud starts with a phone call, "Hello? It's me, it's me, and I need $3000 in a big hurry!" "Oh, Johnny, you poor thing, do you have a cold? Your voice sounds funny! Be more careful. Where should I take the money? I can get it in 30 minutes." I am not kidding; in bad years victims lose hundreds of millions of dollars to this scam. I see no reason to suppose the demographic that falls prey to this fraud is absent elsewhere, or that it contains no email users. It would be very useful to know what the "conversion rate" for phishing is for three cases of interest: A. a phishing message from a non-acquaintance, displayed by the MUA "in the usual way" (eg, with "avatar" from the contact list); B. a phishing message from an acquaintance, displayed by the MUA "in the usual way"; and C. a phishing message from an acquaintance, with a different display containing a familar mitigation. (The user may not be aware that it is a mitigation, of course, expecially if they have experience with Outlook and similar MUAs that apply a similar mitigation to Sender.) But without data, I am quite sure that C lies strictly between A and B, and I think the conservative stance is to assume that it's too close to B ("acquaintance phishing") to risk until data shows otherwise. Note that we *do* have data on the ability of the high tech spammers and scammers to push millions of exploitative messages in minutes. And *they* probably have data on conversion rates. If that data shows an advantage to Type C messages, it would be highly irresponsible to fail to prepare for a sudden, directed onslaught of Type C messages once such mitigations become common. From nobody Tue Sep 30 16:08:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8807C1ACCFE for ; Tue, 30 Sep 2014 16:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r26PVJ2PHD-v for ; Tue, 30 Sep 2014 16:08:45 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C00E1ACC83 for ; Tue, 30 Sep 2014 16:08:45 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so8367782pab.26 for ; Tue, 30 Sep 2014 16:08:45 -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 :message-id:references:to; bh=2QFSEtJX9c0ZdF5eYEFB8HHw+5aMclknyj48i0eUDVA=; b=Tu5ZKrq1tuuzWIHxLqac/HoSLTqlzsdNzEOl+to4fVJ2tLmnw1gW7Xc9yvcgCJ5+r6 oyrvcf61I8vPezqGCu32dyRo0gl7bZdljhd70vW7cLQFee61tJ9XFs21ZO7SvOEz0yZc 87Zpy2gVkox3OPSiArWTvhAqcReekBExWe8bdgqkBt9rVVfOY6NRnpatNYg8Vuge77C+ iqEoiVtlWNA3svZDPtJHbmjGDOqZuLzRdurxpyE2hwW8iKnBW9/5Wbn1bKUT81rgZDP4 WXwJorrlVMBDmByhs+FRe4y9ULzFJcMCCM/5bb9Szrb3NxV7Jn4pW+ymsH9xvTTAI9N3 t2+Q== X-Received: by 10.68.68.203 with SMTP id y11mr7186899pbt.162.1412118524966; Tue, 30 Sep 2014 16:08:44 -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 c3sm901654pbu.15.2014.09.30.16.08.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 16:08:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_D193A95B-26E3-4CA5-89EB-C79A80BA4BB0" From: Douglas Otis In-Reply-To: <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 30 Sep 2014 16:08:43 -0700 Message-Id: <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HebyxAftapJQoolrOC8rysekdgw Cc: dmarc@ietf.org, Douglas Otis Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 23:08:48 -0000 --Apple-Mail=_D193A95B-26E3-4CA5-89EB-C79A80BA4BB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 29, 2014, at 11:58 PM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >>> =46rom (normally contains a mailbox representing the author) might >>> be substituted for a proxy domain to satisfy DMARC acceptance >>> requirements typically needed for non-transactional email. As >>> DMARC affects normal use of From, >=20 > This is rather inaccurate description of the situation. First, "From" > doesn't just "normally" represent the author -- that is the RFC > definition of this REQUIRED field. Second, DMARC is basically an > informational protocol. Only the "p" attribute defines "acceptance > requirements", and only if non-default. Third, even "p=3Dreject" does > not "affect use of From". It affects *delivery* of syntacticly and > semantically conformant Internet messages. (DMARC is a private > protocol by agreement between MXes, and absent a change to the > author's host's terms of service, I don't see why anybody other than > participating MXs should be expected to know or do anything about it.) Dear Stephen, Thank you for your response, but it seems to overlook a few important = issues. The view of DMARC being a private agreement between MX servers assumes = services to the general public are normally categorized as common = carriers to ensure against discrimination and franchise abuse. = Unfortunately, this category is not always applied where appropriate. = For example, a major US provider handles email for other ISPs that offer = general Internet access for millions of customers where the = email-address provided maintains access. As it happens, this provider = also offers their own ad funded group discussion lists, but their = assertion of "p=3Dreject" applied against non-transactional messaging = from other domains disrupts competitors' mailing-lists or legitimate = invoicing services that are nevertheless exchanging RFC compliant = messages. Currently there is NO RFC requirement that =46rom domains use SPF to = authorize all possible IP addresses used by outbound MX servers OR be = signed by matching DKIM domains. To overcome misuse of DMARC policies, = email reliant services are then FORCED to alter the content of their = =46rom header fields into non-compliant forms as their only means to = ensure the integrity of their own service. Such behavior clearly moves = DMARC well beyond the realm of private agreements. As this persists, it = can no longer be seen as just a response to an exigent situation. >> It might be nice to have DMARC embracing use of a special group >> syntax, >=20 > A reasonable suggestion in context of other proposals. >=20 >> since it seems recognizable special group would be fairly unlikely >> to be useful spoofing users. >=20 > But I have to disagree with your premise. To the extent that it *is* > recognizable, it is likely to be "recognized" as an alternative form > of "From" applied to some *authentic* authors for unknown reason, not > as evidence of inauthenticity. Because spam filtering removes many > inauthentic messages and mailing lists generate large numbers of > authentic messages, the conservative assumption (from the point of > view of security against phishing) is that, as seen by recipients, > most authors so marked will indeed be authentic. >=20 > Furthermore, I believe spoofable users *will* get spoofed through such > devices. For example, in Japan, where I live, a standard fraud starts > with a phone call, "Hello? It's me, it's me, and I need $3000 in a > big hurry!" "Oh, Johnny, you poor thing, do you have a cold? Your > voice sounds funny! Be more careful. Where should I take the money? > I can get it in 30 minutes." I am not kidding; in bad years victims > lose hundreds of millions of dollars to this scam. We are dealing with phishing problems on a daily basis. Currently, SPF = is being used by the Kelihos peer-to-peer botnet variant as a means to = create DMARC valid messages using a simple tactic of looking up reverse = domains of compromised computers and assuming SPF has authorized their = gateway. DMARC is also not effective against look-alike attacks = either, which is another scheme not addressed. At least adopting a standard DMARC Group exception should give potential = victims a clue something is different about the message. Valid = mailing-list messages will not be ending up in their spam folder, where = currently it is becoming increasingly common for people to respond to = messages received there. Will the D in DMARC soon stand for Dangerous? I suspect the eventual solution spoofing will be to use DANE to = authenticate email, Caller-ID, web sites, etc. > I see no reason to suppose the demographic that falls prey to this > fraud is absent elsewhere, or that it contains no email users. >=20 > It would be very useful to know what the "conversion rate" for > phishing is for three cases of interest: >=20 > A. a phishing message from a non-acquaintance, displayed by the MUA > "in the usual way" (eg, with "avatar" from the contact list); > B. a phishing message from an acquaintance, displayed by the MUA "in > the usual way"; and > C. a phishing message from an acquaintance, with a different display > containing a familar mitigation. (The user may not be aware that > it is a mitigation, of course, expecially if they have experience > with Outlook and similar MUAs that apply a similar mitigation to > Sender.) From: Dmarc-Noncompliant:ben@example.com; would be similar? > But without data, I am quite sure that C lies strictly between A and > B, and I think the conservative stance is to assume that it's too > close to B ("acquaintance phishing") to risk until data shows > otherwise. >=20 > Note that we *do* have data on the ability of the high tech spammers > and scammers to push millions of exploitative messages in minutes. > And *they* probably have data on conversion rates. If that data shows > an advantage to Type C messages, it would be highly irresponsible to > fail to prepare for a sudden, directed onslaught of Type C messages > once such mitigations become common. In the era of botnets, spammers are able to create DMARC valid messages = without much difficulty. Many years ago, Paul Vixie warned against = being too aggressive with a concern it would drive them in deeper. By = this, I think he was worried about weaknesses in DNS and BGP, abused = even now often without our knowledge. I meet with someone speaking on = behalf a government who said IPv6 is much safer because it now uses = BGPsec. :-) Regards, Douglas Otis --Apple-Mail=_D193A95B-26E3-4CA5-89EB-C79A80BA4BB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 29, 2014, at 11:58 PM, Stephen J. = Turnbull <stephen@xemacs.org> = wrote:

Douglas Otis writes:

=46rom (normally contains a = mailbox representing the author) might
be substituted for a proxy = domain to satisfy DMARC acceptance
requirements typically needed for = non-transactional email.  As
DMARC affects normal use of = From,

This is rather inaccurate = description of the situation.  First, "From"
doesn't just = "normally" represent the author -- that is the RFC
definition of this = REQUIRED field.  Second, DMARC is basically an
informational = protocol.  Only the "p" attribute defines = "acceptance
requirements", and only if non-default.  Third, even = "p=3Dreject" does
not "affect use of From".  It affects = *delivery* of syntacticly and
semantically conformant Internet = messages.  (DMARC is a private
protocol by agreement between = MXes, and absent a change to the
author's host's terms of service, I = don't see why anybody other than
participating MXs should be expected = to know or do anything about it.)

Dear = Stephen,

Thank you for your response, but it = seems to overlook a few important = issues.

The view of DMARC being a private = agreement between MX servers assumes services to the general public = are normally categorized as common carriers to ensure against = discrimination and franchise abuse.  Unfortunately, this category = is not always applied where appropriate.  For example, a major US = provider handles email for other ISPs that offer general Internet access = for millions of customers where the email-address provided maintains = access.  As it happens, this provider also offers their own ad = funded group discussion lists, but their assertion of "p=3Dreject" = applied against non-transactional messaging from other domains disrupts = competitors' mailing-lists or legitimate invoicing services that are = nevertheless exchanging RFC compliant = messages.

Currently there is NO RFC requirement = that =46rom domains use SPF to authorize all possible IP addresses used = by outbound MX servers OR be signed by matching DKIM domains.  To = overcome misuse of DMARC policies, email reliant services are then = FORCED to alter the content of their =46rom header fields into = non-compliant forms as their only means to ensure the integrity of their = own service.  Such behavior clearly moves DMARC well beyond the = realm of private agreements.  As this persists, it can no longer be = seen as just a response to an exigent = situation.

It might be nice to have DMARC embracing use of a special = group
syntax,

A reasonable suggestion in context = of other proposals.

since it seems = recognizable special group would be fairly unlikely
to be useful = spoofing users.

But I have to disagree with your = premise.  To the extent that it *is*
recognizable, it is likely = to be "recognized" as an alternative form
of "From" applied to some = *authentic* authors for unknown reason, not
as evidence of = inauthenticity.  Because spam filtering removes many
inauthentic = messages and mailing lists generate large numbers of
authentic = messages, the conservative assumption (from the point of
view of = security against phishing) is that, as seen by recipients,
most = authors so marked will indeed be authentic.

Furthermore, I believe spoofable users *will* get = spoofed through such
devices.  For example, in Japan, where I = live, a standard fraud starts
with a phone call, "Hello?  It's = me, it's me, and I need $3000 in a
big hurry!"  "Oh, Johnny, you = poor thing, do you have a cold?  Your
voice sounds funny! =  Be more careful.  Where should I take the money?
I can get = it in 30 minutes."  I am not kidding; in bad years victims
lose = hundreds of millions of dollars to this = scam.

We are dealing with phishing = problems on a daily basis.  Currently, SPF is being used by the = Kelihos peer-to-peer botnet variant as a means to create DMARC valid = messages using a simple tactic of looking up reverse domains of = compromised computers and assuming SPF has authorized their gateway. =   DMARC is also not effective against look-alike attacks either, = which is another scheme not addressed.

At least = adopting a standard DMARC Group exception should give potential victims = a clue something is different about the message.  Valid = mailing-list messages will not be ending up in their spam folder, where = currently it is becoming increasingly common for people to respond to = messages received there.  Will the D in DMARC soon stand for = Dangerous?

I suspect the eventual solution = spoofing will be to use DANE to authenticate email, Caller-ID, web = sites, etc.

I see no = reason to suppose the demographic that falls prey to this
fraud is = absent elsewhere, or that it contains no email users.

It would be = very useful to know what the "conversion rate" for
phishing is for = three cases of interest:

A.  a phishing message from a = non-acquaintance, displayed by the MUA
   "in the = usual way" (eg, with "avatar" from the contact list);
B.  a = phishing message from an acquaintance, displayed by the MUA = "in
   the usual way"; and
C.  a phishing = message from an acquaintance, with a different = display
   containing a familar mitigation.  (The = user may not be aware that
   it is a mitigation, of = course, expecially if they have experience
   with = Outlook and similar MUAs that apply a similar mitigation = to
   Sender.)

From: = Dmarc-Noncompliant:ben@example.com; would be similar?

But without data, I am quite sure that C lies strictly = between A and
B, and I think the conservative stance is to assume = that it's too
close to B ("acquaintance phishing") to risk until data = shows
otherwise.

Note that we *do* have data on the ability of = the high tech spammers
and scammers to push millions of exploitative = messages in minutes.
And *they* probably have data on conversion = rates.  If that data shows
an advantage to Type C messages, it = would be highly irresponsible to
fail to prepare for a sudden, = directed onslaught of Type C messages
once such mitigations become = common.

In the era of botnets, spammers = are able to create DMARC valid messages without much difficulty.   = Many years ago, Paul Vixie warned against being too aggressive with a = concern it would drive them in deeper.  By this, I think he was = worried about weaknesses in DNS and BGP, abused even now often without = our knowledge.  I meet with someone speaking on behalf a government = who said IPv6 is much safer because it now uses BGPsec. =  :-)

Regards,
Douglas = Otis

= --Apple-Mail=_D193A95B-26E3-4CA5-89EB-C79A80BA4BB0-- From nobody Tue Sep 30 23:59:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C11A00DF for ; Tue, 30 Sep 2014 23:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.708 X-Spam-Level: *** X-Spam-Status: No, score=3.708 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, J_CHICKENPOX_92=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 kcQb7TYNx2gP for ; Tue, 30 Sep 2014 23:59:14 -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 21CE41A00D9 for ; Tue, 30 Sep 2014 23:59:13 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 57DDE1C3902; Wed, 1 Oct 2014 15:59:12 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4BFE91A2697; Wed, 1 Oct 2014 15:59:12 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 01 Oct 2014 15:59:12 +0900 Message-ID: <87oatwuvgf.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ddHE0n97sssAl2UucpoATCxx9dU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Oct 2014 06:59:16 -0000 Douglas Otis writes: > Thank you for your response, but it seems to overlook a few > important issues. Indeed I overlooked them, but that's because in the context of this working group I consider them unimportant. As follows: > The view of DMARC being a private agreement between MX servers > assumes services to the general public are normally categorized as > common carriers to ensure against discrimination and franchise > abuse. [...] > To overcome misuse of DMARC policies, email reliant services are > then FORCED to alter the content of their From header fields into > non-compliant forms as their only means to ensure the integrity of > their own service. Such behavior clearly moves DMARC well beyond > the realm of private agreements. [...] > SPF is being used by the Kelihos peer-to-peer botnet variant as a > means to create DMARC valid messages [...]. DMARC is also not > effective against look-alike attacks [...]. Abuse of common carrier status is not IETF business, is it? As for private decisions and agreements having external effects, what else is new? The important content of "private agreement" is that outsiders can make all the "standards" they like, but the parties need not adopt them and can continue their behavior. Whether DMARC is effective or not is also outside of the scope of this WG. Bottom line: DMARC is a non-IETF standard prevalent on the Internet, and the WG charter takes that as given as far as I can see. I grant that discussion of these issues provides context, but if I choose not to discuss them, I don't see a problem for conducting WG business. > At least adopting a standard DMARC Group exception should give > potential victims a clue something is different about the message. "Should", yes, I agree in some sense. Unfortunately, at least one HCI paper I read (I am not a specialist) says many potential victims are clueless, and most lack some important clues for protecting their own security. What worries me is that users will pick up on a spurious correlation (the same research provides evidence for that) and interpret the visible artifacts (such as a DMARC-noncompliant tag) incorrectly. Specifically, they'll interpret as just another example of computer breakage, and ignore it in favor of their trust relationship with the apparent author. Remember, *we* know that a great majority of all messages getting that tag are spam, but *the users* never notice them -- many are discarded automatically and those in the spam bucket get discarded without thought -- unless the message is actually from a trusted party, which validates the "computer is broken" hypothesis from that point of view. > In the era of botnets, spammers are able to create DMARC valid > messages without much difficulty. Who needs a botnet? Anybody with access to any domain's DNS can do that. I suppose your point is that somebody with a botnet is able to send From-aligned messages from a Yahoo! address. I don't see how anything authentication-based can deal with such malicious mail, by definition -- the bot must be able to authenticate to send it. To combat such abuse, you need to examine content of outgoing messages as well as incoming messages. "Defense in depth" is the watchword here. But that doesn't make DMARC "D for dangerous"or useless. The point of Yahoo!'s and AOL's use case (thanks to Alessandro Veseley here for making me aware of this) is that the "acquaintance recommendation" spam or phish is based on the ability to spoof a *particular* user to another user, and this is based on an *external* (stolen) contact list. A bot can't do that arbitrarily: because of the way message submission works, it needs to authenticate to pass DMARC p=reject. I suppose if you have both that list and the list of bots, you could match them up and use the "right" bot for this contact list (although the number of matches would be a smallish fraction of all contacts, I suppose). (Not to mention that if you have such a 'bot, it seems more sensible to just use its contact list if you're going to try "acquaintance recommendation spam".) So apparently that isn't what is happening, as p=reject was effective to combat the April attacks.