Temporary server error. Please try again later. PRX4

SMTP log looks more or less like this:

Connecting to ‘outlook.office365.com:587’, SSL/TLS: False.

S: 220 AS8PR04CA0136.outlook.office365.com Microsoft ESMTP MAIL Service ready at Thu, 28 Jan 2021 15:43:35 + 0000
C: EHLO[IPv6:2a02:]
S: 250-AS8PR04CA0136.outlook.office365.com Hello[2a02:]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-CHUNKING
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 SMTP server ready
C: EHLO[IPv6:2a02:]
S: 250-AS8PR04CA0136.outlook.office365.com Hello [2a02:]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-AUTH LOGIN XOAUTH2
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-CHUNKING
S: 250 SMTPUTF8
C: AUTH XOAUTH2 dXNlcj1B...EEBAQ==
S: 451 4.7.0 Temporary server error. Please try again later. PRX4[AS8PR04CA0136.eurprd04.prod.outlook.com]

It is a bug on the Office365 side when new business account is created with Microsoft. 

Although SMTP is enabled by default, it is not working. The workaround for this issue is to turn Authenticated SMTP off and turn it on again.

After creating the e-mail account, you have to edit the account.

Go to https://admin.microsoft.com/ and click Setup.

On the “Active users” list find the account you are using:

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 check it again 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.

After this change Mail.dll client can authenticate successfully using OAuth 2.0:

C: AUTH XOAUTH2 dXNlcj1B...BAQ==
S: 235 2.7.0 Authentication successful
C: QUIT

The post Office365: Temporary server error. Please try again later. PRX4 first appeared on Blog | Limilabs.

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();
}

The post livemail.co.uk SMTP bug first appeared on Blog | Limilabs.

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!.

The post Yahoo SMTP 8 BITMIME bug first appeared on Blog | Limilabs.


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.

The post Mail2World IMAP search ALL bug first appeared on Blog | Limilabs.

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”.

The post Gmail SMTP authentication and STARTTLS bug first appeared on Blog | Limilabs.

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))

The post Yandex BODYSTRUCTURE CHARSET “X-UNKNOWN” first appeared on Blog | Limilabs.

IMAP protocol equivalent of this expression is SENTBEFORE. It examines email’s Date: header.

It appears that although SENTSINCE doesn’t work, SENTSINCE (Expression.SentSince), BEFORE (Expression.Before) and SINCE (Expression.Since) do work correctly. BEFORE and SINCE use email’s INTERNALDATE recorded by the IMAP server instead of Date: header.

C: 0895789b79c64868 UID FETCH 14622 (UID RFC822.SIZE INTERNALDATE ENVELOPE)
S: * 1 FETCH (UID 14622
INTERNALDATE "10-Jun-2014 13:02:08 +0000"
ENVELOPE ("Wed, 10 Jun 2014 15:02:08 +0000" "test2" NIL NIL NIL NIL NIL NIL NIL NIL))
S: 0895789b79c64868 OK UID FETCH completed
C: 2b535791f07e4515 UID SEARCH BEFORE 12-Jun-2014
S: * SEARCH 14622
S: 2b535791f07e4515 OK UID SEARCH completed
C: b726a850e61c4082 UID SEARCH SENTBEFORE 12-Jun-2014
S: * SEARCH
S: b726a850e61c4082 OK UID SEARCH completed
C: 3e479e518dc04915 UID SEARCH BEFORE 13-Jun-2014
S: * SEARCH 14622
S: 3e479e518dc04915 OK UID SEARCH completed
C: 31b7f9ffbe4f4934 UID SEARCH SENTBEFORE 13-Jun-2014
S: * SEARCH
S: 31b7f9ffbe4f4934 OK UID SEARCH completed
C: 2fd2d29b90a24f16 LOGOUT
S: * BYE IMAP4rev1 Server logging out
S: 2fd2d29b90a24f16 OK LOGOUT completed

The fact is that Yahoo IMAP implantation is buggy. Once, the server assigned “17-Jan-1970 05:37:46 +0000” as an INTERNALDATE to one of my emails, just to change that on the next login.

