After calling two different hosting companies - they each host a domain that our client is trying to communicate with - located locally, we may have something. One of the hosting companies has not returned our call yet, but we got to work with the other for about half an hour testing things.
It turns out that they have their servers set to deny the first connection attempt with a 5.7.1 "Try Again" message. This is verbatim from the technician we were speaking with.
On our client's SBS Exchange server, the message tracking indicates that there was a successful SMTP connection, and that the email message was accepted by the hosting provider's email server successfully too!
We tried sending an email from our own SBS Exchange based domain to our client's intended recipient, and the email disappeared into the ether as well. The hosting email server accepted the SMTP connection and accepted the email with no Deny/Retry indicated. Our SBS Exchange queue indicated the email sent to the intended recipient successfully.
At that point the technician was a bit puzzled but still indicated that the problem was on our end and not theirs. I mentioned that it was strange that two different sending SMTP servers have done this, one while we watched, and he stood by our servers being the culprits.
Me thinks not. Their server received the email, put it in some sort of queue - he could look at the cue but couldn't find the message - and their email server would then wait for the sender's server to try to send the email again.
Well, Exchange is not going to try again, because the email was "accepted" by the hosting company's email server. Both of our SBS Exchange message tracking logs indicated thus.
He requested that I send a second email which I did, and it got through with no problems. Again, our SBS Exchange message tracker indicated a successful transfer of the email to the hosting company's email server.
It is strange that both our client's SBS Exchange and our own SBS Exchange servers indicated a successful transmission of the email but the hosting company's servers seemed to make them "disappear" on the first attempt by those SBS servers.
Anyone else experiencing this kind of issue?
It is looking like the hosting company has a configuration issue with their email servers.
For the email server experts out there ... is it proper to have an email server deny the first attempt to connect by a SMTP email server?
Somehow I find this to be a bit strange in my experiences working with Exchange all these years to do that as an anti-spam technique.
Hopefully we hear back from the second hosting company. It would be interesting to see if they are doing the same thing.
BTW: By default Exchange will retry to send a message after 10 minutes if it had received the Deny/Retry message.
UPDATE 2007-08-15: We have subsequently found out that the second hosting provider is only hosting the Web site. So, our next step is to look to the internal email setup for that one.
The hosting provider that we did speak with yesterday contacted us today as we sent in a message requesting further clarification.
They graciously forwarded the logs from yesterday.
This is a screen shot modified to pull relevant data:
So, as the fellow mentioned, there is a "4.7.1 Please try again later" message in the log. I do believe that these logs may not reflect the very first attempt to send the intended recipient an email as there was no retry. If there was as this log shot shows, then their email server vapourized our email as indicated by the second acceptance message in their log!
We ran through a series of tests again today, only this time Exchange did get the 4.7.1 message and retried 1 minute later.
Perhaps they made some changes? Not too sure about that. BTW, they are running the Merak Email Server by IceWarp.
It would be interesting to see if these issues are primarily with smaller outfits like this one.
UPDATE TO THE UPDATE - IMPORTANT:
This one deserves its own post...SBS - Exchange Email Spam Issue - Error Workaround - Exchange may not be retrying!
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.
2 comments:
According to the SMTP RFCs 5.0.0 errors are permanant errors, 4.0.0 errors are temporary. 5.7.1 specifically is "Unable to Relay". for Greylisting a 4.0.0 code is used, usually 4.3.2 He is either blowing smoke or doesnt really know whats going on.
BTW, Greylisting helps because most spam engines are written to completely ignore error codes from servers and just send the mail and move on to the next one. Along that same line, you can configure your SMTP (even exchange) to delay the response to EHLO by 20 seconds, and drop anything that starts sending data before it gets the response (Tarpitting). See http://support.microsoft.com/kb/842851 for how to configure tarpitting on exchange.
Josh,
Excellent information!
I did do a cursory search for the information the tech fellow indicated and didn't find anything. So, this is exactly what I was hoping to hear!
Tarpitting is definitely going on the ToDo list!
Thanks for that. :D
Philip
Post a Comment