• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 771
  • Last Modified:

Email not being delivered through certain providers.

When I try to send to my client at sales@prospot.co.uk I run into problems. Sending to their Exchange 2003 server from my domain, it works fine, from my Mac account, again fine but use GMail then I get an error
***************************
Delivery to the following recipient failed permanently:

    sales@prospot.co.uk

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Requested action not taken: message refused (state 18).

****************************
Prospot.co.uk had changed broadband provider and following other posts I had a PTR record setup for mail.prospot.co.uk to match the IP address of the server to satisfy the Reverse DNS lookup.

I then had to switch web host so I could use an SPF which is now set up as other articles suggested this might be the issue but still I get the above error as do some of Prospot's customers when trying to sent mail to them.

The domain is not on any blacklists and had a neutral IP reputation according to  http://www.senderbase.org/senderbase_queries/rep_lookup¿

If you have any idea to remedy this situation I would appreciate your help.
0
richard1966
Asked:
richard1966
  • 7
  • 5
1 Solution
 
RackballCommented:
Have you tried using SMTPDiag from one of your outward-facing Exchange servers?  That's a wonderful troubleshooting tool for outbound mail.  It gives far more insight than a telnet.

By the way, have you tried telnetting to the outside server you're trying to talk to?  I was able to verify that sales@prospot.co.uk is good, so there's definitely some kind of issue on your end as opposed to the other end.
0
 
RackballCommented:
I would also check IMF (Intellegent Message Filtering) settings, and your SMTP virtual server config/certs.
0
 
richard1966Author Commented:
I should point out that this problem has only manifested in the last few weeks and the server has had no changes to it since then and there were no other problems.

The outbound mail is working fine.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
RackballCommented:
You don't know how many times I've heard that from clients.  And my answer has always been the same:  If nothing has changed, then there wouldn't be a problem.  Something, somewhere, somehow, has changed.  
It may not even be on your end, but the most efficient way to solve your problem is to at least rule out the possibilities on your side before blaming the other end.  Funny thing is that it could be a change on their end that is requiring a change on your end.  It could just be them requiring HELO and you're sending EHLO.
0
 
richard1966Author Commented:
I was pointing out that no changes have been made in the configuration to the server in order to provide a fuller picture and, indeed something somewhere etc must have otherwise there wouldn't be an issue for which I'm seeking considered opinion.

All was OK for the last couple of years. Then...

In summary Prospot changed broadband providers. Email failed when sent through GMail and some other providers.

The PTR record was amended to reflect the change in IP - this seemed to resolve the issue.

The issue with Gmail happened again as with some other clients trying to contact Prospot getting an error.

SPF record was created as per a post on Expert Exchange - the issue persists.

Any help most gratefully received.
0
 
RackballCommented:
Have you tried contacting the other end to see what changes were made?  I was able to connect to them fine, and a test via https://www.testexchangeconnectivity.com/ came through clean as well.

Do you have an SMTPDiag results that I could look at?
0
 
richard1966Author Commented:
I'm a little confused when you say 'tried contacting the other end'.

While a number of clients can't send to Prospot when I test sending in to them it seems the problem is confined to messages sent in from GMail into Prospot. Is there a way of figuring who the other end is, forgive my lack of knowledge. There are no issues with Prospot's mail being sent, everything sent by them is recieved by those it is addressed to.

The change I suspect is something to do with Google and narrowing down some there to talk to about potential changes is proving difficult.

Wont SMTPDiag only show if the server is working as it should?
0
 
RackballCommented:
Sorry, I misread your original post.  I think I need to take a nap or something; I'm posting all sorts of nonsense today.  I didn't realize this was all a GMail issue...I thought you were having internal domain mail issues.
0
 
richard1966Author Commented:
FYI

C:\>SmtpDiag.exe "sales@prospot.co.uk" "UserName@gmail.com"

Searching for Exchange external DNS settings.
Computer name is SERVER_1.
VSI 1 has the following external DNS servers:
There are no external DNS servers configured.

Checking SOA for gmail.com.
Checking external DNS servers.
Checking internal DNS servers.
SOA serial number match: Passed.

Checking local domain records.
Checking MX records using TCP: prospot.co.uk.
Checking MX records using UDP: prospot.co.uk.
Both TCP and UDP queries succeeded. Local DNS test passed.

Checking remote domain records.
Checking MX records using TCP: gmail.com.
Checking MX records using UDP: gmail.com.
Both TCP and UDP queries succeeded. Remote DNS test passed.

Checking MX servers listed for aUserName@gmail.com.
Connecting to gmail-smtp-in.l.google.com [209.85.143.27] on port 25.
Successfully connected to gmail-smtp-in.l.google.com.
Connecting to alt1.gmail-smtp-in.l.google.com [74.125.79.27] on port 25.
Successfully connected to alt1.gmail-smtp-in.l.google.com.
Connecting to alt2.gmail-smtp-in.l.google.com [74.125.53.27] on port 25.
Successfully connected to alt2.gmail-smtp-in.l.google.com.
Connecting to alt3.gmail-smtp-in.l.google.com [209.85.225.27] on port 25.
Successfully connected to alt3.gmail-smtp-in.l.google.com.
Connecting to alt4.gmail-smtp-in.l.google.com [74.125.159.27] on port 25.
Successfully connected to alt4.gmail-smtp-in.l.google.com.

0
 
richard1966Author Commented:
I wasn't sure whether this is being caused by an internal issue or something to to do with how the mail is routed.

Very confusing.
0
 
richard1966Author Commented:
It appears I have a solution. Gmail was reporting the "The error that the other server returned was: 550 550 5.7.1 Requested action not taken: message refused (state 18)."

What this turned out to be was the Intelligent Message Filter stopping email come in from GMail and others.

I'm not sure what has changed to effect the filter to do this, I can only conclude an update etc but having changed its setting all email seems to get through. Fingers crossed.
0
 
richard1966Author Commented:
The intelligent message filter in Exchange 2003 was the culprit.
0

Featured Post

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now