Thursday, December 13, 2007

Email Woes

email-at1 Today was the day I set aside to study for the SCCM beta exam. Granted, I'd been reading off and on, playing in the lab. But today was the day to blow up the lab and rebuild everything with the RTM version and really dig and try different things.


One user can't send an email to a domain. The ticket gets escalated to me. I do the usual : MXToolbox, etc. We just came off of several blacklists due to some rocket scientist setting up a virus-infected client pc on our network that proceeded to send thousands of SPAM emails out. Yes, port 25 should have been blocked to not allow that traffic, but that was a decision by committee.

Further testing shows an email sent to any address on their domain bounces back almost immediately with that wonderfully useful 550 error.

So I start checking the blacklists again, and it appears that we're all in the clear.

I sent an email from an external account, and a reply came back about half an hour later. So their mail server is actually working.

I immediately decide to blame Postini, but the domain is not on any firmwide blacklists.

Finally I began to wonder if the email was ever even making it out of our environment. The bounceback usually arrived after less then 10 seconds, and that just seemed odd. So I collared out WAN guru and had him sniff the external interface for traffic on port 25 to Postini containing the offending domain... nothing. Specific strings in an email to the domain... nothing.

I set up a second SMTP connector to route email without going through Postini for email to that domain... still no dice. Messages just sit in the queue.

Now this is too weird.

I connect to their email server via good old telnet <> 25 and get a happy SMTP response. I figured I'd send an email manually to the administrator, who by this time I'd spoken with to confirm that we weren't blacklisted on their end. I'd just let him know that I got this far in testing.

So I type : "EHLO" and get an error response.

That can't be right. There must have been a control character in there. So I type it again. Same error. I check to make sure my syntax is correct, and it is.

Then I try "HELO" and it works. Like a champ. I send the email. A quick check of our Exchange server shows, sure enough, that it is configured to send "EHLO" and not "HELO". In all the years we've been on Exchange, this is the first time I've run into another server that refuses "EHLO".

I telnet back in and explain the issue in another 'manual' email session. I'm not sure what this admin will respond with, but I'm not inclined to change our config for one domain.

Yes, we could set up a second SMTP connector to route email to that domain that IS configured to send "HELO". But at this point it's the principal of the thing.

We'll see how they respond.

Post a Comment


It's suddenly February and I have a cast. All of them are people I know or have seen onstage, none of them are the people I thought wou...