Re: DMARC and ietf.org

Dave Crocker <dhc@dcrocker.net> Tue, 19 July 2016 15:47 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F86C12D0CA for <ietf@ietfa.amsl.com>; Tue, 19 Jul 2016 08:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=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 UzCcYUjKgstC for <ietf@ietfa.amsl.com>; Tue, 19 Jul 2016 08:47:50 -0700 (PDT)
Received: from simon.songbird.com (unknown [72.52.113.5]) (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 92FF712D6AC for <ietf@ietf.org>; Tue, 19 Jul 2016 08:34:43 -0700 (PDT)
Received: from [31.133.177.194] (dhcp-b1c2.meeting.ietf.org [31.133.177.194]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u6JFZJEY027891 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Jul 2016 08:35:21 -0700
Subject: Re: DMARC and ietf.org
References: <CAL0qLwYZPO9L9e7MHA6zP5vcTbQEJmwCSonLdMeQiOw4CUoiFw@mail.gmail.com> <20140718174827.652621ADAF@ld9781.wdf.sap.corp> <6.2.5.6.2.20140719235353.0c50d260@resistor.net> <25621.1405862805@sandelman.ca> <56CDC083.7020001@sandelman.ca> <CAA=duU0HLdE0WRcM3o9SXGuZ2T6E5mha+GjRkyGfPEe+VO=pdg@mail.gmail.com> <87B045CE-2C2F-4528-937E-772B67E26F8C@vigilsec.com> <1301.1456329984@obiwan.sandelman.ca> <56CDFA68.4030506@gmail.com> <A2F94A7A-3984-4E01-9C66-C580BD8C92CA@me.com> <BE67956E-7299-41D1-B8D6-B66AD18081D7@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>, John Payne <jcapayne@me.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <bf2540aa-eda2-8e56-d3f5-1bf862b395ce@dcrocker.net>
Date: Tue, 19 Jul 2016 17:34:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <BE67956E-7299-41D1-B8D6-B66AD18081D7@vigilsec.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/If1kcUSikFyIl-q7N6nqDkqFvPw>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2016 15:47:51 -0000

On 7/19/2016 5:00 PM, Russ Housley wrote:
> Outgoing Mailman email still has the problem.  Mailman has an option we can enable to force DMARC-spoofing sender rewriting of all outgoing Mailman email.  If we enable that option, the From: field rewriting and could be disruptive in unknown ways.
>
> We know that outgoing alias email still has the problem.  The Secretariat is did some experiments with some additional headers (Resent-*) to alias mail.  They were not able to determine whether this headers helped destination servers or not.


The major issue is for mail sent through a mailing list, from authors 
whose From: domain has a DMARC policy calling for dire action (reject or 
quarantine) if DMARC does not validate at the final recipient's side.

To overcome this, the ad hoc convention for mailing lists is to rewrite 
the From: header field, using an address belonging to the mailing list 
-- ie, no longer using the author's address -- and modifying the Display 
(friendly) string to /add/ something like "- via <listname>".  In 
addition the Reply-to: header field is set to be the original author's 
address, so that direct replies from a recipient will go back to the 
proper place.

When organized by author address, this means that an actual author's 
mail is listed differently depending upon whether their messages are 
direct to the recipient, versus whether they went through a mailing 
list.  It likely also means differential listing when sorted on the 
Display string...

The modified display string will now have the extra visual cruft and 
there is no empirical basis for justifying that cruft, in terms of user 
behavior or any other safety and security.  That is, it's an entirely 
logical modification, but there is no basis for believing that it is 
useful. (This is an unfortunate fact of usability life.)

There is an effort (ARC) to develop a capability that might let 
DMARC-related messages survive transit of a mailing list, but that 
effort is still nascent.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net