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

"John Levine" <> Mon, 11 January 2016 16:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 36B0C1A8767 for <>; Mon, 11 Jan 2016 08:34:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.863
X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eoab-YcZgz8S for <>; Mon, 11 Jan 2016 08:34:25 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADAC91A883E for <>; Mon, 11 Jan 2016 08:34:24 -0800 (PST)
Received: (qmail 11504 invoked from network); 11 Jan 2016 16:34:23 -0000
Received: from unknown ( by with QMQP; 11 Jan 2016 16:34:23 -0000
Date: 11 Jan 2016 16:34:01 -0000
Message-ID: <20160111163401.48404.qmail@ary.lan>
From: "John Levine" <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
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 16:34:26 -0000

>> Only sort of.  In this case, the downgrade path is obvious, you
>> ignore the TLS flag and send the message along.
>That's the opposite of the goal here. SMTP makes tries to delivery
>messages, even if that results in a downgrade in security. The goal here
>is to fail the transmission of REQUIRETLS tagged messages that can't be
>sent in accordance with the originator's security requirements.

Of course, but there's no reason for recipient MTAs to pay any
attention to the tag if they don't want to.  There is no penalty to
them for doing so.  With EAI there's at least the penalty of messages
getting smashed.

>But you make a good point about the fake MX problem: if you're concerned
>about DNS attacks, you need to make sure that the recipient domain, and
>not just the domain of the MX server, is DNSSEC protected. That's an
>oversight in the specification I will correct.

RFC 7672 which has already addressed that issue in great detail.