EHLO after AUTH causes send failure with 5.7.0 even though authentication succeeded

[fubar-coder]

I've found a problem with an E-Mail provider (Strato) that causes a 5.7.0 error after a successful authentication (2.7.0) due to the sent EHLO after the authentication.

Connected to smtp://smtp.strato.de:587/
S: 220 smtp.strato.de ESMTP RZmta 37.4 ready (mo11)
C: EHLO [192.168.1.70]
S: 250-smtp.strato.de greets 79.194.205.58
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-PIPELINING
S: 250-DELIVERBY
S: 250-SIZE 104857600
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
S: 250-STARTTLS
S: 250 HELP
C: STARTTLS
S: 220 Ready to start TLS
C: EHLO [192.168.1.70]
S: 250-smtp.strato.de greets 79.194.205.58
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-PIPELINING
S: 250-DELIVERBY
S: 250-SIZE 104857600
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
S: 250 HELP
C: AUTH SCRAM-SHA-1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
S: 334 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
C: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
S: 334 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
C: 
S: 235 2.7.0 OK Authenticated
C: EHLO [192.168.1.70]
S: 250-smtp.strato.de greets 79.194.205.58
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-PIPELINING
S: 250-DELIVERBY
S: 250-SIZE 104857600
S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
S: 250 HELP
C: MAIL FROM:<XXXXXXXX@XXXXXXX.de>
C: RCPT TO:<XXXXXXXX@XXXXXXX.de>
S: 530 5.7.0 Bitte konfigurieren Sie ihr E-Mailprogramm fuer Authentifizierung am SMTP Server, wie auf www.strato.de/email-hilfe beschrieben. - Please configure your mail client for using SMTP Server Authentication
S: 503 5.5.1 need MAIL FROM first
C: QUIT
S: 221 2.0.0 closing connection

[jstedfast]

Can you please report this bug to Strato? Clients are supposed to send EHLO after authenticating.

The reason the RFC says SHOULD and not MUST is because it depends on whether or not the client uses extensions. If the client doesn't use extensions, then obviously it doesn't need to re-fetch them. Otherwise it needs to.

[fubar-coder]

I tried, but they don't give a **** about standard compliance and they're big enough to get away with it 😞 . They don't even provide E-Mail support for non-customers...

[jstedfast]

I've committed a different workaround. I'd rather not introduce public APIs to work around broken servers.

[fubar-coder]

Thank you 👍

[cnblogs-dudu]

smtp.dm.aliyun.com has the same problem.

[jstedfast]

I've released MailKit 1.4.1 with a fix for this to nuget.org

[analogic]

@jstedfast Can you please point me to RFC? I have found only https://tools.ietf.org/html/rfc4954 which states that there should be additional EHLO only after TLS negotiation.

(ref https://bitbucket.org/analogic/mailserver/issues/183/mailkit-cant-authenticate-in-posteio)

[jstedfast]

It doesn't say anything about TLS negotiation, it says after any security layer has been obtained. SASL stands for Simple Authentication and Security Layer.

[jstedfast]

That said, rfc4616 does state: The PLAIN SASL mechanism does not provide a security layer..

[analogic]

Thanks!

[SonicGD]

Thank you

[jstedfast]

FWIW, MailKit 1.14.1 fixes this.