Re: DMARC and ietf.org

ned+ietf@mauve.mrochek.com Fri, 22 July 2016 01:31 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 2091E12DBC0 for <ietf@ietfa.amsl.com>; Thu, 21 Jul 2016 18:31:41 -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 CCT6UYpd0dVK for <ietf@ietfa.amsl.com>; Thu, 21 Jul 2016 18:31:39 -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 A147B12D849 for <ietf@ietf.org>; Thu, 21 Jul 2016 18:31:39 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q2TDG5VRY800DARE@mauve.mrochek.com> for ietf@ietf.org; Thu, 21 Jul 2016 18:26:41 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
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 18:26:31 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01Q2TDG2FOSY00005M@mauve.mrochek.com>
Date: Thu, 21 Jul 2016 18:24:56 -0700
Subject: Re: DMARC and ietf.org
In-reply-to: "Your message dated Thu, 21 Jul 2016 13:12:10 -0400" <CC6156F0-83C6-4E18-80F9-B0B4FAD13621@vigilsec.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> <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> <01Q2SVKQRGDC00005M@mauve.mrochek.com> <CC6156F0-83C6-4E18-80F9-B0B4FAD13621@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gNU75Vn1C04lxMH6H5r6qE1l6yM>
Cc: ned+ietf@mauve.mrochek.com, IETF <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: Fri, 22 Jul 2016 01:31:41 -0000

> On Jul 21, 2016, at 12:43 PM, ned+ietf@mauve.mrochek.com wrote:

> >> 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.

> I do not see MailMan settings to make that happen.  Maybe I missed something...

That's most unfortunate, and I have to say moves my position from neutral
to "don't do it".

Reversible damage is one thing, irreversible damage another.

				Ned