Subject: [Uta] Late comment on REQURIETLS: Received header field

From: Jim Fenton <[email-masked]>
Date: Fri, 14 Sep 2018 12:59:44 -0700

In addition to the comment from Viktor a couple of weeks ago, I received 
a suggestion off-list the other day that is worthy of discussion. The 
submitter did not want to join the mailing list but did agree to the 
terms of the Note Well.

The suggestion:

> I had the idea, that it would be useful to see the status of the 
> requested REQUIRETLS service level in the "Received" trace header, 
> which is inserted by the MTA using simple comments. Having this, you 
> could see at which point in message flow the REQUIRETLS was inserted 
> (and lost), as well as detection of mis-behaving MTAs. And it gives 
> the recipient of such a message more confidence because he can see 
> what really happened. For this purpose, adding such information into 
> the trace header must be mandatory for each MTA supporting Require TLS.
> Examples:
>
>     Received: from example.com (example.com [127.0.0.1])
>     	by relay.com (Postfix) with ESMTP
>     	(using REQUIRETLS)
>     	for<[email-masked]>; Thu,  6 Sep 2018 11:46:34 +0200 (CEST)
>     or
>
>     Received: from example.com (example.com [127.0.0.1])
>     	by relay.com (Postfix) with ESMTP
>     	(using RequireTLS:No)
>     	for<[email-masked]>; Thu,  6 Sep 2018 11:46:34 +0200 (CEST)
>
>     These strings should be well-defined by RFC.
>

I am under the impression that the contents of the Received header field 
are (in practice, at least) somewhat ad hoc, at least with respect to 
transport characteristics like the use of TLS. So I'm not sure how 
well-defined these can be, but we could at least suggest the annotation 
of whether the message was received with the RequireTLS option included. 
This would be primarily for diagnostic purposes, because of course any 
MTA along the path could falsify that information.

I'm less convinced of the value in the RequireTLS:no case, because that 
is already expressed in a header field, and there isn't any 
characteristic of the incoming SMTP session to note.

Any other thoughts on whether this would be a valuable addition?

-Jim

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 14 Sep 2018 16:49:43 -0700

On 14 Sep 2018, at 12:59, Jim Fenton wrote:
> In addition to the comment from Viktor a couple of weeks ago, I 
> received a suggestion off-list the other day that is worthy of 
> discussion. The submitter did not want to join the mailing list but 
> did agree to the terms of the Note Well.
>
> The suggestion:
>
> I am under the impression that the contents of the Received header 
> field are (in practice, at least) somewhat ad hoc, at least with 
> respect to transport characteristics like the use of TLS. So I'm not 
> sure how well-defined these can be, but we could at least suggest the 
> annotation of whether the message was received with the RequireTLS 
> option included. This would be primarily for diagnostic purposes, 
> because of course any MTA along the path could falsify that 
> information.
>
> I'm less convinced of the value in the RequireTLS:no case, because 
> that is already expressed in a header field, and there isn't any 

Received has a well-defined extensible syntax as of RFC 2822. Comments 
are not an extensibility mechanism and the contents of comments have no 
interoperable semantic value and should never be standardized if there's 
a reasonable non-comment alternative syntax.

Since Received is a trace header I think it's more important to record 
what actually happened with respect to TLS rather than to record policy 
that impacted what happened. There's already a standard way to record 
the fact TLS was used via the "WITH clause":

  https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-5

and a standard way to record the cipher suite:

  https://tools.ietf.org/html/rfc8314#section-4.3

If the WG deems it important to record 'requiretls' policy, I'd prefer 
that be done by adding new options to the "WITH" clause of Received for 
the sake of consistency with prior work.

		- Chris