Re: history of From: validation, was DMARC-4-ML
"John Levine" <johnl@taugh.com> Thu, 15 May 2014 04:03 UTC
Return-Path: <johnl@iecc.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 052D91A0222
for <ietf@ietfa.amsl.com>; Wed, 14 May 2014 21:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.563
X-Spam-Level: *
X-Spam-Status: No, score=1.563 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311,
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 4PRcNCrVzEv2 for <ietf@ietfa.amsl.com>;
Wed, 14 May 2014 21:03:52 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net
[IPv6:2001:470:1f06:1126::2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 721231A021B
for <ietf@ietf.org>; Wed, 14 May 2014 21:03:51 -0700 (PDT)
Received: (qmail 26955 invoked from network); 15 May 2014 04:03:41 -0000
Received: from miucha.iecc.com (64.57.183.18)
by mail1.iecc.com with QMQP; 15 May 2014 04:03:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com;
h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding;
s=14ad2.53743c9d.k1405; i=johnl@user.iecc.com;
bh=oC/kmksvE0yFUmeZYtP7AtC+8h5kuPtRB/ok/xHj2zg=;
b=D652irsDwKHgCp+h7I/MnwTvH9KYkAL83wcHF7Ofi7UNn07gBi+StOTkFRdBMNUL4adZoUuQbi159YP4lcd4R5u+ky/bSAiscHc2fGU9BUlkPbDRZxFV9FCRwDi5PoSNeB09cRXMeCla6XtYygGX8Yz5zcBCALCUJcLWjwwBJrDjO2w1ClZo8subnFE6RQmwVPUdpbUsb2LJWRNGr1bbd9wDNnk5GpIm79zUvRFserlbI8Kf2kLYKqhrZ3fo3cvJ
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com;
h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding;
s=14ad2.53743c9d.k1405; olt=johnl@user.iecc.com;
bh=oC/kmksvE0yFUmeZYtP7AtC+8h5kuPtRB/ok/xHj2zg=;
b=Q72CnAMutNtW1PKImFyN83Ryi6ZTiklhJSwGR6lBOF0TDK3dgYZk5wrX9iv+/VWopeNc59fHK+WW3ZptOuCy7QcqkVzmqNb9DExkkLcR6axuJbkaGovw78lD0eLYsssiHL6yfFum2+GaDj30sQX3Uwyj1qHrTSZAngo0mJABRkrzF+NNkIMWeKpeJLbGY435qgxXb/rxnRC0Ao9y5T9Z/QtZLwXtYd5GNvGe/jVhs14dHN1NY1iOLu0SfRWA9PvC
Date: 15 May 2014 04:03:19 -0000
Message-ID: <20140515040319.84689.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: ietf@ietf.org
Subject: Re: history of From: validation, was DMARC-4-ML
In-Reply-To: <01P7SNU0YUVS000052@mauve.mrochek.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY
Cc: ned+ietf@mauve.mrochek.com
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: Thu, 15 May 2014 04:03:54 -0000
>In fact an argument can be made that in terms of responsible mail handling, >DMARC is actually an improvement over ADSP. In particular, ADSP provides policy >choices of "unknown", "all", and "discardable", wheras DMARC provides "none", >"quarantine", and "reject". Honoring a "discardable" policy causes mail to be >lost, whereas at least "reject" provides an indication that something went >wrong. Discardable was supposed to be a feature, to avoid backscatter, and on the theory that if the mail is that awful, the sooner it goes away the better. Given the current DMARC fiasco, I'd say it was not a bad choice. I pointed out at the time that "discardable" did not mean your mail was important, on the contrary it meant that your mail was unusually unimportant, since you were telling people to throw it away if there were any doubt about it. >The fact that ADSP was developed in tandem with DKIM also means that the IETF >cannot reasonably claim that attaching these sorts of semantics to From: fields >was in any way unexpected. As such, there was at least a responsibility to >document likely interoperability problems use of DKIM in this way would cause. Well, I tried. I shoehorned my way into the ADSP draft because I anticipated almost exactly the problems with ADSP that we're seeing with DMARC. The other authors didn't disagree, but did say that they wanted each domain to be able to publish its own policy. I thought that was a lousy idea, because I saw no reason to expect that domain owners would publish reasonable policies, but instead would tend to publish overly strict policies in the mistaken belief they were "more secure". I turned out to be right, since around the time that ADSP was published, some subscriber to IETF lists published a discardable policy, which was wrong, and someone else overimplemented ADSP with rejections rather than discards, which was really wrong, and the latter group promptly bounced themselves off the IETF list. What I said at the time was that rather than ADSP, you wanted credible third parties publishing lists of domains for which strict ADSP-like behavior was appropriate. That's exactly what happened--look inside spamassassin and you'll find a module nominally about ADSP, but with the real ADSP checks turned off by default and a short list of fake ADSP entries for the usual suspects, ebay, paypal, etc. The only thing I got wrong was that I expected the damage to come from large numbers of small clueless operators publishing strict policies, like a flock of tiny gorillas beating their wee chests and shouting "Fear us, O Internet!" in high squeaky voices. It never occurred to me that two of the largest and most sophisticated mail operators in the world would do such a thing. R's, John
- 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