Re: Do we actually want to do anything about DMARC?

Michael Richardson <> Mon, 15 August 2016 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A18E12D6AF for <>; Mon, 15 Aug 2016 07:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uO_mIap4d1Mr for <>; Mon, 15 Aug 2016 07:53:25 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8262E128E19 for <>; Mon, 15 Aug 2016 07:53:25 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 406A9203AD; Mon, 15 Aug 2016 11:04:23 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id A68E8639DC; Mon, 15 Aug 2016 10:53:24 -0400 (EDT)
From: Michael Richardson <>
To: "John Levine" <>
Subject: Re: Do we actually want to do anything about DMARC?
In-Reply-To: <20160815012208.8845.qmail@ary.lan>
References: <20160815012208.8845.qmail@ary.lan>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 15 Aug 2016 10:53:24 -0400
Message-ID: <>
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Aug 2016 14:53:27 -0000

John Levine <> wrote:
    >> 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,

Good, we agree about this, but, I still think we need to lead with a carrot
(new DMARC spec to solve the problem), and a stick (date at which we will
comply to DMARC)

    > since it would confirm every worst fear that we're more interested in
    > playing purity games than in getting work done.

That's one way to look at it, and I'm not saying it's wrong.

I think it shows that we actually care about the contents of our
specifications, and that we actually expect others to.

    > 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:


    > 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

Hah. So this is the same debate 6man has about IPv6 Extension Header
insertion :-)

    > 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.)

It's been like two years that I said the same thing.

    > 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.

I call this NAT for email.
I'd rather do IPIP for email and wrap the messages.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-