1

In our LAN, we have a development box with IIS 7 that has an SMTP Virtual Server installed. All development applications send outgoing mail to this virtual SMTP server, and it in turn relays the mail to our internal Exchange 2007 server. Or, at least it used to. Our network engineer recently replaced our Exchange server with another one, and now the mail is no-longer relaying.

Strangely enough, in our production environment, we have a similar setup. All outbound mail is sent to a virtual SMTP server (same version of IIS), and that server relays mail to the same Exchange server, only over the Internet. And outbound mail is working from the production environment. I've tried mirroring every single setting on our development box, including changing the smart host to the Exchange box's Internet-facing host name, and mail continues to linger in the queue.

The development box is able to successfully resolve the smart host's name, and I can connect to the Exchange server via port 25 from that box just fine.

Being completely unfamiliar with Exchange and weakly familiar with SMTP, I'm clueless as to how to troubleshoot this issue. The network engineer hasn't been able to figure things out either. What could be causing this to not work?

Here's my Virtual SMTP Server settings.

  • Under the delivery tab, Outbound Security dialog of the SMTP server, "Integrated Windows Authentication" is selected, and a valid username & password is entered. The user name is prefixed by the Windows domain (domain\username). TLS encryption is selected.
  • Under the delivery tab's Advanced dialog, we have the following settings:
    • Masquerade domain: mycompany.com (I've tried removing this to no avail)
    • Fully-qualified domain name: mycompany.local (I've also tried mycompany.com)
    • Smart host: myexchangeserver.mycompany.local (I've also tried its public domain name)
    • The direct delivery and reverse DNS lookup options are disabled

As far as Exchange settings go, I'm not sure what to look for, but I have access to the box and can post its relevant settings if necessary.

Jacob
  • 67
  • 2
  • 9

2 Answers2

2

Rather than poking at a black box and wondering why it won't work, install "Network Monitor" or Wireshark on the SMTP relay machine and sniff some SMTP traffic. You'll find out in about 30 seconds why your mail is being rejected. That's going to be your path of least resistance. The box wants to tell you what's wrong, you just need to look.

Your "network engineer" should've reached for the sniffer earlier, IMO. Sniffing the traffic on the wire seems "taboo" to some people, but it's often the best way to get to the bottom of a problem in a human-readable protocol like SMTP.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • I tried doing so earlier and saw no SMTP traffic. I'll try it again just in case. However, I suspect that SMTP traffic will continue to not show up since I'm using TLS encryption. How would encrypted traffic appear? – Jacob Aug 12 '09 at 19:09
  • Duh! I didn't see that you're using TLS. Can you turn off TLS temporarily to see the plaintext traffic? – Evan Anderson Aug 12 '09 at 19:53
  • Strange... I see no SMTP traffic on the box through Wireshark, even with TLS disabled. Very fishy. – Jacob Aug 12 '09 at 20:27
  • You do see SMTP traffic when you TELNET to the SMTP server manually, though, right? – Evan Anderson Aug 12 '09 at 20:51
  • Yes. All the trappings of the protocol appear to be working through SMTP. – Jacob Aug 12 '09 at 20:55
1

We just talked to Microsoft's support, and we figured it out. The fully-qualified domain name setting under the advanced dialog of the delivery tab was supposed to be the virtual SMTP server's name, not just the domain name. Now that it's set to myvirtualsmtpserver.mycompany.local, mail is being relayed as expected.

Jacob
  • 67
  • 2
  • 9
  • 1
    Well done Jacob! Just the ticket. Our Fully Qualified Domain Name (FQDN) was set to the local server and worked fine for 8-years. In Feb 2014 we could no longer relay emails. Having followed your advice it solved the problem! Thanks :-) –  Feb 13 '14 at 18:38