Re: [perpass] Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt

Jim Fenton <> Thu, 18 February 2016 03:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F2D61A923E for <>; Wed, 17 Feb 2016 19:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Status: No, score=-2.007 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.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gGk736dfWVLf for <>; Wed, 17 Feb 2016 19:43:02 -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 B3E311A8A01 for <>; Wed, 17 Feb 2016 19:43:02 -0800 (PST)
Received: from splunge.local ([]) (authenticated bits=0) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id u1I3gxBi004526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Feb 2016 19:43:01 -0800
To: Yakov Shafranovich <>
References: <> <> <>
From: Jim Fenton <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 17 Feb 2016 19:42:59 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=supersize; t=1455766982; bh=sPD0MTujYZTURFxNXjjtO7NlTlgU5HBg4/uV3Uh+Mdw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=lUR4UuSy9Ln4vTMPpXFWfHXonjQ//bRUL6xuQWRYPqfaAZRndcWKenRM1oogWX4N+ H/MF0LMbWyBqmiUAVzR2UXU+Wa1Q6uhtfFXVWwxUmE3D4Wd6J3wq3UKs1DWA+2iUeF 4G5DIOclVTdM08wmuHYXR/z8ndP3lgYWnSHCkxb0=
Archived-At: <>
Cc: perpass list <>
Subject: Re: [perpass] Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Feb 2016 03:43:04 -0000

On 2/17/16 2:13 PM, Yakov Shafranovich wrote:
> Some minor comments:
> Section 1:
> "It also requires that the SMTP server advertise
>    that it also supports REQUIRETLS, in effect promising that it will
>    honor the requirement to require STARTTLS and REQUIRETLS for all
>    onward transmissions of messages specifying that requirement."
> "
> The part about "promising" does not seem to go together with the
> optional parameter in section 2 about onward transmission.

If you are saying that the statement in Section 1 is incomplete because
it does not say that the server must honor the requirements of the
optional (server authentication) parameter as well, I agree.

> Section 3.1 - tagging:
> I am wondering if an email header should be defined to carry this
> data, which would also allow for auditing by the receiver. Sort of
> similar to the SPF/DKIM headers used today.

One could be defined, but that would be a message format extension (RFC
5322) rather than a mail transport extension (RFC 5321). It would then
be necessary to define under what circumstances the new header field
would be moved into the transport realm.  I thought it to be more
straightforward to consider REQUIRETLS to be an aspect of the message
envelope (like the envelope-to and envelope-from addresses) rather than
a header field.
> Section 3.4 - delivery:
> It is unclear what "delivery" means here, especially considering that
> SMTP may relay messages to another server, perhaps reference RFC 5598?
> Also, the parts in section 1 and the optional parameter in section 2
> should play together with this, perhaps by requiring TLS in IMAP, etc.
> or not. Either way, this may need clarification.

I have been trying to void "boiling the ocean" by constraining this
feature to SMTP. From the context, it should be clear that by delivery I
was referring to protocols such as IMAP and POP, although webmail
applies here as well. Are you suggesting that this requirement should be
a MUST rather than the SHOULD I proposed?
> Section 5:
> What are the actual added codes? I believe 5.7.10 already exists.

5.7.10 does exist, but seems to have the right semantics ("Encryption
needed"). The others will need to be allocated and since they are
numeric codes I didn't presume to define them myself.

> Section 6:
> Maybe reference RFC 4949 for terminology?

I'll have a look at 4949.
> One other comment - perhaps some sort of limiting digital signatures
> for headers only like DKIM can be employed by the receiving MTA to
> certify that the receipt and transmission was effective? I am thinking
> along the lines of Received headers or DKIM headers, which would allow
> traceability.

This seems to be a separate feature - authenticated return receipts.
This might be useful, but I don't think it belongs here.  I would hope
that MTAs would add information about REQUIRETLS to their Received:
header fields, much as they do about the use of TLS for messages they
receive, but I haven't worked out quite how to specify that yet.
> Yakov

Thanks for your review!