I'm retiring our 10 year old web server (no more Pentium III – yay!). A few of the pages on the web site it hosted have forms that cause e-mails to be sent to certain people. These e-mails are sent via the smtp server in IIS. We also use this smtp server for a few other things, including messages from our help desk software and e-mail alerts from some of our network devices. This is the only remaining smtp server on campus. The rest of our e-mail is hosted by Google Apps for Education. The server is set up with a smart host pointed at smtp.gmail.com and has a good username/password (with tls) to talk to Google's server. In other words, all it does is forward messages from software on campus to our mail system off campus.
Unfortunately, messages sent through this server are getting stuck in the mailroot/Queue folder. If I wait too much longer I expect they'll finally move to BadMail. As far as I can tell, this new server's config exactly manages the old config. My own investigations show that dns is working just fine (the most common suggestion for similar problems found online, to the point that it drowns out other ideas). The event log has the entries in the form of the following:
Message delivery to the host '74.125.148.14' failed while delivering to the remote domain 'york.edu' for the following reason: The remote server did not respond to a connection attempt.
To me this sounds like either a firewall problem (I turned it off – no luck) or an authentication/encryption problem. I've triple-checked that the username and password are correct, and the TLS encryption option is enabled (as it should be). The new server is installed in hyper-v, and so for kicks I tried disabling the firewall on the host as well, but that hasn't helped.
Updated:
Also, I am able to telnet smtp.gmail.com 25 and I get the expected 220 response. Of course, I can go no farther via telnet because it requires a STARTTLS command, but I do at least get that far.
Any ideas?
Best Answer
Okay, once again I missed the obvious. In setting up the smtp server, after making a change I would go to the root of my management console window for IIS and tell it to restart to make sure all the changes were applied. Unfortunately, this would not restart the smtp service, and my changes weren't making it in. Once I corrected this behavior I started seeing actual error messages, and correcting those was a snap.