Re: [dmarc-ietf] IETF Mailing Lists and DMARC

Theodore Ts'o <tytso@mit.edu> Wed, 02 November 2016 23:24 UTC

Return-Path: <tytso@thunk.org>
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 5591812967A; Wed, 2 Nov 2016 16:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org
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 O2dO9Hq8csUl; Wed, 2 Nov 2016 16:24:00 -0700 (PDT)
Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3F7129677; Wed, 2 Nov 2016 16:24:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=uv82srWeGG+H04UDJ5i4Ktp77deWz9lQ4hSY5/uIbCI=; b=w+fYPOuzocdNkwOHK1Q7vNv+u+iK//0zABI38RH6x/NS3wMSKu8irZUsgtCYsCYCKCLT1CKqPbRFWo6OXrick+JY0KiubprDq4ak1951MAqfcd901AV2bca2FKacmh/SnOmHlVCQ6KNDaoyPXiAt2uvB6vg9FwF7QjP8w6oy63k=;
Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from <tytso@thunk.org>) id 1c24sw-0004P7-QX; Wed, 02 Nov 2016 23:23:58 +0000
Received: by callcc.thunk.org (Postfix, from userid 15806) id 83736C00A04; Wed, 2 Nov 2016 19:23:57 -0400 (EDT)
Date: Wed, 02 Nov 2016 19:23:57 -0400
From: Theodore Ts'o <tytso@mit.edu>
To: Brandon Long <blong@google.com>
Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC
Message-ID: <20161102232357.b55vx7est7vjrdfo@thunk.org>
References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com>
User-Agent: NeoMutt/20161014 (1.7.1)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SaT5u5zlFv-tlPsMWlp53_A2YQI>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "dmarc@ietf.org" <dmarc@ietf.org>, IETF <ietf@ietf.org>, Cullen Jennings <fluffy@iii.ca>
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: Wed, 02 Nov 2016 23:24:02 -0000

On Wed, Nov 02, 2016 at 02:58:31PM -0700, Brandon Long wrote:
> If this is a problem for you as a receiver, you can choose to attempt to
> whitelist the ietf mailing list mail from DMARC enforcement.  You may not
> be able to do so, just like the sender may not be able to change their
> organizations DMARC record.
> 
> The middle man, ietf, can work around this today.  They need to run a new
> enough version of mailman and enable one of the workarounds.  For mailman,
> this means munging the mail, usually the From header.  It's not pretty, but
> it works, it works now, and it will work for everyone.  The difference is
> mostly cosmetic, though depending on your mail client, there may be other
> downsides.  And it may violate RFC 5322.
> 
> I don't think this is possible with mailman, but theoretically it is also
> possible for a mailing list to pass the message through without breaking
> the DKIM signature.  This means no footers and no subject tags.  Which of
> these a list would choose is probably dependent on the list members.
> 
> mailman should also know how to tell the difference between a message
> specific policy bounce, and particular DMARC bounces, and should apply
> different heuristics to handling them.  I have no idea if that existing in
> any version of mailman or is a planned feature.
> 
> There is a proposed standard, ARC, that would allow mail receivers to do
> more intelligent whitelisting.  It's not ready yet.

There is a third option --- which is that if you want to participate
on certain mailing lists, you have to use a non-DMARC e-mail address.
There are people with google.com addresses that need to use non-Google
addresses in order to participate on the Linux Kernel Mailing List.

On Wed, Nov 02, 2016 at 04:00:36PM -0600, Cullen Jennings wrote:
> 
> So how do we get this fixed ? Has someone talked to the IESG about
> this? Right now as a chair, I am making consensus calls that are
> probably ignoring any emails from people from google.com - and other
> - because I am not getting their email. That seems like a serious
> process problem.

I would expect that most folks at Google.com who need to interact with
external communities are painfully aware of the DMARC brain-damage,
and at least with respect to the Googlers who work on the Linux
kernel, so it shouldn't be coming as a surprise.

I would expect that it would easy to determine how many who are on
DMARC-hobbled domains on the IETF working gorup mailing lists, and it
should be easy to create tools to send last-call announcements to
those people to at least solve the process problem.

But given that at the IETF attendees represent themselves, and not
their companies, if it means that people at certain companies need to
get alternate e-mail arrangements, I don't think that's a fatal issue.
It certainly hasn't bothered the LKML administrators, which has a
similar "we're all engieners, not corporate representatives" ethos.

Cheers,

						- Ted