Not Receiving Email From Certain Domains (Exchange 2003 on SBS 2003)
Hi, several users have been complaining that certain people cant email them. About 24 hours after they try to send an email to our domain, they get a bounceback. The timing seems to correlate to when we switched ISPs, but dealing with the ISP, Broadview, has been less then helpful, they deny its anything on their side. So thats been a dead end so far. Our DNS is GoDaddy, tried them too and they ran some tests and came up empty.
As far as I know Exchange 2003 is configured correctly, it'd been working without problem for over 2 years, up untill about a month ago when this all started.
So Im at a point where I dont know what to do next...
Our domain is thearborsliving.com.
Heres an example of the first part of the bounce back people get when they try to email us
As far as I know Exchange 2003 is configured correctly, it'd been working without problem for over 2 years, up untill about a month ago when this all started.
So Im at a point where I dont know what to do next...
Our domain is thearborsliving.com.
Heres an example of the first part of the bounce back people get when they try to email us
From: Mail Delivery System [mailto:mailer-daemon@electric.net]
Sent: Thursday, May 21, 2009 10:46 AM
To: Bruce******
Subject: Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
*******@thearborsliving.com
retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
Return-path: <******@onyxcap.com>
Received: from 1M6pge-0006NX-Vu by tazo.electric.net with emc1-ok (Exim
4.69)
(envelope-from <********@onyxcap.com>)
id 1M6pgf-0006OG-Tm
for ******@thearborsliving.com; Wed, 20 May 2009 10:34:41
-0700
Received: by emcmailer; Wed, 20 May 2009 10:34:41 -0700
Received: from [72.35.12.251] (helo=email.exchange.electric.net)
by tazo.electric.net with esmtp (Exim 4.69)
(envelope-from <*******@onyxcap.com>)
id 1M6pge-0006NX-Vu
for *********@thearborsliving.com; Wed, 20 May 2009 10:34:40
-0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C9D971.4090A8BA"
Subject: FW: Property tax reduction/refund analysis ?
Date: Wed, 20 May 2009 10:34:51 -0700
Message-ID:
<BAF64B1A53C8614398142457DADFE1EF02526BCA@EMAIL.exchange.electric.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Property tax reduction/refund analysis ?
Thread-Index: AcnUwh9kZMDA+DslTMmUhzbq+91utwEryE0g
From: "B" <*********@onyxcap.com>
To: "G" <*************@thearborsliving.com>
X-Outbound-IP: 72.35.12.251
X-Env-From: ************@onyxcap.com
X-Virus-Status: Scanned by VirusSMART (c)
This is a multi-part message in MIME format.
------_=_NextPart_001_01C9D971.4090A8BA
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
=20
=20
From: ***********=20
Sent: Thursday, May 14, 2009 11:31 AM
To: ***************
Subject: Property tax reduction/refund analysis ?
=20
=20
Are you receiving email from anyone? If so, it is possible that the people who cannot email you have a cached copy of your old DNS record. It is odd that they would have such an old record, but I am curious if you get email from anyone and only certain people cannot email you. The bounceback message shows that their message timed out before getting to you, so obviously somewhere along the line a server could not find your domain.
Is the sending server forwarding the domain to an outdated cached email IP? I see your IP is good, and you have a good SPF record too:
v=spf1 ip4:64.61.79.180 a mx ptr ?all
I would have them check if they have old cached (or static) IPs for you.
v=spf1 ip4:64.61.79.180 a mx ptr ?all
I would have them check if they have old cached (or static) IPs for you.
Hi
I have checked your MX record you are totally gooooooooood
I mean 100% good
i have had similar situations it was always the cached credentials on the server.
try contacting their IT and explaining them.
it is 100% their side.
if they do not agree with you tell me i will call them :))
Regards Art
I have checked your MX record you are totally gooooooooood
I mean 100% good
i have had similar situations it was always the cached credentials on the server.
try contacting their IT and explaining them.
it is 100% their side.
if they do not agree with you tell me i will call them :))
Regards Art
yes and one simple test
if they don't agree with you that they have a problem.
open a yahoo mail and send your self and others a test mail I am sure it will come.
Then tell them that with your MX records every thing is ok.
if they start bla blaing you
saying it is being blocked or what ever tell them to shut up :)
their email doesn't even reach your servers to get blocked so it is their server having a problem finding you.
if yahoo, hotmail and some other of your customers can find you then you know :) tell them to shut up:))
Art
if they don't agree with you that they have a problem.
open a yahoo mail and send your self and others a test mail I am sure it will come.
Then tell them that with your MX records every thing is ok.
if they start bla blaing you
saying it is being blocked or what ever tell them to shut up :)
their email doesn't even reach your servers to get blocked so it is their server having a problem finding you.
if yahoo, hotmail and some other of your customers can find you then you know :) tell them to shut up:))
Art
ASKER
@Netwoobie
Yea we receive alot of mail without a problem. It just certain accounts.
Atfirst it seemed like it was all west coast domains that had the problem (we're in NY), but this morning I heard someone else in NY couldnt email us either.
We had the tech at onyxcap.com do an nslookup this morning and it resolved to the correct IP. However, last week he said the nslookup couldnt resolve via the Cogent DNS his company uses, but did resolve on a Worldcom one.
Tomorrow morning I'll try to have the specific people who cant email us do a dnsflush on their pc's
Thanks guys
Yea we receive alot of mail without a problem. It just certain accounts.
Atfirst it seemed like it was all west coast domains that had the problem (we're in NY), but this morning I heard someone else in NY couldnt email us either.
We had the tech at onyxcap.com do an nslookup this morning and it resolved to the correct IP. However, last week he said the nslookup couldnt resolve via the Cogent DNS his company uses, but did resolve on a Worldcom one.
Tomorrow morning I'll try to have the specific people who cant email us do a dnsflush on their pc's
Thanks guys
ASKER
@artoaperjan
Haha Im less worried about their complaints and more about the management here chewing me out.
But I'll def tell them tomorrow to check their local DNS records and maybe I'll get lucky
Thanks, I'll let you know how it turns out tomorrow!
Haha Im less worried about their complaints and more about the management here chewing me out.
But I'll def tell them tomorrow to check their local DNS records and maybe I'll get lucky
Thanks, I'll let you know how it turns out tomorrow!
ASKER
Heres some triple post action for ya:
I dont think its related but my boss wont let me off the hook untill I fix it.
When you try to access the OWA external dns (https://mail.thearborsliving.com/exchange) INTERNALLY it doesnt resolve. From my home I can type it in and it works fine, but from on site it wont. You cant ping thearborsliving.com locally either.
This is all behavior I thought was normal, but my boss wont let me off the hook untill I investigate.
Obviously I can just add the host on the local DNS server and that would fix it, but Im not sure if tahts more of a work-around then a fix?
I dont think its related but my boss wont let me off the hook untill I fix it.
When you try to access the OWA external dns (https://mail.thearborsliving.com/exchange) INTERNALLY it doesnt resolve. From my home I can type it in and it works fine, but from on site it wont. You cant ping thearborsliving.com locally either.
This is all behavior I thought was normal, but my boss wont let me off the hook untill I investigate.
Obviously I can just add the host on the local DNS server and that would fix it, but Im not sure if tahts more of a work-around then a fix?
I agree that the mail issues does sound like dns caching to me. if you know what your new ip address will be in advance, you can setup a secondary mx record for it, wait for ttl to finish so all dns servers have both records and then you will have no issues. of course, you need to have the ip before the isp change.
ASKER
@shauncroucher
I suppose that woulda been the thing to do, a month or two ago.
I suppose that woulda been the thing to do, a month or two ago.
ASKER
This post https://www.experts-exchange.com/questions/23141193/Can't-Ping-Public-IP-Address-from-internal-network.html seems to answer my question about OWA, so disregard that.
Yes, just if you ever get this again, it's a handy way of dealing with IP change.
Shaun
Shaun
ASKER
Here's another bounc back, this one was from an optonline.net account
This report relates to a message you sent with the following header fields:
Message-id: <e4118a9d35238.4a369d35@optonline.net>
Date: Mon, 15 Jun 2009 19:12:53 +0000 (GMT)
From: *******@optonline.net
To: *********@thearborsliving.com
Subject: Fwd: Recreation Director (Westbury, NY)
Your message is being returned; it has been enqueued and undeliverable for
57 hours to the following recipients:
Recipient address: ********@thearborsliving.com
Reason: unable to deliver this message after 57 hours
Delivery attempt history for your mail:
Wed, 17 Jun 2009 22:53:53 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Tue, 16 Jun 2009 22:52:42 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Tue, 16 Jun 2009 06:51:32 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Mon, 15 Jun 2009 22:50:21 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Mon, 15 Jun 2009 18:49:11 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Mon, 15 Jun 2009 16:48:01 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Mon, 15 Jun 2009 15:46:50 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
Mon, 15 Jun 2009 15:15:31 -0400 (EDT)
Error reading SMTP packet; response to dot-stuffed message expected; likely problem with network or remote SMTP server
I've just run a telnet test to your server.
A couple of things.
1) Your banner does not display any info? Just 220 **************************
2) Your server does not respond to EHLO, only HELO handshake. Again, SMTP servers SHOULD be able to handle sending HELO, so shouldn't cause a problem
3) Then I try to send an email and when I get to RCPT TO: section of telnet test I get a connection timeout. No permanent failure message, no transient failure message and no 250 successful response. This is unusual. Your server should really be responding with FAILURE or SUCCESSFUL code, not just time out.
4) I have a dynamic IP without PTR at home where I ran these tests. I tried this from a location where they have a valid PTR and I managed to get to the DATA stage when I get a 5.7.1 message refused message.
So a couple of things to consider there. It all appear pretty non standard for Exchange 2003? I would be looking at what Anti-Spam facilities you have / what checks do you run against sending SMTP servers when they connect?
I'm wondering if this may be more than just DNS caching issue.
Shaun
A couple of things.
1) Your banner does not display any info? Just 220 **************************
2) Your server does not respond to EHLO, only HELO handshake. Again, SMTP servers SHOULD be able to handle sending HELO, so shouldn't cause a problem
3) Then I try to send an email and when I get to RCPT TO: section of telnet test I get a connection timeout. No permanent failure message, no transient failure message and no 250 successful response. This is unusual. Your server should really be responding with FAILURE or SUCCESSFUL code, not just time out.
4) I have a dynamic IP without PTR at home where I ran these tests. I tried this from a location where they have a valid PTR and I managed to get to the DATA stage when I get a 5.7.1 message refused message.
So a couple of things to consider there. It all appear pretty non standard for Exchange 2003? I would be looking at what Anti-Spam facilities you have / what checks do you run against sending SMTP servers when they connect?
I'm wondering if this may be more than just DNS caching issue.
Shaun
For reference I would expect a Microsoft 2003 server to respond as follows when a telnet session is opened (unless it has been customised).
220 DOMAIN.COM Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready
at Fri, 19 Jun 2009 18:27:54 +0100
I believe you may have a third party SPAM product (or hardware device) that runs the SMTP server, does SPAM protection and sends accepted mail to your Exchange server. This may be the one causing the issues. Is this possible?
Shaun
Shaun
220 DOMAIN.COM Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready
at Fri, 19 Jun 2009 18:27:54 +0100
I believe you may have a third party SPAM product (or hardware device) that runs the SMTP server, does SPAM protection and sends accepted mail to your Exchange server. This may be the one causing the issues. Is this possible?
Shaun
Shaun
ASKER
@ shauncroucher
Wow you seem pretty money, we have Trend Micro Messaging Security. Typically when it detects a spam message it still accepts it though, it just gets sent to the users spam folder.
I just got a log from one of the troubles email hosts that agrees with your theory too. It seems like the connections are being canceled before completion.
Wow you seem pretty money, we have Trend Micro Messaging Security. Typically when it detects a spam message it still accepts it though, it just gets sent to the users spam folder.
I just got a log from one of the troubles email hosts that agrees with your theory too. It seems like the connections are being canceled before completion.
2009-06-08 09:57:19 1MDi0F-0004PT-Tp == tcappellino@thearborsliving.com R=dnslookup T=remote_smtp defer (110): Connection timed out: SMTP timeout while connected to mail.thearborsliving.com [64.61.79.180] after end of data (10026 bytes written)
ASKER
After an hour and a half with Trend they couldn't find any problems, we ended up uninstalling it just in case, for the mean time.
Shaun, Id be interested to know how your telnet test goes now.
Shaun, Id be interested to know how your telnet test goes now.
Hi TritechSolutions,
Still the same problem I'm afraid. Also, it still appears to be Trend that is dealing with the SMTP communications (are you sure it is fully uninstalled?).
The other possibility is telecommunication glitches that are causing the time out, but I would think this is unlikely because the connection lost message is pretty consistently after the RCPT TO command.
If you can run the test from inside does it go through ok? Run from the localhost the following:
telnet localhost 25
HELO domain.com
MAIL FROM:<someone@hotmail.com>
[wait for 250 response]
RCPT TO:<avalidemailaddress@the
[wait for 250 response]
DATA
[wait for 354 message]
Test message.
.
The dot on it's own should then give you a message queued for delivery or ID [number] message.
If you can repeat this remotely replacing the telnet localhost 25 with telnet mail.thearborsliving.com 25 you may get the same as me on the telnet test with Connection timed out.
Definitely something fishy with the SMTP client being used (or possibly but unlikely a connectivity issue)
Shaun
Still the same problem I'm afraid. Also, it still appears to be Trend that is dealing with the SMTP communications (are you sure it is fully uninstalled?).
The other possibility is telecommunication glitches that are causing the time out, but I would think this is unlikely because the connection lost message is pretty consistently after the RCPT TO command.
If you can run the test from inside does it go through ok? Run from the localhost the following:
telnet localhost 25
HELO domain.com
MAIL FROM:<someone@hotmail.com>
[wait for 250 response]
RCPT TO:<avalidemailaddress@the
[wait for 250 response]
DATA
[wait for 354 message]
Test message.
.
The dot on it's own should then give you a message queued for delivery or ID [number] message.
If you can repeat this remotely replacing the telnet localhost 25 with telnet mail.thearborsliving.com 25 you may get the same as me on the telnet test with Connection timed out.
Definitely something fishy with the SMTP client being used (or possibly but unlikely a connectivity issue)
Shaun
ASKER
Its definitely fully uninstalled.
What I did discover is that internally when you telnet you get the normal :
220 DOMAIN.COM Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready
at Fri, 19 Jun 2009 18:27:54 +0100
but when I did my external telnet test it produced your 220 **************************
Very odd.
What I did discover is that internally when you telnet you get the normal :
220 DOMAIN.COM Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready
at Fri, 19 Jun 2009 18:27:54 +0100
but when I did my external telnet test it produced your 220 **************************
Very odd.
ASKER
So I recreated the SMTP virtual server and re-ran the wizard, and its still no change. Looks like Im calling Microsoft.
It must be that somewhere (possibly on a router providing NAT) that SMTP traffic from outside your organisation is being port forwarded to a Non-Microsoft (or heavily customised) SMTP server.
The fact that you get a different banner when you telnet locally on the Microsoft server is almost 100% proof that there is a second SMTP server that accepts mail, I believe this is the issue. Microsoft may not be able to help here.
I'm not sure what else to suggest. Check your port forwarding rules if you use NAT.
Shaun
The fact that you get a different banner when you telnet locally on the Microsoft server is almost 100% proof that there is a second SMTP server that accepts mail, I believe this is the issue. Microsoft may not be able to help here.
I'm not sure what else to suggest. Check your port forwarding rules if you use NAT.
Shaun
ASKER
@shauncroucher:
I thought the same thing, so I called the router company, everything is forwarded correctly.
Phone with M$ now.
I thought the same thing, so I called the router company, everything is forwarded correctly.
Phone with M$ now.
OK, I will be very interested to see what they say about this.
My money is on either SMTP engine on the server has been damaged by the third party application (Trend micro) OR somehow SMTP requess from outbound are being forwarded to another SMTP service somewhere.
Good luck
Shaun
My money is on either SMTP engine on the server has been damaged by the third party application (Trend micro) OR somehow SMTP requess from outbound are being forwarded to another SMTP service somewhere.
Good luck
Shaun
ASKER
Well im back on the phone with the ISP, Broadview. Microsoft confirmed the firewall Broadview has in place uses an SMTP proxy, and it seems like thats the issue. Ofcourse, Ive called Braodview 5 times already and asked if they had anything filtering or blocking SMTP and they denied it.
My guess is Broadview doesnt even know what they're supporting.
My guess is Broadview doesnt even know what they're supporting.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@shauncroucher:
Well they finally found and disabled the SMTP Proxie, or so they say. The banner appears normal now. Id love to know if you could actually make a connection now.
Its hard for me to test because my computer never experienced the problem in the first place.
Well they finally found and disabled the SMTP Proxie, or so they say. The banner appears normal now. Id love to know if you could actually make a connection now.
Its hard for me to test because my computer never experienced the problem in the first place.
Hey! Looking good.
Just managed to send a test message to your postmaster account successful without a timeout.
(If you check your postmaster you should see it there. I don't have an email address shauncroucher@shauncrouche
I reckon all will be good now.
Shaun
Just managed to send a test message to your postmaster account successful without a timeout.
(If you check your postmaster you should see it there. I don't have an email address shauncroucher@shauncrouche
I reckon all will be good now.
Shaun
ASKER
@shauncroucher
Hrmm thats interesting, Im still having the problem from several domains though! MS is still working on it...
Optonline.net email started working when Broadview made the change too, but gmail and certain others still dont.
Hrmm thats interesting, Im still having the problem from several domains though! MS is still working on it...
Optonline.net email started working when Broadview made the change too, but gmail and certain others still dont.
do they get bounce backs more quickly now? I know at one stage it was delays for 24 hours before a failure. are the senders getting a message delayed or a full 5xx failure ndr?
are you able to replace the router temporarily to test if this is the cause?
ASKER
Well after about 3 weeks of fighting with the ISP, they finally brought in a higher level router tech. It ended up being a fragmentation issue, packets were being disregarded by the router when they were fragmented. It took the tech 2 seconds to fix, once he actually tried. Im giving you points Shaun, because you helped me discover that it was definitely the ISP and not my server. Thanks!
ASKER
We actually brought the server to our other office, which uses Optonline. As soon as we switched over the MX record all the emails started coming in. We used that as leverage against Broadview, the problem ISP.
That's great. glad I could help.