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

"Robin H. Johnson" <robbat2@gentoo.org> Tue, 08 April 2014 05:38 UTC

Return-Path: <robbat2@gentoo.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962DF1A012C for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 22:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level:
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xsWY8fMzSuds for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 22:38:00 -0700 (PDT)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by ietfa.amsl.com (Postfix) with ESMTP id D62DA1A012F for <ietf@ietf.org>; Mon, 7 Apr 2014 22:38:00 -0700 (PDT)
Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 19A3B33FF98 for <ietf@ietf.org>; Tue, 8 Apr 2014 05:37:55 +0000 (UTC)
Received: (qmail 15095 invoked by uid 10000); 8 Apr 2014 05:37:52 -0000
Date: Tue, 8 Apr 2014 05:37:52 +0000
From: "Robin H. Johnson" <robbat2@gentoo.org>
To: John R Levine <johnl@taugh.com>
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
Message-ID: <20140408053752.GB2858@orbis-terrarum.net>
References: <robbat2-20140408T031810-279861577Z@orbis-terrarum.net> <alpine.BSF.2.00.1404072357400.73388@joyce.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IfZ+tgy+ooJOsAAy"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1404072357400.73388@joyce.lan>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/ExLDjDyb5mrmqTyrybJ_l-xGN9E
X-Mailman-Approved-At: Tue, 08 Apr 2014 08:55:21 -0700
Cc: IETF general list <ietf@ietf.org>, "Robin H. Johnson" <robbat2@gentoo.org>, zwicky@yahoo-inc.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 08 Apr 2014 05:38:05 -0000

On Tue, Apr 08, 2014 at 12:21:46AM -0400, John R Levine wrote:
> You would have to track which forwarders are well behaved and add
> valid X-O-A-R headers, but if you can do that, you can skip the header
> analysis and just whitelist the mail from the well behaved forwarders.

The XOAR proposal does specify:
| The X-Original-Authentication-Results header is only useful if the
| forwarder is trusted.  The forwarder is free to modify the headers and
| body of the message however it wishes and can generate new signatures
| over arbitrary X-Original-Authentication-Results headers.  Thus, the
| user SHOULD only trust X-Original-Authentication-Results if the message
| was delivered by known good forwarders, and forwarders SHOULD NOT
| propagate X-Original-Authentication-Results unless the previous
| forwarder is known to be good.
|
| For the purposes of this memo, a message was delivered through trusted
| forwarder if:
| - The DKIM signature passes
| - The DKIM domain is a trusted forwarder

I think the original scenario you described could be implemented by bad
players as follows:
- set up a mailman instance with DMARC support, that forges the XOAR
  header.
- Ensure that the mailman outgoing mail passes SPF+DKIM for the domain
  in question.


> Note that there are also well behaved things that don't pass DMARC and 
> don't have any original authentication results to report, with the usual 
> examples being mail-an-article at the NY Times and Wall Street Journal.
Those uses shouldn't be considered valid, and NYTimes has already moved
away from that, at least as of my test 5 minutes ago.
| MAIL FROM:<emailthis@ms3.lga2.nytimes.com>
| RCPT TO:<robbat2@gentoo.org>
| DATA
| ...
| From: robbat2 <emailthis@ms3.lga2.nytimes.com>
| Sender: emailthis@ms3.lga2.nytimes.com
| To: robbat2@gentoo.org
| ...

> > 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.
By implement DMARC, I meant implement XOAR headers; VERP is too useful
to running lists to get rid of. Non-VERP bounce messages are still too
generic, even in this modern day.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85