Posts Tagged ‘Bug’

Office365: Temporary server error. Please try again later. PRX4

Thursday, January 28th, 2021

When using SMTP with Office365 and OAUTH 2.0 you may receive this error:

Temporary server error. Please try again later. PRX4

SMTP logs look 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 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:

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

livemail.co.uk SMTP bug

Monday, May 18th, 2015

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

Yahoo SMTP 8 BITMIME bug

Tuesday, February 17th, 2015

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

Mail2World IMAP search ALL bug

Monday, August 4th, 2014

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.

Gmail SMTP authentication and STARTTLS bug

Wednesday, July 23rd, 2014

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