Re: DMARC-4-ML: Can the IETF call a demonstration?

Alessandro Vesely <vesely@tana.it> Fri, 16 May 2014 13:48 UTC

Return-Path: <vesely@tana.it>
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 18CD21A0061 for <ietf@ietfa.amsl.com>; Fri, 16 May 2014 06:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.026
X-Spam-Level:
X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 tCyshTxJOI1E for <ietf@ietfa.amsl.com>; Fri, 16 May 2014 06:48:44 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4A81A0062 for <ietf@ietf.org>; Fri, 16 May 2014 06:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1400248114; bh=GwSJi8+jt50FeMiBs3ohaClNXTs0vzC1oKamj15ko68=; l=2093; h=Date:From:To:References:In-Reply-To; b=kqewMEz8+wnJS3FNIpvaLDKWuhfdnTl7MsnLImbWDEoQWipF99rfaPS+o3v5UI9wa sqCnrYdIXuO8GAhan8Or5LnmlVIeCMeUBsKr5qCjiyRZ2w25GrRvI8zYVEJR+FN2if soHquCJUthJTDX87GsCe5NvpCKcABRlOL1+Bt1p8=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 16 May 2014 15:48:34 +0200 id 00000000005DC035.0000000053761732.00002235
Message-ID: <53761732.1020308@tana.it>
Date: Fri, 16 May 2014 15:48:34 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: DMARC-4-ML: Can the IETF call a demonstration?
References: <537358E1.8060101@tana.it> <0168AF240FBAEFE4174A1B21@JcK-HP8200.jck.com> <5374D981.8030404@dcrocker.net>
In-Reply-To: <5374D981.8030404@dcrocker.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/rxYoYTeVi1q1-hxkH40KCf8LtUQ
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: Fri, 16 May 2014 13:48:46 -0000

On Thu 15/May/2014 17:13:05 +0200 Dave Crocker wrote:
>
>   2.  There is nothing that requires mailing lists to make adjustment.
> Arguably, it is better for mailing lists NOT to make adjustments, so
> that those affected users can consider the efficacy of their current
> account.

I'm disappointed.  I know p=reject, like dkim=discardable before it,
was meant to be used by domains that "don't have individual human
users".  I cannot help comparing it to SPF's -all.  In fact, DMARC's
overview[1] suggests that the monitoring step be followed by policy
adjustment.  Looking at DMARC reports, one can guess whether an
authentication failure originates from abuse or from a possibly
forwarded mailing list post.  Setting a strict policy would kill both.
 OTOH DMARC is perfectly useless with p=none.

What does it take to set up a "human" domain, then?  It's way harder
than a web site.  Several organizations give up working out their own
way to configuring a mail server.  Google do an excellent job at
filtering.  Besides marking as spam and email authentication, they
deploy literally hundreds of signals, whose relative importance is
dynamic and determined on complex algorithms[2], which are definitely
beyond the reach of an average company with a smallish IT dept.

Now, being forced to outsource email has obvious privacy issues.  I
want to ask whether the onset of giant, all-monitoring, central email
plants is part of "the basic design assumptions of Internet email".
If not, we ought to consider putting the restoring of a well-defined,
simple email functionality among the Internet 2020 goals.  Can DMARC
generalization be regarded as a spontaneous move in that direction?
It requires adjustments in mailing lists and other niches such as WSJ
send-an-article and gmail sending.  But what are the alternatives?

Ale

[1] How Senders Deploy DMARC in 5-Easy Steps, bottom section in
http://www.dmarc.org/overview.html

[2] summary of a talk with Sri Somanchi on Gmail's Anti-Spam Team
http://www.campaignmonitor.com/blog/post/4196/gmail-focus-on-engagement