[Uta] Implementing STS
Arvel Hathcock <arvel@thehathcocks.com> Thu, 14 April 2016 14:20 UTC
Return-Path: <arvel@thehathcocks.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9012D5A9 for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 07:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level:
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_12LTRDOM=0.1, RDNS_DYNAMIC=0.982] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thehathcocks.com
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 HV1m1I2ZwTdo for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 07:20:01 -0700 (PDT)
Received: from mail.thehathcocks.com (108-198-31-66.lightspeed.rcsntx.sbcglobal.net [108.198.31.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD24112D12A for <uta@ietf.org>; Thu, 14 Apr 2016 07:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=thehathcocks.com; s=MDaemon; t=1460643602; x=1461248402; i=arvel@thehathcocks.com; q=dns/txt; h=MDPGP-Results:From:To:Subject:Message-ID:Date: User-Agent:MIME-Version:Content-Type; bh=YcMz1+r5Tw5tkBMbaWJj7KY qdUMSFW8VlXuIXqEt/vE=; b=jkbAmNRLsRzSollkEXIFsCSa6ezKy2pZ7keVoCA fd4IZms0s18eT5dKODmEyYSiCwaBgwyBqcYgolV4+1qQ8JvlBJVqqFCyCc2As/11 +Qu5FoFR1NuzF64icsooW0eXt6iqvwx4NLQ3SkH3qburi6ujI2W5Q0HFH+R/xSgr jLS4=
X-MDAV-Result: clean
X-MDAV-Processed: mail.thehathcocks.com, Thu, 14 Apr 2016 09:20:02 -0500
Received: from [x.x.x.x] by mail.thehathcocks.com (Cipher TLSv1.2:AES-SHA:256) with ESMTPSA id md50000134622.msg for <uta@ietf.org>; Thu, 14 Apr 2016 09:20:02 -0500
X-Spam-Processed: mail.thehathcocks.com, Thu, 14 Apr 2016 09:20:02 -0500 (not processed: message from trusted or authenticated source)
X-MDRemoteIP: 108.198.31.66
X-MDArrival-Date: Thu, 14 Apr 2016 09:20:02 -0500
X-Authenticated-Sender: arvel@thehathcocks.com
X-Return-Path: arvel@thehathcocks.com
X-Envelope-From: arvel@thehathcocks.com
X-MDaemon-Deliver-To: uta@ietf.org
MDPGP-Results: mail.thehathcocks.com; Thu, 14 Apr 2016 09:20:02 -0500; id=051582; t=s; e=arvel@thehathcocks.com; k=052328682E7D7DF5; signed by arvel@thehathcocks.com with key-id 052328682E7D7DF5
From: Arvel Hathcock <arvel@thehathcocks.com>
To: uta@ietf.org
Message-ID: <570FA711.9060307@thehathcocks.com>
Date: Thu, 14 Apr 2016 09:20:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="MDaemon_PGP_part_boundary_1460643601"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/FmHK6KQ3ur_6LSWYkhCTf9XOPnQ>
Subject: [Uta] Implementing STS
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 14:20:02 -0000
Hi everyone! I just wanted to speak up and say that in the case of my MTA (MDaemon) the question of whether to link in a web-client lib is a non-issue because (for me) that had to be done years ago. Perhaps that lib is not called by the SMTP delivery code but its in the EXE already at least. I have no serious issue with this and one way to handle it (as I think was mentioned before) is by deferring back to queue any delivery attempt which finds a previously unknown STS policy record until such time (not long) as a separate thread safely dedicated to the task can validate the policy and update the cache file. I will have to take this approach due to my MTA's internal design. I also wanted to mention that I serve the world of the very small on-premise business community and I've received numerous emails stating the expectation and desire to have something like this implemented for them. This is a consequence of the STS articles etc recently put to press but also shows that its not only the big players who might push for it. Its true though that the vast majority are oblivious to these matters (which is fine) and they want us vendors to "just handle it" (which we should). So I hope that this effort moves forward and above all does not get overly complicated. A couple of tiny minor spec things for starters: Section 3 says that MX patterns are required yet the example at the end of the doc doesn't have them. Also, "_.example.com" has the _ char as the wild-card. Maybe there's a reason not to use * for this? See, minor stuff. It would be good to have some reference STS records/hosts setup somewhere that implementers can test against. Arvel
- Re: [Uta] Implementing STS Viktor Dukhovni
- [Uta] Implementing STS Arvel Hathcock