Exchangepedia Blog is read by visitors from all 50 US States and 150 countries world-wide
The SMTP stack provided by IIS' SMTP svc in Exchange Server 2003/2000 changes significantly when Exchange is installed on a Windows server. Some ESMTP extensions are added to support Exchange, it gets Exchange's Advanced Queuing Engine (AQE) implemented in phatq.dll, and the Categorizer (phatcat.dll). The mailroot path is moved from IIS' default (\inetpub\mailroot) to \exchsrvr\mailroot. Post-Exchange install, you cannot use IIS to manage SMTP - management functionality is provided by Exchange System Manager (ESM).
In the process, Exchange changes some of the default parameters set by IIS' SMTP stack. It is important to change many of these defaults to what's suitable for your environment/organization in order to gain some additional security.
Here are some examples:
1) Message size: IIS' default 2048 Kb changes to a populated parameter of 4096 Kb, but it's not enforced [screenshot]. Most deployments will need to set this to a higher limit.
2) Recipients per message: I find this to be the most annoying of all - changes from IIS' 100 max recipients per message to a whopping 64,000 recipients! I can't imagine the size of organizations this caters to, but I suspect even many larger organizations find this excessive. Important to change this one to something more appropriate.
3) Retry intervals: Change from IIS' 15, 30, & 60 minutes (for 1st, 2nd, and 3rd retries which are explicitly specified) to 10 minute intervals each. Subsequent retry interval changes from IIS' 240 minutes to 15 minutes. Now this is a change that doesn't belong to this irksome list - I actually like the more frequent retries at smaller intervals, particularly now when greylisting is becoming all the rage. I would probably decrease the first retry interval to as little as 2-5 minutes to bypass greylisting agents on destination hosts, but you should try and see what works best for your environment.
4) Delay Notification: This is the time Exchange waits before informing the sender that delivery of a message is delayed. In this case, the default doesn't change from IIS to Exchange, and it's set at 12 hours. Pause here and think how soon your users would want to be notified when mail is delayed. Should they wait 12 hours before finding out? Didn't think so... I often change this to as little as an hour or two, though some deployments require this to be as little as 30 minutes. Remember those calls from users wanting to know whether their email made it to the recipient - sent less than an hour ago? Users expect email to be delivered within minutes (if not seconds!), so 12 hours is a tad excessive, imo, and needs to be changed.
Some other defaults that I advise changing in most deployments:
5) SMTP virtual server binding: By default, SMTP virtual servers are bound to "All Unassigned" - that is all IP addresses not explicitly used by other SMTP virtual servers. It's a good idea to bind this to a particular IP address, unless the intent is to be listening on all IP addresses for SMTP traffic. Remember, this doesn't impact outbound email, which still gets routed using the IP address closest to the destination network - whether bound to a SMTP virtual server or not. (For more info about the latter, read another one of Scott Landry's excellent posts on the team blog, titled
"SMTP Virtual Server Myths Exposed". Specifically, Myth #4: Virtual Server IP Address Will Be Used For Outgoing Connections - Bharat).
6) Number of connections: Perhaps one of the most important settings - there are no limits on number of SMTP connections by default [screenshot]. Limiting this to a number appropriate for your environment is highly recommended, and part of a good defense against DoS/spam attacks imo.
7) Logging: By default, logging of SMTP activity is not enabled. Unfortunately, many users find out after beginning to troubleshoot a specific SMTP issue. [Read my previous post on logging - "Logging SMTP protocol activity"]
8) Session size: By default, Exchange limits number of messages sent per connection to 20. If you're only accepting messages from a SMTP relay host in your perimeter network or at a service provider (in cases where you don't accept inbound SMTP mail directly, and your MX record points to your SMTP relay host or a service provider), it may make sense to increase this, again - depending on your environment/message volume. However, session sizes (configured in Kb) should be limited as well - these are not by default. It's a good idea to limit session size to:
max. message size x messages per connection.
(assuming you've calculated protocol overhead ~30% when setting max message size).
Before you fire up ESM to change some or all of the above, I highly recommend testing every change in a test environment - if possible, do this while emulating your normal message volumes.
Exchange Server 2007 ships with a new SMTP stack native to Exchange (IIS' SMTP service is not required on servers with Exchange Server 2007), so some of the above doesn't apply. Overall, Exchange Server 2007's ReceiveConenctors behave more intelligently (as one would expect from a shiny new version of Exchange :). More about that in a later post.
In the process, Exchange changes some of the default parameters set by IIS' SMTP stack. It is important to change many of these defaults to what's suitable for your environment/organization in order to gain some additional security.
Here are some examples:
1) Message size: IIS' default 2048 Kb changes to a populated parameter of 4096 Kb, but it's not enforced [screenshot]. Most deployments will need to set this to a higher limit.
2) Recipients per message: I find this to be the most annoying of all - changes from IIS' 100 max recipients per message to a whopping 64,000 recipients! I can't imagine the size of organizations this caters to, but I suspect even many larger organizations find this excessive. Important to change this one to something more appropriate.
3) Retry intervals: Change from IIS' 15, 30, & 60 minutes (for 1st, 2nd, and 3rd retries which are explicitly specified) to 10 minute intervals each. Subsequent retry interval changes from IIS' 240 minutes to 15 minutes. Now this is a change that doesn't belong to this irksome list - I actually like the more frequent retries at smaller intervals, particularly now when greylisting is becoming all the rage. I would probably decrease the first retry interval to as little as 2-5 minutes to bypass greylisting agents on destination hosts, but you should try and see what works best for your environment.
4) Delay Notification: This is the time Exchange waits before informing the sender that delivery of a message is delayed. In this case, the default doesn't change from IIS to Exchange, and it's set at 12 hours. Pause here and think how soon your users would want to be notified when mail is delayed. Should they wait 12 hours before finding out? Didn't think so... I often change this to as little as an hour or two, though some deployments require this to be as little as 30 minutes. Remember those calls from users wanting to know whether their email made it to the recipient - sent less than an hour ago? Users expect email to be delivered within minutes (if not seconds!), so 12 hours is a tad excessive, imo, and needs to be changed.
Some other defaults that I advise changing in most deployments:
5) SMTP virtual server binding: By default, SMTP virtual servers are bound to "All Unassigned" - that is all IP addresses not explicitly used by other SMTP virtual servers. It's a good idea to bind this to a particular IP address, unless the intent is to be listening on all IP addresses for SMTP traffic. Remember, this doesn't impact outbound email, which still gets routed using the IP address closest to the destination network - whether bound to a SMTP virtual server or not. (For more info about the latter, read another one of Scott Landry's excellent posts on the team blog, titled
"SMTP Virtual Server Myths Exposed". Specifically, Myth #4: Virtual Server IP Address Will Be Used For Outgoing Connections - Bharat).6) Number of connections: Perhaps one of the most important settings - there are no limits on number of SMTP connections by default [screenshot]. Limiting this to a number appropriate for your environment is highly recommended, and part of a good defense against DoS/spam attacks imo.
7) Logging: By default, logging of SMTP activity is not enabled. Unfortunately, many users find out after beginning to troubleshoot a specific SMTP issue. [Read my previous post on logging - "Logging SMTP protocol activity"]
8) Session size: By default, Exchange limits number of messages sent per connection to 20. If you're only accepting messages from a SMTP relay host in your perimeter network or at a service provider (in cases where you don't accept inbound SMTP mail directly, and your MX record points to your SMTP relay host or a service provider), it may make sense to increase this, again - depending on your environment/message volume. However, session sizes (configured in Kb) should be limited as well - these are not by default. It's a good idea to limit session size to:
max. message size x messages per connection.
(assuming you've calculated protocol overhead ~30% when setting max message size).
Before you fire up ESM to change some or all of the above, I highly recommend testing every change in a test environment - if possible, do this while emulating your normal message volumes.
Exchange Server 2007 ships with a new SMTP stack native to Exchange (IIS' SMTP service is not required on servers with Exchange Server 2007), so some of the above doesn't apply. Overall, Exchange Server 2007's ReceiveConenctors behave more intelligently (as one would expect from a shiny new version of Exchange :). More about that in a later post.
Labels: Administration, SMTP
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home