Exchange Server 2007 Frequently Asked Questions

Part of this column discusses the pre-release version of Windows Server 2008, where specific information may be changed.

Q: I want to use secure smtp-how do I get Exchange Server to listen on port 465 for SMTP?

A: Unfortunately, your goal cannot be achieved. You can indeed make the SMTP virtual server or receive connector listen on port 465, but this does not guarantee the use of secure SMTP (SMTPS).

Why? Let's explain. There are two types of SSL: explicit and implicit. Initially, most SSL was implicit, meaning that a dedicated port for SSL was used. For example, HTTP is on port 80 by default, and HTTPS (HTTP with SSL) is on port 443. A few years ago, the Internet community decided not to use a dedicated port for SSL. Therefore, explicit SSL arises.

Although Netscape has selected 465 as the Smtps port, Exchange Server does not provide SSL functionality in SMTP. However, the Exchange team sees the benefits of explicit SSL (which both clients and servers can use), so they support SMTP using explicit SSL.

For SMTP, explicit SSL uses the STARTTLS ESMTP command to indicate that an existing socket will be protected. Most other SMTP servers and client vendors have also implemented the STARTTLS command, so there is not much need to support port 465, and this is not an official Internet standard.

To date, no version of Exchange Server supports SMTP using implicit SSL. Having an Exchange receive connector or an SMTP virtual server listening on port 465 cannot change this fact. Therefore, you need to use a client that supports STARTTLS on port 25. If you cannot use port 25, you can logically choose 587, which is the standard port for client SMTP submissions. Now the client typically supports STARTTLS on port 25, so there is no need to add support for implicit SSL.

Incidentally, the Exchange POP3 and IMAP4 protocols typically support implicit SSL. However, in Exchange Server 2007, support for explicit SSL has been added to both protocols. However, because there are not many clients that support this newer standard, implicit SSL will continue to exist for some time.

Q: We send a large number of messages to many domains, but they are queued-none of my users can send any mail. What's going on here? How to prevent this?

A: This problem is not the only one you have encountered. Anyone who owns a server on the Internet may experience this problem. There are generally two reasons. The first reason is that you are inadvertently opening the relay function to yourself (see support.microsoft.com/kb/304897). But, of course, you don't want to do that, do you? (Open relay is disabled by default, starting with Exchange Server 2000.) Therefore, you are likely to receive a Non-delivery report (NDR) spam message. In the process of sending unsolicited commercial e-mail (UCE), spammers often send them to addresses that do not exist in your domain. Your server tries to make spammers know that the user he sent to does not exist, of course, so that spammers have cheated on the return address. Spammers may cheat on an invalid address (in which case the NDR hangs for a period of time until it expires), or he may be trying to send a spam message from your server to another domain on his behalf as an NDR attached to your server.

You can disable NDRs, but if the legitimate user then accidentally types the wrong address, your server will never know that the message was not delivered and might lose important messages. Here's a better solution.

First, make sure you are not opening the relay (I just have to say that). Then, enable some sort of anti-spam filtering feature, such as Intelligent Message Filter (IMF), Exchange Server 2007 content filter, or real-time block list (RBL). These operations can occur in the Edge Transport role or Hub transport role, but because more than 90% of the messages may be spam and you do not want the server to be busy with the garbage, you should do so at the first hop.

Finally, the recipient filtering feature is enabled on the first Exchange Server in your environment. This way, your server can reject a message before it enters your network. A legitimate user who types the wrong address can still receive an NDR, but this NDR will be generated by the sender's server.