Re: [Emailcore] Issue 80 - Clarify where the protocol stands with respect to submission and TLS issues

[John C Klensin <[e-mail]>]

--On Wednesday, December 6, 2023 14:22 -0500 Hector Santos
<hsantos=[e-mail]> wrote:

> If I may,  I wish to add an implementation antidote note. In
> our ongoing battle to control SMTP attacks, we recently
> updated our SMTP server to required TLS for AUTH.   In other
> words,  AUTH is not presented in initial EHLO response if the
> session is not encrypted (by issuing STARTTLS first). So far,
> session trace logs show it has made a difference, albeit
> small, a difference nonetheless.    I do wonder how other SMTP
> servers behave.  It may depend on SASL methods available
> (plain text vs encrypted).

Hector,

If I correctly understand you, you have decided that, because
you are requiring AUTH and TLS, you have decided to not publish
the availability of the AUTH extension in the EHLO response.
That is a clear violation of the standard (not just 5321/5321bis
but all of their ancestors going back to RFC 1425).  What I
don't understand is what you think it accomplishes.   

The situation is a bit like the one with 8-bit-clean
implementations and 8BITMIME.   In that case, we hope the server
will advertise the extension but they will accept message
content with octets with the high bit on regardless of whether
the BODY command is sent by the client or not.  That means that,
other than conformance to the standard (and that is easy), the
only advantage for those servers of announcing 8BITMIME over not
doing so is that, if the client notices that the extension is
not announced, it might decide (fully consistent with spec) to
reject/bounce the message or convert it to some inconvenient and
annoying Content-transfer-encoding.  The only advantage to an
8-bit-clean server of _not_ advertising the extension... well,
other than saving about ten octets in the EHLO reply and AFAICT,
there isn't one.

Now consider what I understand you to be saying.  Your server
does not advertise the AUTH extension but you expect clients to
invoke AUTH and send the message over TLS anyway.  Your
situation then differs from the 8-bit-clean situation a bit
because, if the client does not start a TLS session, you are
going to reject the message.   However, it seems to me that
there are no advantages to not advertising the extension and one
disadvantage, which is that a client, noticing that you did not
include AUTH in the EHLO comment, might conclude that your
server and the systems surrounding it do not take privacy and
security seriously enough and refuse to send the message. 

So, did I misunderstand and, if I did not, what is your
reasoning behind not announcing the AUTH command?

thanks,
   john


> 
> 
> All the best,
> Hector Santos
> 
> 
>> On Nov 30, 2023, at 3:14 PM, Todd Herr
>> <todd.herr=[e-mail]> wrote:
>> 
>> Greetings.
>> 
>> The subject issue
>> (https://github.com/ietf-wg-emailcore/emailcore/issues/80)
>> was discussed during the 29 November 2023 interim. The
>> initial comments from November 2022 in the Github issue read
>> as follows:
>> 
>> submission on port 587
>> submission on port 465
>> TLS relay on a port different from 25 (whenever)
>> Recommendations about general use of transport layer (hop by
>> hop) security, particularly encryption including
>> consideration of RFC 8314.
>> The MTA-to-MTA relay case is now covered by now closed ticket
>> #54
>> <https://github.com/ietf-wg-emailcore/emailcore/issues/54>.
>> Do we need to say anything about submission and RFC 8314?
>> 
>> The conversation at the interim seemed to coalesce around the
>> idea that section 6 of the current version of the A/S
>> (https://www.ietf.org/archive/id/draft-ietf-emailcore-as-08.h
>> tml#name-confidentiality-and-authent) addresses this topic
>> save for no mention of port 465. 
>> 
>> It is recorded in the comments for this issue that the A/S
>> should be updated to acknowledge the existence of port 465
>> and the ticket should be closed. Specifically, this sentence
>> in section 6.4:
>> 
>> SMTP AUTH defines a method for a client to identify itself to
>> a Message Submission Agent (MSA) when presenting a message
>> for transmission, usually using port 587 rather than the
>> traditional port 25.
>> 
>> should be updated to read as follows:
>> 
>> SMTP AUTH defines a method for a client to identify itself to
>> a Message Submission Agent (MSA) when presenting a message
>> for transmission, usually using ports 465 or 587 rather than
>> the traditional port 25.
>> 
>> Please consider what was recorded from the interim and either
>> declare your support for making this change to the A/S and
>> closing this issue or provide candidate text for insertion
>> into the next revision of the A/S.
>> 
>> Thank you.
>> 
>> -- 
>> Todd Herr  | Technical Director, Standards & Ecosystem
>> e: [e-mail] <mailto:[e-mail]>
>> p: 703-220-4153
>> m: 703.220.4153
>> 
>> This email and all data transmitted with it contains
>> confidential and/or proprietary information intended solely
>> for the use of individual(s) authorized to receive it. If you
>> are not an intended and authorized recipient you are hereby
>> notified of any use, disclosure, copying or distribution of
>> the information included in this transmission is prohibited
>> and may be unlawful. Please immediately notify the sender by
>> replying to this email and then delete it from your system.
>> -- 
>> Emailcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/emailcore
>