Re: not really to do with Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

ned+ietf@mauve.mrochek.com Tue, 15 July 2014 16:03 UTC

Return-Path: <ned+ietf@mauve.mrochek.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 E3CE41B28D6 for <ietf@ietfa.amsl.com>; Tue, 15 Jul 2014 09:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-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 oftGpRPzo2Nb for <ietf@ietfa.amsl.com>; Tue, 15 Jul 2014 09:03:04 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7A21B28D2 for <ietf@ietf.org>; Tue, 15 Jul 2014 09:03:04 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PA78TQ33Y80088JV@mauve.mrochek.com> for ietf@ietf.org; Tue, 15 Jul 2014 08:58:06 -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 <01PA1SES1000007ZXF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Tue, 15 Jul 2014 08:58:01 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01PA78TOWR4O007ZXF@mauve.mrochek.com>
Date: Tue, 15 Jul 2014 08:12:16 -0700
Subject: Re: not really to do with Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)
In-reply-to: "Your message dated Tue, 15 Jul 2014 11:20:23 +0000" <20140715112023.GU2595@mournblade.imrryr.org>
References: <20140714164212.22974.20340.idtracker@ietfa.amsl.com> <4450964.7UmRiHm4KW@scott-latitude-e6320> <20140715001549.GG2595@mournblade.imrryr.org> <2270075.AYnCC6OxAQ@scott-latitude-e6320> <20140715033346.GL2595@mournblade.imrryr.org> <026301cfa01a$7ebdde40$4001a8c0@gateway.2wire.net> <20140715112023.GU2595@mournblade.imrryr.org>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/pRqPZXCmnD82_QS5sZ5liBO-r-Q
Cc: 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: Tue, 15 Jul 2014 16:03:07 -0000

> On Tue, Jul 15, 2014 at 09:06:55AM +0100, t.p. wrote:

> > > MUAs should expose message origin when different from author.
> >
> > Viktor,
> >
> > A fine idea, but, as a pragmatic engineer, I know that changes to an MUA
> > will take five, may be ten, years to achieve widespread deployment,
> > whereas changes to MTA could happen in a matter of weeks, if needs must.

> We could have started 5 years ago.  Better late than never.  The
> problem being tackled has no instant gratification solutions.
> Pretending the problem is simpler than it is has a way of coming
> back to bite you.  I've always held that no amount of sender origin
> authentication will save the clueless from themselves, any real
> protection is at the gateway, and the gateway sees all the headers.

> In the mean-time "citibank.com.dukhovni.org" will look plausible
> enough to the helpless and will not be foiled by DMARC.

> The expedient approach has not worked, it should have been done right
> long ago, and should still be done right in the present.

You know, I'm finding it difficult to argue with this.

I've long been a supporter of using From/Sender semantics, but I've also bought
into the assumption that current client behavior made use of these semantics
problematic.

But current client behavior also includes, in many cases, showing personal name
information and not addresses. Which renders the entire from domain
authorization check approach moot.

This has led people to suggest that we need to do something about validating
personal name information in From: header fields. This, along with all the
various schemes that are being proposed to work around the myraid issues with
third party message handling, increasingly looks to me like a tottering edifice
built of hack piled on hack piled on hack.

I think that at a minimum any change we propose needs to be compared against
the alternative of using the semantics defined for email 30+ years ago.

				Ned