Re: DMARC and ietf.org

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 24 February 2016 14:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 21CBA1B3176 for <ietf@ietfa.amsl.com>; Wed, 24 Feb 2016 06:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level:
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
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 1T_jHJ8xPD6v for <ietf@ietfa.amsl.com>; Wed, 24 Feb 2016 06:39:01 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id 0661E1B3174 for <ietf@ietf.org>; Wed, 24 Feb 2016 06:39:01 -0800 (PST)
Received: from [IPv6:2607:f0b0:c:101::40] (knothole.gatineau.credil.org [IPv6:2607:f0b0:c:101::40]) by tuna.sandelman.ca (Postfix) with ESMTPSA id F376E2002A for <ietf@ietf.org>; Wed, 24 Feb 2016 09:40:05 -0500 (EST)
Message-ID: <56CDC083.7020001@sandelman.ca>
Date: Wed, 24 Feb 2016 09:38:59 -0500
From: Michael Richardson <mcr+ietf@sandelman.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: DMARC and ietf.org
References: <CAL0qLwYZPO9L9e7MHA6zP5vcTbQEJmwCSonLdMeQiOw4CUoiFw@mail.gmail.com> <20140718174827.652621ADAF@ld9781.wdf.sap.corp> <6.2.5.6.2.20140719235353.0c50d260@resistor.net> <25621.1405862805@sandelman.ca>
In-Reply-To: <25621.1405862805@sandelman.ca>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/vwNOtPuxjWQFZkF-P-4VKawqFXw>
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: <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, 24 Feb 2016 14:39:03 -0000

20 months ago, I asked the following question, and I am still unclear if 
we have some plan.
https://www.ietf.org/mail-archive/web/ietf/current/msg88695.html

Again, I'm not interested what the best way to boil the DMARC ocean is.
I'm interested in the IETF cup of tea, as an enterprise, not as the 
responsible SDO.
When I asked before, I was told that there would be results "soon", and 
I should wait.

(I also would like to recommend that the 2016 nomcom be given 
@something.ietf.org IMAP mailboxes, because DMARC makes receiving 
feedback very difficult.)

So again, my questions were:

On 20/07/14 09:26 AM, Michael Richardson wrote:
> Regardless of how/if/why/when we process DMARC as a specification, we need to
> decide how ietf.org MTA is going to deal with things.
>
> 1) someone has to fund changes to mailman, and perform testing, installation,
>     and community education for the IETF mailing lists.  That implies that
>     we have to decide *for ourselves* where and how we will "break" the
>     DMARC/DKIM connection,  and if we will reject email from p=reject senders
>     before we attempt to relay.

I don't think we ever made a decision here.  I'm pretty sure that we 
need to make this decision regardless of what improvements are made to 
DMARC.  If someone marks their email as not for forwarding, perhaps we 
should respect that.  Some suggested that the lists refuse to have 
people on them with p=reject policy.

My spam processor has just started processing DMARC, which will kick me 
off mailing lists unless I disable it.  Fortunately, that is an option, 
but I think I have to turn off SPF to get it.

Has the tools cmte determined if mailman will be enhanced in the way 
that we want?
So, again, I'm not interested in what we might specify as an SDO.
I'm interested in what we are going to *do* as an entity.