Exchange SMTP Authentication Issue

SlimShady

[H]ard|Gawd
Joined
Aug 2, 2000
Messages
1,143
We have a client that is running SBS2003 that is using the smtp.comcast.net SmartHost to send outgoing mail. Now, the SmallBusiness SMTP connector is not staying active and is reporting an error of 'The remote SMTP service rejected AUTH negotiation.' We noticed this when the client said he was unable to send mail. There was a total of about 20 messages sitting in the outgoing queue.

We are currently using port 25 with anonymous access using the smtp.comcast.net smarthost.

My initial thought was that port 25 was being blocked, but I was able to telnet from the server to the smtp server without an issue, meaning its not being blocked.

As a stopgap measure, I tried using port 587 with credentials from a spare comcast account that I have, but that did not allow the connection either.

I have also tried additional SMTP servers (such as AOLs) to test and the same error is reported back.

I realize this could be a bunch of things, but does anyone have any thoughts about this?
 
Have you tried recreating your smtp connectors, trying one that is specifically for 76.96.62.117 (smtp.comcast.net) using the ip address but not the DNS name? with anonymous still off.
 
Although I love Comcast as an ISP.......one thing I don't like about them is they really won't support an Exchange server sending out to them. I've talked to their support several times...no straight answer, seems they prefer you send directly out from your Exchange server instead of forwarding to their outbound. Which stinks! However, we usually do our own "washing" of e-mail for our clients with Exchange servers (spam/virus filtering)...and we have so many that we setup our own redundant outbound SMTP service that we set our clients Exchange to spit out to.
 
I fixed it. There was a set of credentials in there that I hadn't found. I deleted those and set everything back to anonymous and it clicked on.

They will say they don't allow port 25 for SMTP, but it seems to be OK... this particular client has been doing it for 4 years. They recommend using 587 instead.
 
Back
Top