Start Free Trial

asked on

Not recieving email from some domains

I have a client using SBS2003 with exchange 2003. They are not able to receive email from some domains. We are using Mcafee Groupshield 6.0 with the anti-spam add-on. I have recruited a user at one of the domains that we are having issue with to help me to troubleshoot this and send test messages to my client and copy me, I receive all of the messages they send.

I have turned ALL SMTP logging on that I know exists. NONE of the logs show an attempt to connect from any of the domains we are having issue with to my clients server, but my messages do appear in the SMTP logs. My client can send messages to them with no problems. I have checked the anti-spam logs and nothing is logged. My client, and the domains in question are not listed in any of the blacklists (147 of them) located in the blacklist search at MX Toolbox.

I am at a loss here. If it was one domain I would say it was on their end, but, it appears to be several domains that we are having the issue with. So, That leads me to believe it is on our end.

Any help is greatly appreciated.

My client and I are use the same ISP, and Our servers are setup nearly Identically.

Does your client have a reverse DNS entry for their domain/server?

Is the other party getting any NDRs?

One thought is using the address for the MXtoolbox for their server try and fake an email by telneting to their mail server on port 25 and use the helo commands to mimick an email providing when it asks with one of the problem domains.

you can find a list of commands how to do it quickly here. It will at least let you know if its being accepted by the mail server.

http://www.wikihow.com/Send-Email-Using-Telnet

-Cheers

ASKER

My client does have a reverse DNS/PTR record and it is correct (Checked it after I posted but before your comment)

I am not sure I understand the "using the address for the MXtoolbox for their server" . I understand the fake email I'm not sure about MXtoolbox, I've never had cause to use that before and I am not familiar with it

ASKER

I tried the telnet from my machine and it went as follows. Edited (of course) to maintain privacy. Myclient.com replaced my clients domain name, Domain.com replaces the external domain name

220 MyClient.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 ready at
Tue, 7 Apr 2009 10:36:00 -0400
helo Domain.com
250 MyClient.com Hello [xx.xx.xxx.xx]
mail from:(Person Helping)@domain.com
250 2.1.0 (Person Helping)@domain.com....Sender OK
rcpt to:client@myclient.com
250 2.1.5 client@myclient.com
data this is a test from paul
354 Start mail input; end with <CRLF>.<CRLF>
.
250 2.6.0 <SBS2003tIL1f3x7cOSH000000aa@MyClient.com> Queued mail for delivery
quit
221 2.0.0 MyClient.com Service closing transmission channel

I checked the loSMTP log, and it shows a connection with the domain name domain.com and my IP address

I know it sounds silly, but what happens if you add a trouble domain to your whitelist. or can you turn off the anti-spam feature temporarily to send another telnet email and see where it goes.

ASKER

Oops...Forgot to mention that I did both of those things as well during my troubleshooting. Whitelisted, No Joy. Disabled all AV and AS software (this was scary) for a test and no Joy. Thanks for the suggestion though.

pfleury1,

did the Telnetted email come through?

You say emails come through to you, can you see them logged in your SMTP filters?

Doesnt seem to be a rDNS / blacklist issue, though adding the domain to your McAffee whitelist may be worth a shot (as previously suggested)

ASKER

No, the telnetted emails do not get delivered. but I thought this might be for some other reason, like something related to relaying since I did not telnet from the actual IP of the domain name I used in the telnet session

Yes, I see them in my logs.

I have whitelisted them in McAfee.

Is there a whitelist in Exchange that I don't know about?

No there isnt.

Ok, enable message tracking (if not already enabled), re-send the email via Telnet (the commands you put here looked right) and then track the message.

ASKER

I had Message tracking turned on. I reviewed the log and my previous telnet session does NOT appear in the Message Tracking log (I did not create a new Telnet session). It does appear in the SMTP connector log though.

It's not considered relaying if you did it through telnet because you were the original starting point of the message. In relaying it will examine the headers of the message to see where it has bounced from. Each server relaying it will stamp its own name in the header of the email.

Because your acting as an original source it wouldnt be seen as a relay. Plus if it was a relay you would get an NDR saying Relaying not allowed.

