It is a bug when setting up an office365 business account with Microsoft.
After creating the e-mail account, you have to edit the account (go to https://admin.microsoft.com/)
Then go to “Mail” tab then click “Manage email apps”
There is an option called “Authenticated SMTP”. It is ticked by default, however to actually make it work you have to uncheck it and save the changes, then go back in and re-check it and save the changes.
You may need to leave it unchecked for some time and wait for some time when it is rechecked before it starts working:
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 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.
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):
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”.
