RE: DMARC: perspectives from a listadmin of large open-source lists

"MH Michael Hammer (5304)" <> Tue, 15 April 2014 21:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2219B1A0454 for <>; Tue, 15 Apr 2014 14:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3TCfKwIx0ht4 for <>; Tue, 15 Apr 2014 14:15:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ABEED1A049E for <>; Tue, 15 Apr 2014 14:15:19 -0700 (PDT)
Received: from ([fe80::f5de:4c30:bc26:d70a]) by ([::1]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 17:15:15 -0400
From: "MH Michael Hammer (5304)" <>
To: Hector Santos <>, Alessandro Vesely <>
Subject: RE: DMARC: perspectives from a listadmin of large open-source lists
Thread-Topic: DMARC: perspectives from a listadmin of large open-source lists
Thread-Index: AQHPWO049xJg0SLv5E6irQO+Rle3hpsTKl8Q
Date: Tue, 15 Apr 2014 21:15:15 +0000
Message-ID: <>
References: <> <alpine.BSF.2.00.1404072357400.73388@joyce.lan> <> <> <alpine.BSF.2.00.1404081325130.76892@joyce.lan> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Apr 2014 21:15:21 -0000

> -----Original Message-----
> From: ietf [] On Behalf Of Hector Santos
> Sent: Tuesday, April 15, 2014 4:57 PM
> To: Alessandro Vesely
> Cc:
> Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
> >> It may be the "quickest" way, but I would consider this the most
> >> intrusive and even email damaging, extremely harmful suggestion to
> >> electronic mail communications.
> >
> > Ok, I added "temporarily", so it now reads:
> >
> >     Various workarounds have been proposed to cope with domains that
> >     publish strict policies unwittingly. For example, a mailing list
> >     manager should reject posts from authors who use problematic email
> >     domains. The latter behavior is the most respectful the
> >     communication protocols as well as the domain owner's will.
> >     However, it might cause inconveniences in the face of sudden
> >     policy changes. According to John Levine, a well known mail
> >     expert, the least intrusive way to temporarily mitigate the damage
> >     would be to rewrite the From: address in a predictable,
> >     comprehensible manner, such as the following:
> >
> > In the preceding "History" section, I appended:
> >
> >     In April 2014, Yahoo changed its DMARC policy to p=reject, thereby
> >     causing misbehavior in several mailing lists.[6] DMARC is not yet
> >     a standard protocol, and currently misses a provision for such
> >     sudden changes.
> >
> > Is that more acceptable?

Many protocols do not address sudden individual implementer changes to their implementation. I do believe that there were various issues involving DNSSEC trust chains when upstream participants (including CC TLDs) implemented "sudden" changes. Are you expecting something like "MUST provide x days notice of intended change" to make it non-sudden or require a rollback if more than x mailing lists have problems? Are there any other IETF standards that would be a reference point for such a provision? I'm not trying to be cute or argumentative - I'm just not familiar with something like this in any standards I can think of.

> I think adding temporarily helps and the additional text about DMARC
> certainly helps.
> But the problem is YAHOO doesn't want you to do this (rewrite).
> Just consider what you are essentially doing:
>     Degrading a secured message to a non-secured message.
> The whole point of Yahoo moving to a restrictive policy is to force a cleanup
> of their domain usage, to increase its security quality, even if it hurts the
> innocent users who were using their domains in public mail list areas.
> So I would personally refrain from any product liability risk that its ok to
> "tamper" with their DKIM secured author domain submissions.
> Case in point, lets say a real bad message got into the list, unsigned,
> purported from Yahoo, the 5322.From was rewritten and distributed to other
> list users and some of those users were "harmed"
> in some fashion that it worth the effort to sue.   Guess who would be
> at legal fault here?  Not YAHOO. They are legally protected.  The MLM, who
> wistfully and intentionally ignored policy and even went as far to break the
> security, is now at risk.
> No, its not silly, and just because I am not a lawyer, doesn't mean we don't
> think about these things in our product development.  In fact, it is generally
> the engineer, us, that has to ask the our lawyers if this is ok.  He isn't going to
> generally tell you, it is not something he will pick up unless you pointed it out
> to him. Then he will give you his legal advise and in my strong opinion, you
> don't tamper with a security protocol which is what being suggested here.
> Don't let me stop you from the wiki work.  It is just how I work.
> Thanks
> --