IETF Logo Mail Archive

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

"Mark Delany" <sx6un-fcsr7@qmda.emu.st> Sat, 10 February 2018 09:23 UTC

Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93F412D860 for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sat, 10 Feb 2018 01:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emu.st
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 P9brW5G4PCPa for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sat, 10 Feb 2018 01:23:38 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88FD124D37 for <ietf-dkim-archive@ietf.org>; Sat, 10 Feb 2018 01:23:38 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [127.0.0.1]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1A9MVdG011985; Sat, 10 Feb 2018 01:22:32 -0800
Authentication-Results: simon.songbird.com; dkim=fail reason="verification failed; unprotected key" header.d=emu.st header.i=@emu.st header.b=hVziMIyz; dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1A9MRYI011981 for <ietf-dkim@mipassoc.org>; Sat, 10 Feb 2018 01:22:28 -0800
Received: by f3.bushwire.net (Postfix, from userid 1001) id 0D47C34AA0C; Sat, 10 Feb 2018 19:21:28 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2017; t=1518254488; bh=1Snmq8+1owZqBOlD1jYdrvyK0bY=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=hVziMIyzapRSg8lpnGmRibAz2ds8i8NNZOsuvVJ4PhjFhh2TF/BWNn9/z2du8hC7b dnpVrgANvFtuJR+rwJogSJUYfZh7h499aCONDHJK36c84yIUdIkSBM36wUSn6Cmfe6 s3SfRFsZUlh8i7LyX1WeSf+UvX6JyAed5UWU6qOE=U6qOE=
Comments: QMDA 0.3a
Received: (qmail 33399 invoked by uid 1001); 10 Feb 2018 09:21:27 -0000
Date: Sat, 10 Feb 2018 09:21:27 +0000
Message-ID: <20180210092127.33398.qmail@f3-external.bushwire.net>
From: Mark Delany <sx6un-fcsr7@qmda.emu.st>
To: DKIM List <ietf-dkim@mipassoc.org>
References: <alpine.OSX.2.21.1802091731220.56915@ary.qy>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.21.1802091731220.56915@ary.qy>
Subject: Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim/>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: ietf-dkim-bounces@mipassoc.org
Sender: ietf-dkim <ietf-dkim-bounces@mipassoc.org>

On 09Feb18, John R. Levine allegedly wrote:

> RFC 822 may not have versions but 821/2821/5321 sure do.
> 
> As soon as 2821 added EHLO, SMTP got service extensions and pretty
> much by their nature, those extensions are not backward compatible.
> 
> Well-known examples are 8BITMIME and SMTPUTF8.  If you have a message that needs
> one of those and the server you're trying to send it to doesn't support the
> extension, you lose, the message bounces.

I'm not sure whether this an argument for or against versioning. Or an argument
that sometimes bad engineering choices are made regardless of the upgrade
mechanism.

In any event, 822 is an existence-proof that decades-long upgrades are entirely
possible without the scorched-earth approach of versioning. I hope it would take
a very strong argument to suggest that we shouldn't (or can't) follow the 822
strategy.


Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

v2.23.0 | Report a Bug | By Email