Exchange Queue & A
Secure E-Mail Protocols, Mysterious Spam, and More
Nino Bilic and Scott Landry
This column is based in part on a prerelease version of Windows Server 2008. Details herein are subject to change.
Q I want to use secure SMTP—how do I get Exchange Server to listen for SMTP on port 465?
A I'm sorry, but you can't do this. Yes, you can make any SMTP virtual server or Receive connector listen on port 465, but that will not achieve your goal of secure SMTP (SMTPS).
Why? Well, let's back up a little and see. There are two types of SSL: explicit and implicit. Initially, most of the SSL was implicit, meaning that a dedicated port for SSL was used. For example, HTTP is on port 80 by default, but HTTPS (HTTP with SSL) is on port 443. Several years ago, the Internet community decided that a dedicated port should not be required for SSL. Thus, explicit SSL was born.
Netscape had already chosen 465 as the SMTPS port, but Exchange Server had no SSL functionality in SMTP. However, the Exchange team saw the advantage of explicit SSL—that it could be used equally by clients and servers—and chose to support explicit SSL for SMTP.
In the case of SMTP, explicit SSL uses the STARTTLS ESMTP command to signal that the existing socket is about to be secured. Most other SMTP server and client vendors have implemented the STARTTLS command as well, so there never was much need to support port 465, which wasn't an official Internet standard anyway.
To this day, no version of Exchange Server supports implicit SSL for SMTP. Telling an Exchange Receive connector or SMTP virtual server to listen on port 465 does not change this fact. Therefore, you need to use a client that supports STARTTLS on port 25. If you can't use port 25, the next logical choice is 587, which is the standard port for client SMTP submissions. There aren't many modern clients that don't support STARTTLS on 25, so adding support for implicit SSL has not been necessary.
By the way, Exchange POP3 and IMAP4 protocols have always supported implicit SSL. But in Exchange Server 2007, there is now added support for explicit SSL for these two protocols as well. But since not many clients support this newer standard yet, implicit SSL is going to be around for the foreseeable future.
Q I have a great deal of mail queued to a number of domains—and none of my users sent any of the mail. What's going on, and how do I prevent it?
A You're not alone. Anyone who has a server on the Internet may run into this problem. Basically, there are two possible causes. The first is that you somehow opened yourself up for relay (see
support.microsoft.com/kb/304897). But of course you wouldn't do that, would you? (Open relays have been disabled by default since Exchange Server 2000.) So it's more likely you're seeing what's called non-delivery report (NDR) spam. In the process of sending unsolicited commercial e-mail (UCE), spammers often send to nonexistent addresses at your domain. Your server tries to let the spammer know that the users don't exist, but of course, the spammer has spoofed the return address. The spammer may be spoofing an invalid address (in which case the NDR hangs out for a while until it times out), or he may be attempting to have your server send spam to another domain on his behalf, as an attachment of the NDR that your server has generated.
You could disable NDRs, but then if a legitimate user mistypes an address by mistake, your server will never let him know that the e-mail did not go through and critical messages could be lost. Here's a better solution.
First, make sure you are not open for relay. (I just had to say it.) Next, turn on some sort of anti-spam filtering, such as the intelligent message filter (IMF) or the Exchange Server 2007 content filter, as well as a few Realtime Block Lists (RBLs). This can be in either the Edge Transport role or the Hub Transport role, but it should be done at the very first hop because over 90 percent of mail volume tends to be spam and you don't want to keep your servers busy with all that junk).
Finally, enable recipient filtering on the first Exchange Server that accepts mail into your environment. This allows your server to reject a message before it comes into your network. Legitimate address mistypes will still get the NDR, but the NDR will be generated by the sender's server.
Q I had one server running Exchange Server 2000 and one running Exchange Server 2003, each sending mail successfully to the Internet. Then I installed Exchange Server 2007 and now mailboxes on each server cannot send mail.
A If you have had only one Exchange Server in the past, you might not be very familiar with the concept of connectors. Exchange connectors are logical routing configuration objects that tell Exchange where to direct e-mail. When you introduce Exchange Server 2007 into an existing organization, in order to route mail you absolutely must have routing group connectors and an SMTP connector.
You'll need two routing group connectors, one going from the Exchange Server 2007 routing group to the Exchange Server 2003 routing group, and vice versa. You can set this up as part of the installation process, but if you missed it or you're not sure, you can check using the Exchange Management Shell and correct the problem there. If you don't, you will not be able to send mail between your servers. Messages will end up in unreachable destination queues.
To route Internet mail you only need one SMTP connector, also known as a Send connector in Exchange Server 2007. You should have one in Exchange Server 2000 and Exchange Server 2003, but you may have gotten by without it. The address space should be SMTP:* for all domains, and you can specify either the use of a smart host or DNS for mail delivery. You choose whether you want the Exchange Server 2007 server or the older server to handle the outgoing Internet mail, or you can create one on both routing groups if you want each server to handle its own. You can also create one of these as part of the Edgesync process if you have installed an Edge Transport server role.
If you previously put a smart host on the SMTP virtual server, now is a good time to remove it. It should only be on the SMTP connector, never on the virtual server as that will break the routing group connector.
You should also be aware that inbound e-mail is controlled by your MX record or the IP the firewall is forwarding to. There isn't much to configure on the Exchange side, but this document should help if you're still having trouble:
msexchangeteam.com/archive/2006/11/17/431555.aspx.
Q Why do I get multiple journal reports for the same message in Exchange Server 2007?
A The Exchange Server 2007 transport journaling agent will journal messages after categorization. The categorizer has many reasons why it bifurcates a message (that is, copies the message body and puts different envelope recipients on the different copies). Here's an example: because the journaling now has the ability to tell you what the membership of a distribution group was at the time the message was sent, one case where you might get multiple reports is for a nested distribution group.
This additional richness in the reporting means that you may get a few copies of the same message, each with a unique report. There isn't a guaranteed way to know if all the reports have arrived for a message, but if you're doing archiving, you'll want to work with your archive vendor to make sure it's aware of the changes.
Q Where did the feature for forwarding unresolved messages to the host go in Exchange Server 2007? What do I do now?
A The dog ate it.
Actually, this specific feature never worked very well in situations where you had more than one Exchange Server. Exchange already had another way to accomplish the same thing, however, and that method was much more powerful. Specifically, you have the ability to share individual SMTP domains with other systems. So the "forward unresolved" feature was dropped and the shared domain concept was carried forward and simplified. In Exchange Server 2007, just go to Organization | Hub Transport | Accepted Domains and change the domain type from Authoritative to Internal Relay. It's actually a little more complex than this for some environments, and we're working to update some of the documentation. But this should help in the meantime.
Q I am trying to prepare my root domain for Exchange Server 2007 installation. The server I am trying to run Exchange Server 2007 setup from has Exchange Server 2003 Exchange System Manager (ESM) installed and the setup is failing. What's the problem here?
A Simply put, running any part of Exchange Server 2007 setup on a machine that has any Exchange Server 2000 or 2003 components installed is not supported. Because Exchange Server 2003 ESM is installed, the Exchange Server 2007 setup will see this and a setup prerequisite check will fail and tell you, "A previous version of Exchange Server is already installed on this computer. Run Exchange Server 2007 Setup from a different computer or remove the previous version of Exchange Server."
Probably the easiest way to work around this problem is to simply run the Exchange Server 2007 setup from another server in the root domain and prepare your domain that way. If that's not feasible, the Exchange Server 2003 component will have to be uninstalled before you can continue with the Exchange Server 2007 setup.
Remember that you can use the 32-bit version of Exchange Server 2007 to prepare the domain, so any 32-bit server in the root domain will usually do. For more information on this subject, please see technet.microsoft.com/library/bb232170.aspx.
By the way, this means that you can't install Exchange Server 2003 ESM and Exchange Server 2007 Exchange Management Console on the same machine as the coexistence of Exchange Server 2003 and Exchange Server 2007 management tools on the same machine is not supported. Exchange Server 2007 will block setup if you attempt to install it on a machine that has any Exchange Server 2000 or Exchange Server 2003 component installed.
Finally, note that you should not attempt to install Exchange Server 2007 management tools first and then follow with Exchange Server 2003 tools on the same machine. This approach will put you in a configuration that has not been tested and might give you unexpected results when trying to manage your servers. If you need to manage both server versions from a single machine, you could use remote desktop to connect to one version, or use a virtual machine to host a different version of the management tools in an isolated environment.
Q When, oh when, will I finally be able to run Exchange Server 2007 Management Tools on my Windows Vista® workstation?
A The official support for Exchange Server 2007 Management Tools on
Windows Vista is coming with the release of Exchange Server 2007 SP1. A package containing the Exchange Server 2007 SP1 management tools will be available for download once Exchange Server 2007 SP1 is released.
Q What about Exchange Server 2003 ESM on Windows Vista or Windows Server 2008? Will I be able to run that too?
A No, unfortunately this will not work. Management tools for any version of Exchange Server prior to Exchange Server 2007 SP1 will not be supported on either Windows Vista or Windows Server 2008. That means that even after Windows Server 2008 releases, installing Exchange Server 2003 ESM on it will not be supported. Management of Exchange Server 2003 servers will have to be done either from Windows Server 2003 or Windows XP workstations; alternatively, you can use the Remote Desktop connection from any OS.
Q I have several Exchange Server 2003 servers running in my domain. Will I be able to upgrade my domain controllers to Windows Server 2008 domain controllers?
A Yes indeed, running Exchange Server 2003 SP2 in the domain that has Windows Server 2008 domain controllers is supported. Please note that Exchange Server cannot use Windows Server 2008 read-only domain controllers (RODCs) or read-only global catalog servers (ROGCs). Manually specifying (hardcoding) Exchange Server to use the Windows Server 2008 RODC/ROGC might result in unexpected behavior.
Nino Bilic a Supportability Program Manager for Exchange Server, spends his free time discovering the beauty of server-to-server communication by reading a ton of Netmon traces before going to sleep at night.
Scott Landry, a Support Escalation Engineer for Exchange Server, does not go anywhere without his towel, copy of the Guide, and his trusty Windows Mobile phone.
Scott Landry a Support Escalation Engineer for Exchange Server, does not go anywhere without his towel, copy of the Guide, and his trusty Windows Mobile phone.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.