Re: DMARC and ietf.org

John C Klensin <john-ietf@jck.com> Sun, 20 July 2014 16:12 UTC

Return-Path: <john-ietf@jck.com>
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 7D8451B2C7C; Sun, 20 Jul 2014 09:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] 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 hqFVlj0XLPgF; Sun, 20 Jul 2014 09:12:40 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13A41ACAD6; Sun, 20 Jul 2014 09:12:40 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1X8tez-00012l-AJ; Sun, 20 Jul 2014 12:08:25 -0400
Date: Sun, 20 Jul 2014 12:12:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: DMARC and ietf.org
Message-ID: <8FD6A1B037EE43D7EDB4DB53@JCK-EEE10>
In-Reply-To: <53CBCC41.5000907@gmail.com>
References: <CAL0qLwYZPO9L9e7MHA6zP5vcTbQEJmwCSonLdMeQiOw4CUoiFw@mail.gmail.com> <20140718174827.652621ADAF@ld9781.wdf.sap.corp> <6.2.5.6.2.20140719235353.0c50d260@resistor.net> <25621.1405862805@sandelman.ca> <53CBCC41.5000907@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/nNVphggPdjXf2Lx52KiFNFzRG48
Cc: iaoc@ietf.org, ietf@ietf.org
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: Sun, 20 Jul 2014 16:12:46 -0000


--On Monday, 21 July, 2014 02:03 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> On 21/07/2014 01:26, 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 thought the preferred solution was to rewrite the From for
> those users only.

Brian,

I think that remains controversial.  At least some of us would
prefer that we scan IETF lists for addresses that might be
affected, notify those people that they will no longer be able
to send to IETF lists from those addresses, and then, while we
would continue to deliver traffic to them to the degree
feasible, any traffic originating from them would simply be
rejected or bounced by mailman.  That requires changes and some
tool work too, but puts the pain where it belongs -- on the
DMARC-using systems and those who choose to have addresses on
then.

I have mixed feelings about recommending that strategy for the
more general community and am happy to let the proposed WG do
its job, but, as far as the IETF community is concerned, we are
all presumably capable of understanding the issues and finding
other addresses if needed.

   john