Recently one of our clients reported an issue with the SMTP server they use. The problem occurred only in Mail.dll. Outlook was working correctly.

The exception we are getting is:

Limilabs.Client.ServerException: 5.5.1 Invalid command
at Limilabs.Client.SMTP.Smtp.[1](String [1], Boolean
)
at Limilabs.Client.SMTP.Smtp.LoginDIGEST(String user, String password)
at Limilabs.Client.SMTP.Smtp.UseBestLogin(String user, String password)
at ..Forms.ComposeEmailForm.SendEmail()

The SMPT settings are as follows:

Outgoing mail server: smtp.livemail.co.uk
Port: 587
Use SSL: false

After some investigation it turned out that livemail.co.uk incorrectly advertises CRAM-MD5 login method:

The server EHLO response is misleading:


S: 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-DSN
S: 250 AUTH PLAIN LOGIN CRAM-MD5

Notice that it sends DIGEST-MD5 in first AUTH response and it doesn’t send it in the second one. Unfortunately Mail.dll uses the first response and it causes it to use CRAM:

C: AUTH DIGEST-MD5

the command fails, because it’s most likely not implemented by the server or not turned on:

S: 500 5.5.1 Invalid command

AUTH PLAIN and AUTH LOGIN methods do work without any problems

using (Smtp client = new Smtp())
{
    client.Connect("smtp.livemail.co.uk");
    client.Login("user", "pass");
    //...
    client.Close();
}

using (Smtp client = new Smtp())
{
    client.Connect("smtp.livemail.co.uk");
    client.LoginPLAIN("user", "pass");
    //...
    client.Close();
}

It’s sometimes hard to believe, that even the biggest make such mistakes.

Here’s the capability (EHLO) response from Yahoo’s SMTP server:

S: 220 smtp.mail.yahoo.com ESMTP ready
C: EHLO [192.168.0.11]
S: 250-smtp.mail.yahoo.com
S: 250-PIPELINING
S: 250-SIZE 41697280
S: 250-8 BITMIME
S: 250 STARTTLS

Can you spot the problem? It’s not that easy, and it has been brought to my attention by one of our customers:

S: 220 smtp.mail.yahoo.com ESMTP ready
C: EHLO [192.168.0.11]
S: 250-smtp.mail.yahoo.com
S: 250-PIPELINING
S: 250-SIZE 41697280
S: 250-8 BITMIME
S: 250 STARTTLS

It supposed to be: 8BITMIME, at least according to RFC6152

the EHLO keyword value associated with the extension is 8BITMIME;

Most annoying part is that in many cases, space is used to split extensions keyword and its parameters e.g. SIZE 41697280. We want Mail.dll to be robust enough to accept custom extensions or extensions unknown yet, that follow this standard.

Shame on you Yahoo!.

Another broken IMAP server.


S: * OK Mail2World IMAP4 Server 2.6 64bit ready
S: 76abb5398bc44413 OK CAPABILITY completed
C: 1d5827aea22047ea LOGIN X Y
S: 1d5827aea22047ea OK LOGIN completed
C: b094a8b36bce4d26 EXAMINE "INBOX"
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Recent)
S: * 1 EXISTS
S: * 0 RECENT
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: * OK [UNSEEN 0] first unseen
S: * OK [UIDVALIDITY 42389] UIDs are valid
S: b094a8b36bce4d26 OK [READ-ONLY] opened INBOX
C: 95d4bf743ec949dd UID SEARCH ALL
S: 95d4bf743ec949dd BAD UID SEARCH wrong arguments passed.

“UID SEARCH ALL” is a valid IMAP search query, all servers I know (e.g. Gmail, Exchange) support it without any problems. I can’t imagine a simpler search query, than “UID SEARCH ALL”.

I doubt any email program can download anything from this server.

Funny enough such broken commands as: “UID SEARCH 1:* UID” or “UID SEARCH ALL UID” work on this server.

Nevertheless latest version of Mail.dll is smart enough to access this server.

Most SMTP servers don’t accept not encrypted connections, or require to secure such connection using explicit SSL.
Usually in such case LOGINDISABLED and STARTTLS are send in response to EHLO command. Some servers send STARTTLS and simply don’t send any AUTH responses.

Recently Gmail started to act differently (and incorrect):

S: 220 mx.google.com ESMTP hc4sm6305585wjc.9 - gsmtp
C: EHLO [192.168.0.11]
S: 250-mx.google.com at your service, [89.67.21.113]
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN XOAUTH XOAUTH2 PLAIN-CLIENTTOKEN
S: 250-ENHANCEDSTATUSCODES
S: 250 CHUNKING
C: AUTH LOGIN
S: 530 5.7.0 Must issue a STARTTLS command first. hc4sm6305585wjc.9 - gsmtp

Server claims that it accepts LOGIN command:
S: 250-AUTH LOGIN
but when it is send, it claims that you must issue STARTTLS first:
S: 530 5.7.0 Must issue a STARTTLS command first. hc4sm6305585wjc.9 - gsmtp

This doesn’t make much sense and Gmail should not send “250-AUTH LOGIN PLAIN”.

Yandex does not recognize UTF-8 charset correctly. For a message with text part using utf-8 charset:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit


Yandex returns “X-UNKNOWN” as CHARSET instead of correct utf-8 in BODYSTRUCTURE response:

C: 11b7e19c9cd84f0f UID FETCH 1 (UID BODYSTRUCTURE)
S: * 1 FETCH (UID 1 BODYSTRUCTURE (“TEXT” “PLAIN” (CHARSET “X-UNKNOWN”) NIL NIL NIL 11894 0 NIL NIL NIL NIL))