SMTP server did not accept STARTTLS with error: 503 5.5.2 Send hello first

[hubipe]

Version: 3.1.3

Bug Description

After upgrading nette/mail to version 3.1.3 from 3.1.2, the e-mails won't send with exception:

Nette\Mail\SmtpException
SMTP server did not accept STARTTLS with error: 503 5.5.2 Send hello first [DB5EUR03FT018.eop-EUR03.prod.protection.outlook.com]

I suspect this pull request #67 to be an issue.

Steps To Reproduce

Send e-mail with this settings:

[
  'host' => '<hidden>.mail.protection.outlook.com',
  'port' => 25,
  'secure' => 'tls',
]

Expected Behavior

E-mail is sent

Possible Solution

Revert the pull request #67

[hubipe]

I also tried the connection through command line and telnet. With EHLO sent first, the SMTP server responded properly:

> telnet <hidden>.mail.protection.outlook.com 25
Trying 104.47.8.36...
Connected to <hidden>.mail.protection.outlook.com.
Escape character is '^]'.
220 AM5EUR03FT021.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Wed, 15 Jul 2020 11:50:29 +0000
> EHLO
250-AM5EUR03FT021.mail.protection.outlook.com Hello [<IP address hidden>]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
> QUIT
221 2.0.0 Service closing transmission channel
Connection closed by foreign host.

With sending STARTTLS command first, the server responded with an error:

> telnet <hidden>.mail.protection.outlook.com 25
Trying 104.47.9.36...
Connected to <hidden>.mail.protection.outlook.com.
Escape character is '^]'.
220 VE1EUR03FT049.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Wed, 15 Jul 2020 11:51:00 +0000
> STARTTLS
503 5.5.2 Send hello first [VE1EUR03FT049.eop-EUR03.prod.protection.outlook.com]
> EHLO
250-VE1EUR03FT049.mail.protection.outlook.com Hello [<IP address hidden>]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
> STARTTLS
220 2.0.0 SMTP server ready

[dg]

ping @ajaxovic

[ajaxovic]

Hmmm, that is strange, mail server hosted in cz.nic behaves differently:

telnet mail.<doamin>.cz 587
Trying <ipaddress>...
Connected to mail.<doamin>.cz.
Escape character is '^]'.
220 mail.<doamin>.cz ESMTP Postfix
EHLO mail.<doamin>.cz
250-mail.<doamin>.cz
250-PIPELINING
250-SIZE 25600000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

After some mailing with server admin, he said AUTH is not allowed on unsecured channels. Outlook says Can't secure before EHLO. So, two server configurations goes against each other. Frankly, I don't know right solution...

[ajaxovic]

Maybe one thing on the top of my head, is it OK to have TLS on port 25? Or should we use 587? Can you test it?

[hubipe]

@ajaxovic The port shouldn't be the problem as the SMTP communication works in different network layer.

[hubipe]

I don't fully understand the SMTP standard, but I've skimmed through the RFCs regarding the SMTP communication and this is what I found:

1. In RFC 2821 describing the SMTP, there is a section 4.1.1.1 (https://tools.ietf.org/html/rfc2821#section-4.1.1.1) defining the word EHLO and in second paragraph, there is a sentence: A client SMTP SHOULD start an SMTP session by issuing the EHLO
   command. Which doesn't require client to send EHLO as a first command, but in such a case, the client must have a valid reason not to do so.
2. In RFC 2487 (https://tools.ietf.org/html/rfc2487) describing the SMTP over TLS, in section 5: A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. So I understand, that any public SMTP server can't require clients to use TLS.
3. In the section 6 if the same RFC, there is an example of the SMTP session with the TLS negotiation. The client starts with the EHLO command
4. In the pull request SmtpMailer: Fix for servers which sends 250-AUTH only through encrypted connections #67 you (@ajaxovic) wrote as a reason for the pull request: There are some SMTP TLS servers, which does not send 250-AUTH PLAIN through non-tls channel... There is a RFC 4954 (https://tools.ietf.org/html/rfc4954) where in section 4 there is written: Note: A server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS [SMTP-TLS] command has been negotiated or some other mechanism that protects the session from password snooping has been provided. That explains, why the SMTP server does not offer a 250-AUTH PLAIN. It doesn't think, the session is secured. In my opinion, the 250-AUTH PLAIN is offered after the STARTTLS proccess.

To conclude, I'm convinced, that SMTP clients should in every session start with the command EHLO, then STARTLS, if they choose to (after which the client should send EHLO again), and finally they could start the AUTH process. If the server does not offer 250-AUTH PLAIN, then the server doesn't thinkg the connection is secured and requires you to use TLS.

[milo]

What about to try EHLO, if fails, STARTTLS and try it again?

[dg]

I am reverting #67, it seems not correct, it sends twice EHLO.

[dg]

@ajaxovic can you check this d9e2741?

[janlanger]

@dg We're getting similar error from Gmail SMTP on 3.1.3 - SMTP server did not accept STARTTLS with error: 503 5.5.1 EHLO/HELO first

d9e2741 also does not work, but with diferent error: SMTP server did not accept STARTTLS with error: 250-smtp.gmail.com at your service, [94.112.62.114] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 Maybe there should be second parameter here? d9e2741#diff-55f5cc92e7b5762927980bbfe6a1151cR158

[dg]

Hmmm, probably missing read(). Can you check this 9a86fb6?

[janlanger]

@dg Yeah, that works with gmail.