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
- DMARC-4-ML: Can the IETF call a demonstration? Alessandro Vesely
- Re: DMARC-4-ML: Can the IETF call a demonstration? John C Klensin
- Re: DMARC-4-ML: Can the IETF call a demonstration? ned+ietf
- Re: DMARC-4-ML: Can the IETF call a demonstration? Alessandro Vesely
- Re: DMARC-4-ML: Can the IETF call a demonstration? John C Klensin
- Re: DMARC-4-ML: Can the IETF call a demonstration? Hector Santos
- Re: DMARC-4-ML: Can the IETF call a demonstration? John C Klensin
- Re: history of From: validation, was DMARC-4-ML John Levine
- Re: history of From: validation, was DMARC-4-ML Hector Santos
- Re: DMARC-4-ML: Can the IETF call a demonstration? Dave Crocker
- Re: DMARC-4-ML: Can the IETF call a demonstration? Alessandro Vesely
- DMARC: A solution using ATPS RFC6541 extension Hector Santos