Re: DMARC and ietf.org

ned+ietf@mauve.mrochek.com Thu, 21 July 2016 17:00 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
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 8EE4012D565 for <ietf@ietfa.amsl.com>; Thu, 21 Jul 2016 10:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gTAdMk8DbnA7 for <ietf@ietfa.amsl.com>; Thu, 21 Jul 2016 10:00:12 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD5612D7A5 for <ietf@ietf.org>; Thu, 21 Jul 2016 09:59:59 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q2SVKTCWMO00DLT2@mauve.mrochek.com> for ietf@ietf.org; Thu, 21 Jul 2016 09:55:04 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q2RZ1YP6UO00005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Thu, 21 Jul 2016 09:54:53 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01Q2SVKQRGDC00005M@mauve.mrochek.com>
Date: Thu, 21 Jul 2016 09:43:03 -0700
Subject: Re: DMARC and ietf.org
In-reply-to: "Your message dated Thu, 21 Jul 2016 08:29:21 +0200" <c1372647-cd37-9eb9-ee8b-4ef8d21809c4@dcrocker.net>
References: <CAL0qLwYZPO9L9e7MHA6zP5vcTbQEJmwCSonLdMeQiOw4CUoiFw@mail.gmail.com> <20140718174827.652621ADAF@ld9781.wdf.sap.corp> <6.2.5.6.2.20140719235353.0c50d260@resistor.net> <25621.1405862805@sandelman.ca> <56CDC083.7020001@sandelman.ca> <CAA=duU0HLdE0WRcM3o9SXGuZ2T6E5mha+GjRkyGfPEe+VO=pdg@mail.gmail.com> <87B045CE-2C2F-4528-937E-772B67E26F8C@vigilsec.com> <1301.1456329984@obiwan.sandelman.ca> <56CDFA68.4030506@gmail.com> <A2F94A7A-3984-4E01-9C66-C580BD8C92CA@me.com> <BE67956E-7299-41D1-B8D6-B66AD18081D7@vigilsec.com> <bf2540aa-eda2-8e56-d3f5-1bf862b395ce@dcrocker.net> <10004.1469036041@obiwan.sandelman.ca> <25ffe3be-cf32-6a25-1830-82650c1175d9@dcrocker.net> <aa0e220a-e1a1-3c65-b426-01d1fbb09c5d@gmail.com> <c1372647-cd37-9eb9-ee8b-4ef8d21809c4@dcrocker.net>
To: Dave Crocker <dhc@dcrocker.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/dIbqEI1an79dLfpkHYcoD8UY_eI>
Cc: ietf@ietf.org
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: Thu, 21 Jul 2016 17:00:15 -0000

> On 7/21/2016 7:35 AM, Brian E Carpenter wrote:
> > Yes. So I repeat the question: Since the most pragmatic, non-purity-based
> > solution is to rewrite the sender field for mail from p=reject (or p=quarantine)
> > domains, when will we change the IETF and IRTF mailmen to do so?


> I'm sure you really meant this, but just to be careful, what with this
> being a technical point in a technical forum, it's worth clarifying that
> the rewriting is for the rfc5322.from field and not the rfc5322.sender
> field.

I have an additional suggestion.

If we're going to do this - and I'm not going to offer an opinion on whether or
not it should be done - I'd like to see it done in a fashion that's both
detectable and reversible. That way people using sieve or procmail or whatever
will be able to undo the damage.

The most straightforward way to accomplish this would be to make copies of the
original fields with different names, but of course many other approaches  are
possible.

				Ned