Re: dmarc damage, was gmail users read on... [bozo subtopic]

David Morris <dwm@xpasc.com> Mon, 15 September 2014 03:41 UTC

Return-Path: <dwm@xpasc.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 E7C6B1A0538 for <ietf@ietfa.amsl.com>; Sun, 14 Sep 2014 20:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.967
X-Spam-Level:
X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, 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 CwShOUpEvcPW for <ietf@ietfa.amsl.com>; Sun, 14 Sep 2014 20:41:38 -0700 (PDT)
Received: from c2w3p-2.abacamail.com (c2w3p-2.abacamail.com [67.231.154.153]) by ietfa.amsl.com (Postfix) with ESMTP id 27FF81A04F8 for <ietf@ietf.org>; Sun, 14 Sep 2014 20:41:38 -0700 (PDT)
Received: from xpasc.com (h-68-164-244-186.snva.ca.megapath.net [68.164.244.186]) by c2w3p-2.abacamail.com (Postfix) with ESMTP id 791EC3F9A3 for <ietf@ietf.org>; Mon, 15 Sep 2014 03:37:50 +0000 (UTC)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id s8F3farJ031628 for <ietf@ietf.org>; Sun, 14 Sep 2014 20:41:36 -0700
Date: Sun, 14 Sep 2014 20:41:36 -0700
From: David Morris <dwm@xpasc.com>
To: ietf@ietf.org
Subject: Re: dmarc damage, was gmail users read on... [bozo subtopic]
In-Reply-To: <E8CD1C3A-B7DD-404E-B9A7-1CA70D7645B4@me.com>
Message-ID: <alpine.LRH.2.01.1409142034180.30233@egate.xpasc.com>
References: <20140911202058.3327.qmail@joyce.lan> <541208F6.1010302@dougbarton.us> <bb48b8f170074ddeb25cbb213f613892@DM2PR0301MB0655.namprd03.prod.outlook.com> <CE39F90A45FF0C49A1EA229FC9899B0525E804C0@USCLES544.agna.amgreetings.com> <54132CE8.7000702@dcrocker.net> <E8CD1C3A-B7DD-404E-B9A7-1CA70D7645B4@me.com>
User-Agent: Alpine 2.01 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/07ShZZoIUbze70v68LoieHwtQTU
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
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: Mon, 15 Sep 2014 03:41:39 -0000

It seems to me that the wrapped original mail could be signed by the
forwarding list processor so that the DMARC recipient would accept the
forwarded mail as coming from the forwarder and the ultimate MUA would
be able to verify that the wrapped messaged was indeed wrapped by the
forwarding list processor and transparently unwrap the original
email.

Since some list mail is re-forwarded along the path to the ultimate MUA,
this mechanism should support multiple layers of signed wrapping.

Dave Morris


On Sat, 13 Sep 2014, Sabahattin Gucukoglu wrote:

> On 12 Sep 2014, at 18:27, Dave Crocker <dhc@dcrocker.net> wrote:
> > By definition, p=reject enforces a semantic that requires the owner of
> > the rfc5322.From domain to have a relatively tight relationship with the
> > operator sending the message.
> >
> > IMO, it's quite reasonable to characterize this as conflating From: and
> > Sender:.
> >
> > What tends to be missed, throughout all of the discussions about dealing
> > with the effect on intermediaries such as mailing lists, is that most or
> > all of the mechanisms being discussed for intermediaries will work
> > equally well for bad actors...
>
> Indeed.
>
> I wonder if it might not simply make more sense to warn users that the
> information in the header fields cannot be trusted once they have been
> remailed by an exploder of any kind.  This way, transparent MUA
> unwrapping of encapsulated list mail is a much more plausible solution
>
> Cheers,
> Sabahattin
>