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

Alex Ojeda <> Tue, 08 April 2014 17:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 94AA81A0684 for <>; Tue, 8 Apr 2014 10:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r7oW3Ck_zByk for <>; Tue, 8 Apr 2014 10:59:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B42621A0683 for <>; Tue, 8 Apr 2014 10:59:02 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.908.10; Tue, 8 Apr 2014 17:58:59 +0000
Received: from ([]) by ([]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 17:58:59 +0000
From: Alex Ojeda <>
To: "" <>, John R Levine <>
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: AQHPUtuYTS4fL01ECEiytxQlwLX/hZsH9HcKgAANnuA=
Date: Tue, 8 Apr 2014 17:58:57 +0000
Message-ID: <>
References: <> <alpine.BSF.2.00.1404072357400.73388@joyce.lan> <>
In-Reply-To: <>
Accept-Language: es-CL, en-US
Content-Language: es-ES
x-originating-ip: []
x-forefront-prvs: 017589626D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(51704005)(59124003)(377424004)(93516002)(74366001)(65816001)(99396002)(81542001)(74876001)(74316001)(81342001)(74706001)(69226001)(87266001)(2656002)(85306002)(47446003)(54356002)(47736002)(54316003)(47976002)(50986002)(53806002)(90146001)(80022001)(87936001)(86362001)(66066001)(31966008)(59766001)(77982001)(94316002)(63696002)(20776003)(74662001)(79102001)(4396001)(74502001)(49866001)(83072002)(46102001)(76482001)(85852003)(19580405001)(83322001)(19580395003)(566704002)(76786001)(76576001)(76796001)(77096001)(81816001)(95416001)(81686001)(94946001)(56816005)(93136001)(97186001)(97336001)(56776001)(98676001)(33646001)(80976001)(95666003)(92566001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB535;; FPR:BCFCF6B7.8CD69702.33F35F4B.48A56B49.20452; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF general list <>, "Robin H. Johnson" <>, "" <>
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, 08 Apr 2014 17:59:08 -0000

For mailman and DKIM problems (remote reject) 
2014-04-06 08:09:43 1WWkxK-0007jZ-T5 []:45557 rejected DKIM : DKIM: encountered the following problem validating signature_incorrect


Alex Matias Ojeda Mercado

-----Mensaje original-----
De: ietf [] En nombre de
Enviado el: martes, 08 de abril de 2014 12:53
Para: John R Levine
CC: IETF general list; Robin H. Johnson;
Asunto: Re: DMARC: perspectives from a listadmin of large open-source lists

> > The problem described WILL vanish when all mailing list apps 
> > implement DMARC, but until then, it's really broken.

> Mailing list apps can't "implement DMARC" other than by getting rid of 
> every feature that makes lists more functional than simple forwarders.
> Given that we haven't done so for any of the previous FUSSPs that 
> didn't contemplate mailing lists, because those features are useful to 
> our users, it seems unlikely we'll do so now.

Actually, mailing lists *can* implement DMARC, just not that way: Do a DMARC check on all incoming messages, and if the domain policy is one that is incompatible with the list's own policies - whatever they are - either change the list's policies to conform to that message or reject it outright, preferably with a nasty "find another a better mail provider" sort of message.

If the IETF wants to take a leadership position in regards to this issue, perhaps someone could set this up.

> If receivers want to implement DMARC policy, they need to make their 
> false alarm whitelist first.  This appears to be a substantial, 
> perhaps insurmountable, hurdle.

> > At the same time, delaying mass usage of the reject policy would 
> > limit damage.

> Reject policy is fine for domains that don't have individual human 
> users, or for companies with firm staff policies that all mail goes 
> through the company mail server, and employees don't join mailing 
> lists and the like using company addresses, or the company provides a 
> separate less strictly managed domain for its staff mail. Strict 
> policies will never be appropriate for public webmail systems where 
> the users will use their mail addresses any way one can use a mail 
> address.  Yahoo appears to understand most of this, viz. the different domain for Elizabeth's company mail.

Which is why support for such policies is even in the specification. The problem is there's no way to stop inappropriate use of such politicies in advance of it happening. The best you can do is apply the clue-by-four later.