Do we actually want to do anything about DMARC?

"John Levine" <johnl@taugh.com> Mon, 15 August 2016 01:22 UTC

Return-Path: <johnl@taugh.com>
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 2CE3612D15E for <ietf@ietfa.amsl.com>; Sun, 14 Aug 2016 18:22:34 -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 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 IL2E6t396524 for <ietf@ietfa.amsl.com>; Sun, 14 Aug 2016 18:22:32 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F07312D0E1 for <ietf@ietf.org>; Sun, 14 Aug 2016 18:22:32 -0700 (PDT)
Received: (qmail 60920 invoked from network); 15 Aug 2016 01:22:30 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Aug 2016 01:22:30 -0000
Date: 15 Aug 2016 01:22:08 -0000
Message-ID: <20160815012208.8845.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: ietf@ietf.org
Subject: Do we actually want to do anything about DMARC?
In-Reply-To: <12947.1471213237@obiwan.sandelman.ca>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/B47dhpBT_gNry9UjgACnUFhMHxg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Mon, 15 Aug 2016 01:22:34 -0000

>I agree strongly with you: the IETF needs to do something in some direction.
>
>That something could be to properly reject email with a DMARC policy that
>does not permit forwarding.  That would piss off an awful lot of IETF
>participants, but it would be simple, since it requires no protocol
>changes, just social changes.

Hmmn, the one approach that is unambiguously worse than doing nothing,
since it would confirm every worst fear that we're more interested in
playing purity games than in getting work done.

If we actually want to do something, we should decide what to do and do it.

It's not like there's any mystery about what the options are.  This
page in the old ASRG wiki lists them all and hasn't changed in ages:

 http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

The options built into mailman 2 are:

 * moderate or reject DMARC'ed submissions

 * rewrite the From: line with the list address

 * wrap messages sort of like one-message digests

Personally, I think those are all pretty bad, so we should do
something else.  (If I had to pick one, I'd pick the last one since
it's the easiest to undo on the way in.)

Anything else would require some development.  I am one of the few
IETF participants who has actually written anti-DMARC code for mailing
lists, so I have some idea of how much work it is.

My preferred approach until ARC is usable is to rewrite the From:
address to a legible forwarding address.  The IETF already handles a
bazillion forwarding addresses for I-D and RFC authors, so I'd think
it wouldn't be terribly hard to adapt that.  You don't have to change
any mailman code; you can do everything in a shim between the list
manager and the outgoing postfix submission program.

My form is marissa@yahoo.com.dmarc.fail,* but if wildcard MX records
are scary, it could be marissa-yahoo.com@fwd.ietf.org.  Having done
this before, I know it's not terribly hard, and I'd be happy to help
make it work.

R's,
John

* - yes, dmarc.fail is a real domain.  If the IETF asks nicely, I'd be
happy to give you dmarc.wtf.