Error: "421 Service Temporarily Unavailable"

[Andrew Hurcombe]

Hi,

One of my clients who's on premise exchange server is receiving Error: "421 Service Temporarily Unavailable" bounce backs when sending to multiple domain which have messagelabs.com filtering services.

I have emailed [e-mail] with example bounce and message and listed domains affected. This was on the 20th July and I have had no response....

Is the IP address 203.122.243.50 listed on any of your internal list's as I can't find it listed anywhere on any blacklists.

Thanks

 

 

[Migration User]

Hi Andrew,

 

Thank you for reaching out to our Support team, I have taken a look at your issue and am not seeing the following IP "203.122.243.50" being throttled or listed on any internal/public blacklists.

 

The error message you are receiving usually is due to the sending IP being throttled, to continue the investigation further can you please send me a test email from the sending domain that is having the issue relaying emails to Symantec customers. 

 

You can send the test email to the following address "[e-mail]", once it has been sent please respond to this post with the email details (sending address, subject and date). 

[Andrew Hurcombe]

 

Hi Akash,

I have sent an email message to the aforementioned email address.

The sending address is [e-mail]

Subject: Test 6th August

Date & Time : Monday 6 August 2018 9:54 AM (ACST)

Please advise if you require any further information.

Thanks

Andrew

 

[Andrew Hurcombe]

Hi Akask,

I still haven't heard from you.

There where a few messages that where delivered from ACST early Saturday morning through till Monday Morning.

But in the afternoon the 421 errors occurred again with some additonal errors that the message lab mail servers where deferring to other servers and then the Service Unavailable.

 

Domains include sales.canon.com.au, boileau.com.au, candogroup.com.au

Some messages are getting through early in the morning and then the others get stuck and are delayed for extended timeframes or aren't delivered.

This is becoming frustrating for the client can you please advise what issues you are having.

Thanks

 

[Migration User]

Hi Andrew,

Thanks for getting back to me I have taken a look at the test email you had sent to our "[e-mail]" mailbox. The reason I wanted to get this test completed was to verify the sending IP your emails are being sent from, from looking at this test you performed we are seeing different results.

According to this test, the sending IP you had sent from is as follows -> x-originating-ip: [10.0.20.3]

Is there any specific reason behind why you are routing emails via a Private IP? We believe there is something going on with the way you are sending the emails, or the sending IP you are using is being throttled. 

I have performed a throttling test for the following 2 IPs (203.122.243.50 and 10.0.20.3) and do not see any current issues.

[Andrew Hurcombe]

Hi Akash,

x-originating-ip: [10.0.20.3] 

This refers to the client based method that is used to send a message, since this message was sent via OWA this field is applied to the header when sending mail from a HTTP frontend.

If a client based send is used the sending server already knows the identity of the client and this is not amended to the header of the email.

I will send another email from a client based machine.

From the logs I am getting back to the server the message lab servers are just pushing the email delivery to other servers which are responding with the 421 errors.

Message Labs are the only provider that we are having issues with all other emails are being delivered correctly.

We believe there is something going on with your service.

Thanks

[Andrew Hurcombe]

Akash,

I have sent to you another email to the gmail account.

Here are the email details.

The sending address is agian: [e-mail]

Subject: 2nd Test 8th August

Date & Time : Wednesday 8 August 2018 18:01 (ACST)

The email has additional information in it regarding the logs from the sending server and there are some return errors from your message lab servers which aren't accepting the delivery of the message and then the connection is reset.

Please review and make changes necessary. 

Can this be escalated to higher level support if needed

Thanks
Andrew

[Andrew Hurcombe]

Hello,

Any reply to my query and email I sent with additonal information????

 

[Migration User]

Hello Andrew,

Thank you for the update, I have taken a look at the 2nd test you sent over and wanted to know if you had any way of providing us the verbose SMTP logs for the email(s) in question that issued the following error "4.2.1 4.4.2 Connection dropped due to connection reset." The verbose logs may indicate who dropped the connection along with if this email in particular was being routed via our primary cluster or honeypot.

By default all our customers are required to have 2 MX records for example ->

10    cluster6.us.messagelabs.com (Primary cluster that relay emails)
20    cluster6a.us.messagelabs.com (Simply just a spam trap/honeypot, this does not relay emails)

Usually our servers would wait ~4 minutes for data if no further data is provided by the sending server connection would time out, I don't see that specifically in the log you provided but can you see if you are able to get us some verbose SMTP logs that might give us a better picture.

[Andrew Hurcombe]

Hi Akash,

 

Hope you had a good weekend.

In the interim I have had to move over mail delivery via a smarthost and am not seeing any issues with mail delivery to domains hosted with  message labs.

I would still like to get this sorted as I would like to get messages flowing again normally.

Is there a test domain I can send mail to as I will set up a specific domain connector for it for testing purposes?

Logs are on and ready for testing and we can capture just the data for the test domain so clean session ID and sequencing in the logs will be shown.

 

Thanks

Andrew

 

[Migration User]

Hi Andrew,

 

Thank you for the update, so you have changed the outbound smarthost connector on your end and email flow is now restored when sending to Symantec customers ?

 

We can perform a test email to our "[e-mail]" address and once I receive it I will take a look at the header details to see if we are seeing these emails from from a different set of IPs hence why they might be getting delivered now.

 

Please reply back once the test has been sent, thank you.