Can you turn off the Anti-SPAM program temporarily to try again. I honestly think its with your SPAM filter. Even though you may have it whitelisted. If you can disable it temporarily...give it a shot.

ASKER

Thanks for the info NoodlesWIU. I have disabled the Anti-Spam, and the Anti-Virus as a test, and it had no effect. As soon as I can get a hold of my recruit at one of the domains that is not getting through, I will try it again.

But, If they are not in the Anti-Spam log, not in the Message Tracking log and not in the SMTP connector log, wouldn't that mean that it is something external to the server causing the problem? I dunno. It just seems like it's not making it to the server at all.

I am going to try to contact one of the domain's IT departments and ask them to telnet in and see if we get anywhere.

I'll post back with updates.

In the meantime, any and all suggestions are welcome.

You've proved it is not something external, as emailing via telnet (you did do this from an external source didn't you?) shows the exact same issue, no message and no tracking.

It's rather bizzare that you see the SMTP log, can you paste the SMTP log as <code> so we can take a look?

ASKER

Here is an update:
I got ahold of the Administrator at one of the domains. He and I went through a bunch of things and here are the results.

He could NOT Telnet to my clients server although I still can. He checked the Queues on his Exchange 2007 Server and there is nothing in the retry queues for my clients domain. He is getting no NDR's. As he repeatedly tried to telnet to the server on Port 25 I checked connection logs and saw nothing, but did see the connection from my network. I recreated the Firewall rule for port 25 forwarding to the server. I restarted the firewall. I restarted the SMTP service. I cleared the DNS Cache.

He is now in the same boat as us saying what the ?

It seems that the messages are getting out onto the internet and vaporizing. But He CANNOT telnet to the server.

The remote Admin not being able to telnet is key here.

Did you do your Telnet test externally?

If he is timing out, then it is either a fiewall policy (unlikely) or something third party on your Exchange server blocking it.

AFAIK there is no built-in tool to Exchange 2k7 to automatically blacklist IP's

Let me sleep on this (since my head is filed with XML IDM config right now), and I'll have another review in the AM

ASKER

Yes I did my telnet externally.
He is simply getting "connection failed". He can ping the server and get a reply (after I opened the port on the firewall). He can also do a tracert successfully.

Thats where I was going with it as well djxtreme. It sounds like your firewall then. What kind of firewall is being used? If its a ISA server or something like that do some monitoring when they send a test message and see what might be the hold up.

ASKER

Ithink we are all heading in the same direction. I just arrivedvonsite to switch them to a backup firewall (sonicwall). I'll post back with results.

ASKER

Replaced the firewall with an older model. Same results. Some mail gets through. Same domains cannot get mail through.

are you running any other borderware than your firewall?

ASKER

No we are not using any borderware.

ASKER

UPDATE- Nothing really to report. But wanted those helping with this issue that the issue still exists. We did find a secondary MX record that was not valid, but have corrected that with no change. Had an admin at one of the domains pitching in, but come to find out the emails were in fact being delivered, so he cannot really help.

If anyone has more suggestions, they are welcome to jump in.

Thanks for all of the help so far.

did the bogus MX record have a lower cost than the other? or the same cost?

now that it has been removed I think you will find that the problem will go away as that bogus entry decays out of the caches of the dns servers out there

ASKER

the correct MX had a cost of 10 and the bogus one had a cost of 50

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

I would agree with you on that. But I am continuing my search to try to get to the bottom of this.

I have spoken with a tech that administers one of the domains and found that they use Postini to scrub both incoming and outgoing mail. I have no experience with Postini. Does that jog anyone's thought process?

ASKER

Another update... I have found another network that cannot send emails to my client. Interestingly, I had the tech try to telnet to ports 25,110 and 23 which should be available and he could not connect. When I had him try to connect using OWA, he got to the same exact server with no problem at all using the domain name. Things in common, Postini and Symantec AV that is all I have found so far.

i'm have a similar issue now, did you ever find a solution?

ASKER

I did Solve it, but can't remember what the solution was. I'll thing on it and get back if I remember. Sorry