The post SENTBEFORE doesn’t work correctly on Yahoo IMAP server first appeared on Blog | Limilabs.

RFC 3501 is clear:

A search key can also be a parenthesized list of one or more search keys (e.g., for use with the OR and NOT keys).

Please note that RFC document is not talking, if a server SHOULD or MUST support parentheses. It tells that any search key can always be a parenthesized list.

What is worth mentioning, although IMAP search uses polish notation (which doesn’t need parenthesis by itself) IMAP search command syntax actually requires parentheses.

UID SEARCH (OR SUBJECT subject BODY body) – fails, while:
UID SEARCH OR SUBJECT subject BODY body – succeeds.

This is the log from the server minus the authentication (note that 2nd search returns one email):


S: * OK serwer1476502.home.pl IdeaImapServer v0.80 ready
C: 21a04 CAPABILITY
S: * CAPABILITY IMAP4rev1 LITERAL+ CHILDREN I18NLEVEL=1 IDLE SORT UIDPLUS UNSELECT XLIST AUTH=PLAIN AUTH=LOGIN
C: 98104 UID SEARCH (OR SUBJECT subject BODY body)
S: 98104 BAD Unknown argument: (OR SUBJECT subject BODY body
C: 16e37 UID SEARCH OR SUBJECT subject BODY body
S: * SEARCH 1
S: 16e37 OK Completed

The post IdeaImapServer IMAP search parentheses bug first appeared on Blog | Limilabs.

Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY, UNSEEN (if any unseen exist)

and later:

If there are any unseen messages in the mailbox, an UNSEEN response MUST be sent, if not it MUST be omitted.

However Gmail IMAP server doesn’t send the OK [UNSEEN <n>] response, even when there are unseen emails in the mailbox. The following listing shows that (note the subsequent SEARCH command that returns a single email):

C: c7a56 SELECT "INBOX"
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Phishing $MDNSent NonJunk $NotPhishing Junk)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $Phishing $MDNSent NonJunk $NotPhishing Junk \*)] Flags permitted.
S: * OK [UIDVALIDITY 3] UIDs valid.
S: * 7619 EXISTS
S: * 0 RECENT
S: * OK [UIDNEXT 30566] Predicted next UID.
S: * OK [HIGHESTMODSEQ 2384884]
S: c7a56 OK [READ-WRITE] INBOX selected. (Success)
C: a7c39 UID SEARCH UNSEEN
S: * SEARCH 30565
S: a7c39 OK SEARCH completed (Success)


The post Gmail doesn’t send “OK [UNSEEN n]” when required first appeared on Blog | Limilabs.

Coping an email with an attachment on Outlook.com using IMAP works correct for small attachments:

C: 7554e85569d0465d UID COPY 100828 "Destination"
S: 7554e85569d0465d OK [COPYUID 43582022 100828 100003] COPY completed

With large attachments (~3MB), although COPY command succeeds:

C: 7734b17263a84259 UID COPY 100823 "Destination"
S: 7734b17263a84259 OK [COPYUID 43582022 100823 100001] COPY completed

All contents of the attachments are removed by the server:

------_=_NextPart_001_01CF7412.6651E594
Content-Type: image/jpeg; name="100557_1_DSC_0041 (2).jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="100557_1_DSC_0041 (2).jpg"
MS-Blob-Excluded: messageId=7C7BA5A2-E006-11E3-94A8-2C59E5464128; blobId=0; encodedLength=2925184; resolveError=true; blobHash=F206EC6BB4B95BF30B1382C38A33C9BEC3DBFB4A

------_=_NextPart_001_01CF7412.6651E594--


After COPY operation email message is modified by the server:
– attachment contents are removed (attachment must be large enough ~3MB)
– new MIME header: MS-Blob-Excluded is added to the MIME entity representing the attachment.

All IMAP clients are affected.

It seems that this behavior is coded-in on purpose, however it’s a bug and violation of the IMAP protocol.

It would be much wiser to fail on COPY command with appropriate error message, if for some reason (performance?) the operation would result in loosing data.

The post Outlook.com IMAP looses attachment contents on COPY first appeared on Blog | Limilabs.