Re: [Shutup] [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt

Jim Fenton <> Mon, 11 January 2016 03:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D6281A6F99; Sun, 10 Jan 2016 19:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gVCwjY8Rn-r8; Sun, 10 Jan 2016 19:15:56 -0800 (PST)
Received: from ( [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 202461A6F8E; Sun, 10 Jan 2016 19:15:55 -0800 (PST)
Received: from [IPv6:2001:470:1f05:bfe::3] ([IPv6:2001:470:1f05:bfe::3]) (authenticated bits=0) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id u0B3FqOx022628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 10 Jan 2016 19:15:54 -0800
To: John Levine <>,,
References: <20160111013623.43568.qmail@ary.lan>
From: Jim Fenton <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 10 Jan 2016 19:15:52 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20160111013623.43568.qmail@ary.lan>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=supersize; t=1452482155; bh=pKIGsMiH4jhxFwyrx0aJNH/uw4Des+74c57dPBEjWns=; h=Subject:To:References:From:Date:In-Reply-To; b=R11jEngg9im3gAe7rGOVIWJgl+GXSZmUIFcSF2E4pADA8Pyj2sOYIgCgt1XBGV+Ir MvE8WgfulmKxUnMcLIYN4OMzoDAkyrL/b/xH48cFMwAKiAPfEWAF0Qn+xVQcQkUdin p1BQrv9RjGDKBWfP5Ms+iHiLqv6WcpGMbOX4Ovq0=
Archived-At: <>
Subject: Re: [Shutup] [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jan 2016 03:15:57 -0000

[not sure if this is germane to the shutup list if I understand the
charter there correctly, but I'll go along with it for now]

On 01/10/2016 05:36 PM, John Levine wrote:
> In article <> you write:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>> Below is the announcement of a draft I just submitted that may be of
>> interest to this list. The approach here is complementary to the other
>> proposals I have seen along these lines (e.g., smtp-sts).
>> Thoughts, reviews, etc. welcomed.
> Interesting idea.  I implemented it on my server

That was quick :)

> PS: Of course, there's no way you can tell whether it'll actually do
> anything different if you set requiretls.  The inability to detect,
> much less penalize, lying strikes me as a problem.

You're describing a mail server that not just hasn't deployed TLS and
REQUIRETLS, but one that is being actively deceptive. There are more
fundamental undetected issues even without REQUIRETLS.

As a mail originator sending messages I consider sensitive, my biggest
concern would be that my outgoing mail operator isn't lying about
REQUIRETLS. There could easily be test reflectors that fail REQUIRETLS
in various ways, i.e., not supporting TLS at all, not supporting
REQUIRETLS, and offering certificates that don't meet various
verification requirements. If the messages go through, the user knows
that someone is lying.

The more general cases of REQUIRETLS deception, particularly within an
administrative management domain, may be hard to test, but those
probably aren't the biggest areas of concern for TLS deployment either.