[Last-Call] Re: [Emailcore] draft-ietf-emailcore-as-28 ietf last call Secdir review

[Eliot Lear <[e-mail]>]

Hi Martin

On 29.04.2026 04:07, Martin Thomson wrote:
> I don't think that there is any attempt to change anything in that way.
>
> The only request is that the document not REQUIRE implementations to have a switch to turn STARTTLS off (or to turn off a mode where they insist on STARTTLS, to be more precise).  This:
>
>     Therefore:	
>     SMTP-receivers MUST be configurable to allow for receiving messages	
>     without specific confidentiality mechanisms, or even without	
>     confidentiality, between SMTP-senders and SMTP-receivers in order to	
>     maximize interoperation and avoid refusal of legitimate messages.	
>     While that provision is extremely important to promote delivery of	
>     legitimate messages whenever possible, mechanisms that provide	
>     confidentiality are still strongly preferred when they are feasible.
>
> The preceding paragraph already establishes why you probably need to allow for a lack of STARTTLS.  That is enough.  The paragraph I quote does nothing beyond that. It doesn't even do what it claims (maximize interoperation and avoid refusal) because the document doesn't prohibit deployments from turning the knob to "STARTTLS required".

Our documents should align to reality, especially when it comes to 
normative text.  The previous paragraph to which you refer is 
justification for this normative statement.  The pattern that is being 
followed here is roughly the same as we used in 1123 to evolve behavior 
toward a new norm.

While I do agree with Christian's and Pete's point that the separation 
between implementations and deployments in this space is not as crisp as 
it was in days of yore, I don't know what wording would resolve that 
particular messiness in a way that doesn't introduce other confusion.

Eliot


>
> On Wed, Apr 29, 2026, at 11:51, Pete Resnick wrote:
>> On 28 Apr 2026, at 19:15, Eric Rescorla wrote:
>>
>>> Again, we've got years and years of STARTTLS deployment without this requirement. What's the evidence this requirement is needed?
>>>
>> Wait...we've got years and years of STARTTLS deployment without the
>> "MUST implement STARTTLS" requirement. What's the evidence *that*
>> requirement is needed?
>>
>> As I said earlier, it is the introduction of the new requirement for
>> STARTTLS (more precisely, confidentiality) that leads us to want to be
>> clear that you also must provide for cleartext for the time being.
>> There would not be a need for that requirement if the new requirement
>> for confidentiality was not added in this document.
>>
>> pr
>>
>> --
>> Pete Resnickhttps://www.episteme.net/
>> All connections to the world are tenuous at best
>>
>> -- 
>> last-call mailing list [e-mail]
>> To unsubscribe send an email [e-mail]