Mailkit can't authenticate in poste.io

[Георгий Драк]

See this issue - https://github.com/jstedfast/MailKit/issues/162. Mailkit sends EHLO after success auth and receive 503 response. SMTP Log:

Connected to smtp://...:587/?starttls=always
S: 220 ....ru ESMTP
C: EHLO [...]
S: 250-mail.....ru Hi Unknown [...]
S: 250-PIPELINING
S: 250-8BITMIME
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead with TLS
C: EHLO [...]
S: 250-mail.....ru Hi Unknown [...]
S: 250-PIPELINING
S: 250-8BITMIME
S: 250 AUTH PLAIN LOGIN
C: AUTH PLAIN ...
S: 235 PLAIN authentication successful for ...@....ru - auth success for ...@....ru
C: EHLO [...]
S: 503 but you already said HELO ...
C: HELO [...]
S: 503 but you already said HELO ...

[SH]

I was unable to find RFC stating that it should be sent. It seems strange to send another one ehlo after auth...

[Jeffrey Stedfast]

It wouldn't actually be strange to EHLO after an AUTH command (some AUTH commands can negotiate security layers, even if PLAIN does not). Secondly, consider the fact that it would not be out of the realm of possibility that a server might want to offer additional functionality to clients that have authenticated that it might not want to offer for non-authenticated clients.

E.g. commands like VRFY and EXPN would be good candidates.

[Jeffrey Stedfast]

That said, and as I have already mentioned in the comments at https://github.com/jstedfast/MailKit/issues/162, the rfc that defines the PLAIN SASL mechanism does explicitly state that it does not provide a security layer and so, by the wording of rfc2554/rfc4954 suggests that MailKit should not be issuing a followup EHLO command after a successful AUTH (at least with PLAIN - mechanisms such as GSSAPI would be a different story).

[SH]

@jstedfast Thanks for explanation, it makes very sense now!

[Георгий Драк]

Ok, thanks