Are Distribution Groups really being used?

Over the years, you end up creating a large number of Distribution Groups based on user demands. The regular departmental Distribution Groups such as Sales, Marketing, Engineering, and HR. The geographical ones such as AllUS, All-California, All-BayArea, and so on. The ones by employment status such as All-FTE for full-time employees, All-Contractors, and so on. And ones to facilitate the working habits of executives and senior managers, who want to address their team with a distro (geekspeak for Distribution Group) like JoeSchmoe-DirectReports. Then there are the more interesting ones, such as All-MountainClimbers, All-GrungeFans.

Why are so many of these Distribution Groups prefixed with an All-? Can Distribution Groups ever be All-Whatever? Is it possible to include all grunge fans in the All-GrungeFans group? Or only the ones who confess? Can you guarantee everyone in the Sales dept will be included in the All-Sales group by default— even if you used Dynamic Distribution Groups? There will be times when someone does not populate the department attribute for the newly hired Manager of Inside Sales for Timbuktu, and surrounding areas. After two weeks in his exciting new inside sales position, the poor bloke finds out he hasn't received the number of sales leads freely flying around on the distro, and unfortunately won't be able to meet his targets for selling surfboards in Timbuktu that quarter.

Over the lifetime of Exchange deployments, there will be groups that get used more frequently, such as Send-Your-Jokes-Here-If-You-Have-Nothing-Better-To-Do-At-Work (the alias conveniently shortened to ExecTalk... ), or the ones that never get used, such as All-ExEmployees (hard as it is to believe, at least one of these two have been spotted in real-world deployments!).

One fine day, your friendly manager/auditor/HR person shows up at your desk wanting to know which distribution groups are in use.

That's where message tracking logs come to the rescue— assuming these are enabled. If you've been mucking around with these logs in Exchange 2007, you probably know a fair bit of PowerShell, and chances are you're absolutely loving it! If not, head over to previous post Exchange Server 2007: Message Tracking from the command line, and get to know the wonderful cmdlet Get-MessageTrackingLog.

Tracking messages sent to Distribution Groups
How do we get a list of messages sent to Distribution Groups? By getting a list of all Distribution Group expansion events, noted in message tracking logs with the EventID EXPAND. The RelatedRecipientAddress field in the EXPAND entry contains the PrimarySmtpAddress of the Distribution Group expanded. Use the following command to grab a list. You can restrain Get-MessageTrackingLog cmdlet in a number of ways. Since these have been covered in the previous post, I won't go into details here.

Get-MessageTrackingLog -Start 2/1/2009 -EventID Expand | ft Timestamp,RelatedRecipientAddress -Autosize

You get back a table that looks something like this:

Timestamp RelatedRecipientAddress
--------- -----------------------
2/18/2009 4:36:27 PM DG-Marketing@MyDomain.com
2/18/2009 4:41:18 PM DG-Sales@MyDomain.com

Next, how do we determine how many messages each Distribution Group received? This is easily done by piping the results to the Group-Object cmdlet:

Get-MessageTrackingLog -Start 2/1/2009 -EventId Expand | group-object RelatedRecipientAddress | ft Name,Count -Autosize

This returns a count for each group of messages:

Name Count
---- -----
DG-Marketing@MyDomain.com 123
DeptSales@MyDomain.com 145

To list messages sent to a particular Distribution Group:

Get-MessageTrackingLog -EventID Expand | ? {$_.RelatedRecipientAddress -like "DG-Marketing@MyDomain.com"} | ft Timestamp,Sender,MessageSubject -Autosize

Of course, you could use the message tracking GUI in EMC— but would it rate anywhere close on your geek satisfaction index?

EHLO: DSNConversionMode and You

If you haven't already read Jason Nelson's take on Delivery Service Notifications (DSNs), head over right away to DSNConversionMode and You: An Administrator's Guide.

Disable Antispam agents on a Receive Connector

Exchange 2007's antispam agents are enabled for all Receive Connectors on a transport server. Is there a way to disable the agents on a particular Receive Connector?

Although not as simple as turning an agent off for each IP address or Receive Connector, Exchange 2007's new transport permissions model allows you to do this just as easily.

The ms-Exch-Bypass-Anti-Spam permission is what allows a sender to bypass antispam agents. By default, mail from authenticated senders is not filtered.

To allow unauthenticated/anonymous senders to bypass antispam filters on a particular Receive Connector, use the following command:

Get-ReceiveConnector "My Receive Connector" | Add-ADPermission -User "NT Authority\Anonymous Logon" -AccessRights ExtendedRight -ExtendedRights ms-exch-bypass-anti-spam

Related Posts and Links:

• Removing internal host names and IP addresses from message headers
  
• Why Get-TransportAgent doesn't agree with the Exchange console
  
• Exchange 2007 Content Filter: How to move messages to Junk Mail folder
  
• Exchange 2007 Content FIlter: The Whitelist Is Here!
  
• Exchange 2007 Transport Permissions Model
  

HOW TO: Prevent annoying spam from your own domain

One of the more annoying types of spam is the one that seems to be coming from your own domain; or worse— from your own email address! Of course, users from your own domain don't generally spam each other— unless you're using one of the free web-based email services. And most of us don't spam ourselves.

Obviously, this is coming from a spammer who has spoofed your email address, or that of someone else from your domain. Unfortunately, SMTP— the protocol that allows mail clients and servers to exchange email, allows headers to be spoofed easily.

In Exchange Server 2007, Accepted Domains tell Exchange which domains to accept email for. If a domain - e12labs.com in this example, exists as an Accepted Domain, there is no reason external senders should use that domain in the MAIL or FROM headers.

You may have remote POP3/IMAP4 users who use SMTP to send mail. However, such sessions should be authenticated, and preferably use a separate Receive Connector.

Thanks to the extensive Transport Permissions model in Exchange 2007, we can easily prevent such spam. Receive Connectors have the ms-exch-smtp-accept-authoritative-domain-sender permission which dictates whether an Accepted Domain can be used in the MAIL or FROM headers. External/internet hosts submit mail to your server without authentication, as anonymous senders. To prevent anonymous senders from sending mail using your domain(s), we need to remove the ms-exch-smtp-accept-authoritative-domain-sender permission assigned to them.

Use the following command to remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon on internet-facing Receive Connector(s):

Get-ReceiveConnector "My Internet ReceiveConnector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

Once this permission is removed, when anonymous senders try to submit mail using your Accepted Domain(s), here's how the SMTP conversation goes:

220 E12Postcard.e12labs.com Microsoft ESMTP MAIL Service ready at Wed, 3 Sep 2008 06:22:43 -0700
helo
250 E12Postcard.e12labs.com Hello [172.31.0.170]
mail from:jadams@e12labs.com
550 5.7.1 Client does not have permissions to send as this sender

Exchange stopped spoofing of P1/envelope headers. Let's continue the session and try to spoof the P2 headers (the ones in the DATA part of the message) — maybe that'll work!

mail from:someone@someotherdomain.com
250 2.1.0 Sender OK
rcpt to:jadams@e12labs.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
from:jadams@e12labs.com
subject: Header spoofing

This is how we spoof headers, spoof headers.

.
550 5.7.1 Client does not have permissions to send as this sender
quit
221 2.0.0 Service closing transmission channel

As you can see, removing the ms-exch-smtp-accept-authoritative-domain-sender permission stops spoofing of your domains in both envelope (P1) and message (P2) headers.

When not to remove the permission?
Is there a scenario where one should not remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon? Yes, on Receive Connectors used by internal or trusted SMTP hosts (such as copiers/scanners and application servers) that submit mail without authentication.

But you do have these internal/trusted hosts submitting to a separate Receive Connector, don't you?

Related posts:

• Exchange Server 2007: How To Allow Relaying
  
• Removing internal host names and IP addresses from message headers
  
• Header Firewall: Why spammers can't insert fake SCL (and other Exchange Organization) X headers
  

Delay Notifications: Informing users about delays in mail delivery

Users consider email to be a reliable communication mechanism - not as reliable as the dial tone, but pretty close. Most users expect mail to be delivered within minutes, if not seconds.

Many organizations, including those operating in the financial & banking sectors, have strict SLAs for mail delivery which specify mail delivery times granularly— for mail within a particular location (that is, within a Routing Group in Exchange 2003 and within an AD Site in Exchange 2007), between two locations, and to/from the internet.

Exchange Server sends a delay notification to inform the sender if delivery of a message is delayed beyond a configured timeout. The default delay notification timeout in Exchange Server 2003 is 12 hours. This has been reduced to a (comparatively) more realistic 4 hours in Exchange Server 2007.

When considering changing these defaults, it's a good idea to consider any SLAs and user expectations. Is it reasonable to expect a user to wait for 24 hours before informing him/her about a delay? 12 hours? 1 hour?


Figure 1: In Exchange 2007, the default delay notification timeout is 4 hours

You can change the delay notification timeout using the Exchange console (EMC) from Server Configuration | Hub Transport | SERVERNAME -> Properties | Limits tab.

To change delay notification timeout using the Exchange shell:

Set-TransportServer "SERVERNAME" -DelayNotificationTimeout 01:00:00

This sets the notification timeout to 1 hour. The value is specified in dd.hh:mm:ss (the standard format used by the shell). Valid values— minimum: 00:00:01 (yes, 1 second!) to 30.00:00:00 (30 days). It's recommended to wait till transient failure retries have been completed before sending a delay notification (that is, higher than TransientFailureRetryInterval x TransientFailureRetryCount).

In Exchange Server 2003, the delay notification timeout can be changed from SMTP Virtual Server | Properties | Delivery tab. There are different delay notification timeouts for outbound and local mail.

If you decide users don't need to know about mail delivery delays (and there could be perfectly legitimate reasons for that - although as I write this I can't think of any... ), you can disable delay notifications:

Set-TransportServer "SERVERNAME" -ExternalDelayDsnEnabled $false -InternalDelayDsnEnabled
$false

Have you changed the default delay notification in your organization? What is a reasonable time for notifying users about delays?

Related:

• SMTP Virtual Servers: Some irksome defaults you should change
  
• Set-TransportServer
  

Removing internal host names and IP addresses from message headers

Another frequently asked question about SMTP mail - how can I remove internal host names and IP addresses from outbound internet mail? More often than not, this results from the belief that somehow if the outside world finds out an organization's internal IP addresses and host names, it makes the organization vulnerable. Auditors love to point this out for some reason. Perhaps it's a part of a checklist written by a security expert at some law firm somewhere, and given the viral nature of checklists it's all over the place!

Let's take a look at what we're talking about here. As a message makes its way from one server to another, it may be handled by more than one SMTP hosts. Each host adds a RECEIVED header at the beginning of message headers, leaving a trace of where the message has been and when (a timestamp).

Here are headers from a message received from Dell. (Unnecessary headers removed).

Received: from smtp.easydns.com (205.210.42.52) by exchange.somedomain.com
(192.168.2.171) with Microsoft SMTP Server id 8.1.240.5; Mon, 19 May 2008
03:12:46 -0700
Received: from mh.dell.m0.net (mh.dell.m0.net [209.11.164.66]) by
smtp.easydns.com (Postfix) with ESMTP id 647C222914 for ;
Mon, 19 May 2008 06:14:46 -0400 (EDT)
Received: from [192.168.138.130] ([192.168.138.130:57330]
helo=fc13a1.dc1.prod) by oms1.dc1.prod (ecelerity 2.1.1.24 r(19486)) with
ESMTP id 3B/AF-18306-11351384 for ; Mon, 19 May 2008
03:14:41 -0700
Message-ID: <14154167762.1211192081379@delivery.net>
Date: Mon, 19 May 2008 03:14:41 -0700
From: Dell Small Business
Reply-To:
To:
Subject: $429 desktop, plus new laptops. Hurry and shop now.
Errors-To: dell@smallbusiness.dell.com
Return-Path: dell@smallbusiness.dell.com

These headers can be used to determine the path taken by a message— useful information for troubleshooting and preventing message loops.

What the standards say
Let's take a look at what the standards say. RFC 2821 says (capitalization of words as it appears in the RFC, emphasis added):

4.4 Trace Information

When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in section 4.1.1.4.

This line MUST be structured as follows:

- The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

and prohibits removing received headers (repeatedly). One example:

An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.

More secure?
Should you remove these headers, and "hide" internal hosts and IP addresses? Is it really a security risk?

There are many opinions about security through obscurity, but if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about.

Steve Riley, Senior Security Strategist at Microsoft, says:

In general, you can’t achieve any additional security by trying to hide things that weren’t designed to be hidden. IP addresses, wireless SSIDs, hostnames—these are all identifiers, and by definition, an identifier is intended to be known. Efforts to hide them generally fail, because the thing that the identifier points to still exists! Determined attackers will find the thing regardless of what you name it.

Microsoft does not remove internal message routing headers. Nor do Dell (as the message headers in the example above reveal), HP, and many other large organizations.

In many ways, the issues faced are similar to changing fqdn on SMTP Virtual Server/Receive Connector. Even if you make these changes, at least one internal hostname is likely to be revealed by the Message-ID (read "Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain").

Nevertheless, many organizations may have a legitimate need to cleanse outbound mail of internal host names and IP addresses, and you probably don't want to invite adverse remarks in an IT or compliance audit (should you find such a requirement on the auditor's checklist).

How to remove Received headers in Exchange Server 2007
Exchange Server 2007 offers an easy way to accomplish this. If your transport server sends outbound email directly using DNS lookup, or delivers to a smarthost without authentication, simply remove the Ms-Exch-Send-Headers-Routing permission assigned to Anonymous Logon— a well-known security principal that refers to anonymous users, as shown below:

Get-SendConnector "Connector Name" | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights "ms-Exch-Send-Headers-Routing" -user "NT AUTHORITY\Anonymous Logon"

What's your take?
Does your organization remove internal Received headers? What are the reasons cited? Does removing internal received headers make your organization more secure? Feel free to leave a comment and share your opinion about this.

Routing outbound mail using a particular IP address

A question that frequently and inevitably pops up when discussing Exchange transport is that of being able to route outbound mail using a particular IP address. The Exchange Server 2003/2000 transport architecture was confusing for many newcomers— the difference between an SMTP Virtual Server and an SMTP Connector being the main cause of this confusion. This is further exacerbated by the fact that SMTP Connectors use SMTP Virtual Servers as bridgeheads.


Figure 1: In Exchange Server 2003/2000, the IP address binding in SMTP Virtual Server properties is only for inbound connections

I've often quoted Scott Landry's post on the team blog— SMTP Virtual Server Myths Exposed. Myth #4 in Scott's post:

Myth 4: Virtual Server IP Address Will Be Used For Outgoing Connections

The last source of misunderstanding is the socket which will be used to open an SMTP connection. This may seem confusing and somewhat contradictory of my first point, but SMTP simply tells the Windows network stack to provide SMTP with a socket. It does not provide a source IP address to use, and as such, you will notice that the source IP address assigned by Windows will be based on the Windows routing table, not taking into consideration the IP of the SMTP VSI that is delivering the message. A common observation of this is that on a cluster server we are using the physical machine IP as our source IP, not any of the virtual IP addresses.

Exchange Server 2007, with its shiny new transport stack (freshly divorced from IIS' SMTP service), makes this quite clear. Receive Connectors, somewhat comparable to the SMTP Virtual Server in previous versions, are for receiving inbound mail. Send Connectors are for sending outbound mail.

When creating or modifying a Send Connector using the shell, you can specify the SourceIPAddress parameter to configure it to use a particular IP address for outbound mail. The IP address can be any IP address bound to a NIC on the Edge Transport server that is configured as a source server on the Send Connector. To modify an existing Send Connector, using the following command:

Set-SendConnector "ToInternet" -SourceIPAddress 1.2.3.4

However, as noted in the documentation, this only works on Edge Transport servers. Hub Transport servers ignore the SourceIPAddress parameter.

Exchange Server 2007 SP1: The most obscure (but relevant) changes

Recently I was asked by a fellow MCT (and now Exchange MVP) to list 3 most obscure (but relevant) changes in Exchange Server 2007 SP1. The first thing that came to mind was the change made to Back Pressure settings.

Back Pressure stops inbound mailflow on transport servers if system resources fall below a certain level. In Exchange Server 2007 RTM, the threshold for free disk space was 4 Gigs - if you had less, Back Pressure (yes, there have been jokes about the name of this feature... ) stops inbound mailflow and throws a 452 4.3.1 Insufficient system resources error on mail submission. Read previous post Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources for my experience with this.

In SP1, the threshold has been reduced to a much more realistic level of 500 Mb. I can probably live with that.

I later posted about turning Back Pressure off - not necessarily something I recommend in production. However, in test environments (particularly in virtual server environments with disks created to be the smallest size possible to allow installation of Windows Server and Exchange... ) this generally makes sense.

Related posts:
- Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources
- Exchange Server 2007: How to turn off the Back Pressure feature on transport servers

Exchange Server 2007: Renewing the self-signed certificate

Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.

The self-signed certificate meets an important need - securing communication for Exchange services by default. Nevertheless, one should treat these self-signed certificates as temporary. It's not recommended to use these for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).

However, should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these need to be renewed - just as you would renew certificates from 3rd-party or in-house CAs.

 To renew the certificate for server e12postcard.e12labs.com, a server with CAS and HT roles installed:

Get-ExchangeCertificate -domain "e12postcard.e12labs.com" | fl

Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.

Get a new certificate with a new expiration date:

Get-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F" | New-ExchangeCertificate

If the existing certificate is being used for SMTP, you will get the following prompt:

Confirm
Overwrite existing default SMTP certificate,
'C5DD5B60949267AD624618D8492C4C5281FDD10F' (expires 8/22/2008 7:20:34 AM), with certificate '3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E' (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Type y to continue. A new certificate is generated.

Thumbprint   Services   Subject
----------   --------   -------
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E   .....   CN=E12Postcard

The new certificate is generated and enabled. Examine the new certificate:

Get-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" | fl

 The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP - IIS is missing.

To enable the certificate for IIS:

Enable-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" -services IIS

This enables the certificate for IIS (in addition to any other services it may already be enabled for - it adds to existing values of the services property).

 Test services are working with the new certificate. If it works as expected, the old certificate can be removed:

Remove-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F"

Related posts:
- Outlook Anywhere and Exchange's Self-Signed Certificate
- Which name should I use as Common Name for my UC certificate?
- DigiCert: A Certificate Authority with excellent customer service

SMTP Connector Myth: Messages are always routed over SMTP Connectors with more specific address spaces

An Exchange Server message routing myth forever being propagated (including by me!):

If 2 SMTP Connectors (or Send Connectors in case of Exchange Server 2007) exist, one with a more specific address space, like exchangepedia.com, and one for a more generic address space like *, messages are always routed over the Connector with the more specific address space.

Now, generally that rule of thumb works for most purposes, until you consider restrictions on Connectors. These include:
Connector Scope: (Entire) Organization, or the Routing Group (to which the Connector belongs or is homed to)
Message Size restrictions: To prevent messages over a certain size from being routed over a Connector
Delivery Restrictions: To allow/prevent messages from particular senders from being routed over a Connector (Exchange Server 2003/2000)


Figure 1: Content Restrictions on a SMTP Connector, including message size limit

Scenario:
You want to prevent users from sending messages over 100 Kb to exchangepedia.com.
- Connector1 for address space exchangepedia.com, message size restriction of 100Kb.
- Connector2 for address space *, no message size restrictions.
Result:
- Messages for exchangepedia.com recipients with a message size that is under the 100kb limit are routed over Connector1.
- Messages for exchangepedia.com recipients with a message size of over 100kb are routed over Connector2 with the generic address space of *. Connector1 with more specific address space of exchangepedia.com is never considered.

If you want to limit messages sent to exchangepedia.com to only 100kb, you cannot do it using the configuration in the above scenario.

From Exchange Server 2007 documentation:
Routing to External Domains -> Selecting the Routing Path to an External Recipient):

If more than one Send connector is configured to have an address space that meets the routing requirements for an external recipient, Exchange 2007 routing will select a single connector through which to route the message. The selected connector must meet the message size constraints. After Exchange 2007 has eliminated all connectors that have prohibitive message size restrictions, routing applies the following criteria to determine to which connector it will route:

From the list of all Send connectors and foreign connectors that are configured in the Exchange organization, it narrows the list to connectors that satisfy all the following criteria:

- In the scope for the local server
- Enabled
- With an address space that matches the recipient's e-mail domain

From the resulting list, select the connector with the most specific address space match. No matching connectors may be found.

Maybe an Exchange Server 2007 change, you wonder. Not quiet - Exchange Server 2003 behaves similarly.

From Exchange Server 2003 documentation:
Exchange Server 2003 Message Routing -> Routing Path Selection Process

It determines all connectors to the message destination in the organization topology, and then analyzes message characteristics and connector restrictions to exclude all those connectors that must not be used to transfer the message.

In a nutshell: Connector selection happens after restrictions are checked.

Which Connector? Determining the Send Connector used in Exchange Server 2007 is quiet easy - if using different fqdns on a Send Connector, you can simply check the Received headers; or you can look at the SMTP logs (read previous post "Exchange Server 2007: Logging SMTP Protocol Activity"). In Exchange Server 2003, you can bump up the diagnostics logging on MSExchangeTransport -> Routing Engine/Service. Exchange logs Event ID 984, which provides details about message routing, including the Connector selected.

In the following screenshots, we see 2 different SMTP Connectors being selected for 2 messages to the same destination - the smaller message uses the Connector with the specific address space - exchangepedia.com, which routes the message to a smarthost. The larger message that exceeds that Connector's message size limit is routed using the Connector for address space *, which routes the message using DNS to lookup the MX record(s) for exchangepedia.com.


Figure 2: With Diagnostics Logging enabled, Exchange Server 2003 logs Event ID 984, which shows Connector selected (for a small message under 100kb in this case). The message is delivered to the Smarthost specified in the Connector.


Figure 3: Event ID 984 shows the Connector for generic address space * selected for a larger message (over 100kb in this case). Message is delivered using DNS lookup.

Unintended consequences? The implications aren't pretty, specially when you consider scenarios where one uses a SMTP Connector for a particular address space to enforce TLS (perhaps one of the biggest reasons why messages should never be routed over a Connector with a generic address space if a Connector for a specific address space exists). If I enforce message size restrictions on my Connector with TLS enabled, larger messages can and will be transmitted using the generic Connector that does not use TLS. Now we have the larger message(s) traveling over potentially unsecured SMTP sessions.

What about Delivery Restrictions? For Exchange Server 2003, the same is true for Delivery Restrictions. If the Connector for exchangepedia.com has Delivery Restrictions to prevent Joe Adams from sending messages to Exchangepedia, the message routes over the generic Connector for * - effectively flushing such restrictions down the tube. Restrictions on Connectors with more generic address space are a different story - if Joe has Delivery Restrictions on the * Connector, he cannot send internet mail.

The first task of the Routing Engine/transport should be to check if Connectors with more specific address spaces are available. If it finds any, there is no reason to exclude these from the routing decision. Any restrictions on that Connector exist for a purpose - to restrict message sizes, or to prevent certain users from sending to particular domains using Delivery Restrictions. By excluding Connectors with restrictions from the routing calculation, we're saying routing the message is more important than enforcing those restrictions. As a result, by routing the message over generic Connectors, other requirements for mail delivery to that address space, such as those mentioned above and other available Connector settings, may not be applied.

Related Posts:
- HOW TO: Prevent a user from sending and receiving internet mail
- Exchange Server 2007: Setting Message Size Limits
- Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

You can change the fully-qualified domain name (fqdn) used by a SMTP virtual server from its properties | Delivery tab | Advanced | Fully-qualified domain name. In the following example, we change the fqdn of a SMTP virtual server from its default - letter.exchangelabs.net, to postcard.exchangelabs.net.


Figure 1: Changing the fully-qualified domain name in SMTP Virtual Server properties

What this does:
1. Changes the fqdn displayed in the SMTP banner.
2. Changes the fqdn provided in HELO/EHLO command when sending outbound mail (see relevant part of a packet capture)
3. The fqdn provided in HELO/EHLO commands shows up in the Received headers in the message.

Delivered-To: foo@gmail.com
Received: by 10.142.188.12 with SMTP id l12cs257007wff;
Tue, 18 Dec 2007 07:24:25 -0800 (PST)
Received: by 10.114.15.1 with SMTP id 1mr2552630wao.27.1197991464897;
Tue, 18 Dec 2007 07:24:24 -0800 (PST)
Return-Path: <jadams@exchangelabs.net>
Received: from postcard.exchangelabs.net (64-169-85-157.ded.pacbell.net [64.169.85.157])
by mx.google.com with ESMTP id m40si5110107wag.2007.12.18.07.24.20;
Tue, 18 Dec 2007 07:24:24 -0800 (PST)
Subject: test fqdn
Date: Tue, 18 Dec 2007 07:22:22 -0800
Message-ID: <086C0984D0478545845025F046CD4E3F037678@LETTER.exchangelabs.net>
From: "Joe Adams" <jadams@exchangelabs.net>
To: "foo" <foo@gmail.com>

What it doesn't do:
- Doesn't change the fqdn used in the Message-ID, as seen in the above headers.

[Act surprised... ]: Now why can't the SMTP VS change the Message-ID as well?
Because RFC 2822 says so - a Message-ID is a globally unique identifier of a message. Once created, the Message-ID for a particular instance of a message should not be changed. It allows one to track messages, and correlate multiple messages to the same thread (using additional header fields like references and in-reply-to).

It's not very often that the SMTP VS encounters messages without Message-IDs. SMTP clients generally generate the Message-ID. When using Outlook (MAPI) or OWA, the Exchange Store generates it. When the SMTP VS sees a message without a Message-ID, it does create one. Try this by telnetting (I'm working on getting this word officially recognized as a verb... :) to the SMTP port of the server, and sending a message. The SMTP VS accepts the messages, and provides you with a Message-ID that uses the changed fqdn.

Changing the fqdn doesn't really "hide" the original fqdn of your server, and the server's IP address is still visible in message headers. As such, it is merely a cosmetic change that doesn't accomplish much in most scenarios. (I frequently refer to and quote Scott Landry's excellent post on the team blog: SMTP Virtual Server Myths Exposed. It's a must-read - Scott addresses the fqdn issue in Myth 3b: Modifying The FQDN of the SMTP Virtual Server).

Does changing the fqdn on the SMTP virtual server ever make sense? Yes, in some scenarios:
- SMTP VS that serves as a Bridgehead for outbound internet mail, if the server's original fqdn uses an invalid or unregistered domain or the hostname has an underscore (_) character (Refer to KBA 841091: Characters that are not supported for object names in Exchange). However, rather than using the default SMTP virtual server for outbound/inbound internet mail, it is recommended to create an additional SMTP Virtual Server for this.
- If the Exchange server has more than 1 SMTP virtual server

SMTP Virtual Server FQDNs and Service Principal Name

If you do decide to change the fqdn on the default SMTP virtual server, ExBPA will warn you about a missing Service Principal Name (SPN) in AD.


Figure 2: ExBPA error: Missing Service Principal Name. More information

Also take a look at the Kerberos authentication issue that may cause messages to be NDRed with a 550 5.7.1 Unable to relay for foo@domain.com, mentioned in KB 914137: Exchange Protocol Security authentication fails after you install Windows Server 2003 Service Pack 1 on a server that has multiple SMTP virtual servers in Exchange Server 2003.

If the fqdn field does all of the above, what does the Masquerade domain do?


Figure 3: Changing the masquerade domain in SMTP Virtual Server properties

The online documentation provides a hint:

"Use this text box to type an alternate domain for other SMTP servers to use when sending non-delivery reports (NDRs). NDRs will be returned to the alternate domain specified, instead of the domain from which the email originated."

If you change the masquerade domain, restart the SMTP VS and send a test message, chances are you won't see any changes in message headers.

The Masquerade domain setting works when the SMTP VS is a bridgehead for a Connector, and the mailbox that is used to send a message does not reside on the same server.

If it is a Bridgehead for a Connector, the SMTP VS changes the Return-Path header so NDRs are returned to the masquerade domain, as seen in the following headers (irrelevant header fields removed):

Delivered-To: foo@gmail.com
Return-Path: <jonstamp@footimesfive.com>
Received: from letter.exchangelabs.net (64-169-85-157.ded.pacbell.net [64.169.85.157])
by mx.google.com with ESMTP id b2si10345244rvf.2007.12.18.07.05.28;
Tue, 18 Dec 2007 07:05:29 -0800 (PST)
Received: from STAMP.exchangelabs.net ([172.31.0.169]) by letter.exchangelabs.net with Microsoft SMTPSVC(6.0.3790.2499);
Tue, 18 Dec 2007 07:03:33 -0800
Subject: Test masquerade from Jonstamp
Date: Tue, 18 Dec 2007 07:03:33 -0800
Message-ID: <AA446FF1A137FA47B5EABE4F94CAC7FD1AE7@STAMP.exchangelabs.net>
From: "Joe Onstamp" <jonstamp@exchangelabs.net>
To: "foo" <foo@gmail.com>
Return-Path: jonstamp@footimesfive.com

Released: ForeFront Security for Exchange SP1

ForeFront Security for Exchange SP1 follows Exchange Server 2007 SP1 out the door. FSE SP1 is compatible with Exchange Server 2007 SP1. It includes support for Windows Server 2008, IPv6, and improved content filtering.

Exchange Server 2007 SP1 and ForeFront Security for Exchange

- Before you upgrade Exchange Server 2007 to SP1, make sure you either upgrade ForeFront Security for Exchange to SP1, or uninstall it.
- If ForeFront Security for Exchange is upgraded to SP1, you must stop all ForeFront services before upgrading Exchange Server 2007 to SP1.

Download it here.

220 Welcome to a California mail server: Fighting spam with SMTP Banners

If you are interested in messaging and fighting spam, you probably watch the legal response to spam with some interest. Given the nature of email and the art of remaining anonymous or otherwise untraceable that spammers seem to have mastered, anti-spam laws were written off as largely ineffective, or even ridiculous. (The FTC begs to differ, in its report to Congress on the CAN-SPAM Act's effectiveness - PDF available here). Legislation and (its) enforcement can never be the sole approach to a problem mostly attributed to technology.

The much-talked about first conviction under the federal CAN-SPAM Act was handed out in California - to Nicholas Tombros in Los Angeles in 2004. Since then, quite a few spammers have had their date with the law, with the accompanying media brouhaha.

California anti-spam laws: California also has its own antispam laws - enacted as amendments to the Business and Professions Code. The rather lame one - Section 17538.4, allows California Attorney General to sue spammers, with a list of IFs that make it more like a "License To Spam". Section 17538.45 is the one of interest, aimed at protecting email service providers from spammers. Email service providers can file civil suits against spammers and claim greater of the following amounts:
- the actual monetary loss suffered by reason of that violation
- liquidated damages of $50 per message initiated or delivered, up to a maximum of $25,000 per day.

Any organization that provides the ability to send or receive email to registered users through equipment located in California (and is an "intermediary" in sending/receiving email) is an email service provider for the purpose of this law.

Interesting, as technology-related legislative action always is.

If your mail servers are located in California (and even if they are not... ), it makes sense to change the SMTP banner (SMTP 220 response) to give notice to a sender that your system should not be used to send unsolicited electronic mail advertisements.

The California Business and Professions Code Section 17538.45 states:

(3) (A) In any action brought pursuant to paragraph (1), the electronic mail service provider shall be required to establish as an element of its cause of action that prior to the alleged violation, the defendant had actual notice of both of the following:

(i) The electronic mail service provider's policy on unsolicited electronic mail advertising.

(ii) The fact that the defendant's unsolicited electronic mail advertisements would use or cause to be used the electronic mail service provider's equipment located in this state.

(B) In this regard, the Legislature finds that with rapid advances in Internet technology, and electronic mail technology in particular, Internet service providers are already experimenting with embedding policy statements directly into the software running on the computers used to provide electronic mail services in a manner that displays the policy statements every time an electronic mail delivery is requested. While the state of the technology does not support this finding at present, the Legislature believes that, in a given case at some future date, a showing that notice was supplied via electronic means between the sending and receiving computers could be held to constitute actual notice to the sender for purposes of this paragraph.

Let's leave the legal interpretation of laws to those who practice law. Regardless of whether your organization intends to take legal action against spammers or not, one of the important principles of information security is having policies in place and communicating them clearly. Not only does it demonstrate your organization's intent, it can be a potential deterrent for folks who may otherwise claim ignorance of such policies.

(While we're on the subject of SMTP banners, for historical context, also take a look at Paul Hobbes & John Levine's draft from 1998 titled "Anti-UBE and Anti-UCE Keywords in SMTP Banners". Much later, a SMTP extension was also proposed to include such information - RFC 3865 - A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension.)

Changing the SMTP banner: Assuming the policy is in place, the SMTP banner can be changed easily to communicate it, as hosted email security and compliance services provider Postini (acquired by Google not too long ago) does.

220 Postini ESMTP 11 y6_12_2c0 ready. California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.

On Exchange Server 2003/2000 or if using Windows Server's SMTP service component on SMTP gateways, the banner text can be changed by setting the IIS Metabase value ConnectResponse, using any Metabase editor or the adsutil.vbs script that ships with IIS (in the Inetpub\AdminScripts directory by default).

cscript adsutil.vbs set smtpsvc/1/ConnectResponse "220 California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements."

Note, the numeric value 1 after smtpsvc/ in the above command refers to the SMTP Virtual Server ID. Each SMTP VS has one, the default/first one starting at 1. To get a list of SMTP Virtual Servers using adsutil.vbs:
adsutil.vbs enum /p smtpsvc

Exchange Server 2007 makes changing the banner a relatively simple task. Note, the banner should start with the SMTP response code 220. Fire up the shell:

Set-ReceiveConnector "Connector Name" -banner "220 (Optional: Server.domain.com). California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements."

That wasn't too difficult, was it? If that simple banner change deters a a single spammer from victimizing your users, and in the process buys you the legal ammunition (that may some day help your organization take legal action, should it decide to.... ), is it worth it?

DigiCert: A Certificate Authority with excellent customer service

I finally took the plunge and decided to get a certificate from a public Certificate Authority (CA) for my Exchange Server 2007 server at home. A certificate that supports Subject Alternative Names (SAN certificate, aka "Unified Communications" certificate), no less. Having dealt with a number of CAs in the past, and having heard some horror stories about getting a certificate that supports Subject Alternative Names, I wasn't quite looking forward to the exercise.

Thanks to Office Communications Server (OCS) MVP (and fellow Zenpriser till recently... ) Lee Mackey, the CA he recommended - DigiCert - provided exemplary customer service.

Chain of events:
- Generate SAN certificate request using the New-ExchangeCertificate command from Exchange Server 2007 (for a couple of domains, includes the Autodiscover.domain.com fqdn).
- Submit request to DigiCert
- Get confirmation emails from DigiCert (for multiple domains)
- Within a few seconds, while I'm still clicking on the confirmation messages, I get a call from a DigiCert rep to confirm the details
- The rep informs me the physical/mailing address with the domain registrar for one of the domains is not current or not the same as the one I provided when requesting the cert
- Rep waits while I correct it on the domain registrar's web site
- Confirms the address is updated in the registrar's WHOIS info
- Asks for a photo ID to be uploaded on their secure site
- I email him the photoID instead of uploading it
- By the time I'm back from the scanner/copier to my desk, and hit refresh, the photo ID shows up on DigiCert's web site
- Within a few minutes I get the certificate in by email
- Install certificate and test it with the different domains - works!

An impressive and positive customer service experience - these guys rock! If you're in the market for a digital certificate, check them out.

Requesting and using certificates for Exchange Server 2007

- KB 929395 Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007
- Use the Import-ExchangeCertificate command to import the new certificate, and Enable-ExchangeCertificate command to enable the new certificate for Exchange services you want to use it with (IIS, SMTP, IMAP, POP, and UM)
- Also recommend reading the team blog post by John Speare: Exchange 2007 lessons learned - generating a certificate with a 3rd party CA
- SAN certificates cost significantly more than regular SSL certificates as of now. Figure out if using multiple regular certificates (may require additional IP address) works out for your deployment.

ISA Server issues

- Forms-Based Authentication: If using ISA (ISA 2006 in my case) to publish Exchange CAS URLs for OWA, disable the Forms-Based Authentication on Exchange's OWA virtual directory, else you'll get two Forms-Based Auth pages and will end up having to authenticate twice - once with ISA, and once with Exchange.
- A useful doc if you're publishing with ISA 2006: Publishing Exchange Server 2007 with ISA Server 2006.
- ISA and SAN Certs: ISA 2004/2006 still have issues with SAN certs, discussed in the ISA team blog: Certificates with Multiple SAN Entries May Break ISA Server Web Publishing.

MX Records - Preference or Priority?

At times I've used the words Preference and Priority interchangeably to describe the numerical value in MX records that determines which record gets used first. Many folks do it, and no, it's not a crime to use either as long as the message gets across.

However, when actually committing words to paper - when writing technical articles, white papers, books, etc., use of the correct technical term is a requirement that cannot be ignored.

RFC 1035 Domain Names - Implementation and Specification says it's PREFERENCE - "A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred".

I will try to stick to Preference when talking about MX records.

Exchange Server 2007 and Address Literals

RFC 2821 allows the use of a literal form of a recipient's address, which uses the destination system's IP address enclosed by square brackets in the domain part, as an alternative to a domain name. Commonly known as address literals, this form of addressing helps in delivery of mail to a recipient when the recipient's domain is facing DNS issues - such as when DNS servers are not available, or domain registration records point to invalid or old DNS server (as may happen temporarily when moving to different DNS servers and old information lives on in DNS caches... ).

In addition to the technical glitches with DNS, there will always be that odd case of human error, when someone responsible in your organization for domain registrations/renewals, and paying the bills, forgets to pay up for renewal. If it can happen to Microsoft (Hotmail lost the domain name hotmail.co.uk, which expired due to non-renewal), it can happen to any of us.

Exchange Server 2003 supports address literals [read previous post "Address Literals and Microsoft Exchange"]. A Recipient Policy rule can be created to generate literal addresses. This allows mail delivery to a recipient, without relying on or using DNS.

The usage scenario: A monitoring system/service like Zenprise, which monitors service availability for email, DNS, etc. detects unavailability of your external DNS servers/zones, or some inconsistency with DNS zones or records. This affects mail delivery to your domain(s) using your normal email address(es) - e.g. foo@yourdomain.com. In such cases, the monitoring system or service can send mail using the address literal - foo@[1.2.3.4] or notify postmaster@[1.2.3.4].

Exchange Server 2007 does not support address literals - you cannot create an AcceptedDomain and EmailAddressPolicy (together these are equivalent of Recipient Policies in Exchange Server 2003/2000) to generate literal addresses, nor does it support manually adding such addresses to a recipient. Microsoft has no plans of reintroducing it.

However, much as one would like to see these supported, Exchange Server 2007 cannot be accused of not being standards-compliant - address literals are neither a requirement, nor a recommendation according to RFC 2821. It allows the use of such addresses.

Exchange Server 2007: Can the quarantine mailbox be an external smtp address?

In Tuesday's Birds of a Feather (BOF) session on Fighting Spam with Exchange Server 2007, someone from the audience wanted to know if an external (smtp) email address can be used as a quarantine mailbox. Exchange does no validation of the email address used for a quarantine mailbox - as long as it's a valid smtp address, it can be used.

However, the results may not be what one's looking for. The quarantined message appears as a NDR. Outlook knows how to treat it correctly using the Send Again functionality, which won't happen if you're forwarding quarantined messages to an external address. The From headers will not be rewritten to identify the original sender of the message.

So yes, it can be done - but what's the point?

Grimes Gripes About RBLs

InfoWorld columnist Roger Grimes gripes about Real-Time Block Lists (aka Real-Time Blackhole Lists, DNSBLs or DNS-based Block Lists. The Exchange Server 2007 term for RBLs is "IP Block List Providers").

The feelings towards RBLs are understandable - you won't be a fan of RBLs if your IP addresses are the ones getting listed, and your users breathing down your neck about bounced messages. It's important to monitor RBLs to determine if your IP addresses are listed in any. (Incidentally, Zenprise for Exchange does this automatically several times a day - configurable by the administrator - and alerts you if any of your IP addresses are listed on RBLs. Your external IP addresses are detected automatically based on messages sent to Zenprise's Zmail hosted service).

Once listed, some RBL providers make the process of getting IP addresses delisted a long and painful one. At times, and in spite of your best efforts and assurances by the provider that the IP address(es) will be delisted, they continue to live on in such lists. On the other end of the spectrum are RBL providers that make the delisting process as simple as entering the listed IP address in a form on their web site, without any checks in place. I would shy away from using the latter.

Regardless, if you are on the other side, as a victim of spam rather than a victim of RBLs, good/reputed RBL providers like Spamhaus (which has its detractors as well - read previous post: "Spamhaus, the E360Insight lawsuit and the future of RBLs"), can help in dramatically reducing spam at the mail gateway - by as much as 90+ percent. This further reduces the stress on mechanisms like content filters (like Intelligent Message Filter or IMF in Exchange Server 2003, and the Content Filter agent in Exchange Server 2007).

Whether you use RBLs to block inbound internet mail from black-listed addresses or not, it makes sense to monitor whether your IP addresses are listed or not on a regular basis.

Read Grimes' column titled "Why I hate RBLs" on InfoWorld.com.

Exchange Server 2007: Logging SMTP Protocol Activity

I wrote about SMTP logging in Exchange Server 2003/2000 in what is one of the most popular posts on Exchangepedia [read previous post - "Logging SMTP protocol activity"]. Exchange Server 2007 has its own SMTP stack, and what I like to think of as smarter or more intelligent Receive Connectors (these are protocol listeners, roughly equivalent or comparable to the SMTP Virtual Server we've known from Exchange Server 2003/2000 - Bharat).

Not enabled by default
I hoped to see (SMTP) protocol logging turned on by default on these connectors, this is one aspect that hasn't changed. Yes, SMTP logging is still not enabled by default! You have to remember to enable SMTP logging on transport servers.

To enable protocol logging on Receive Connectors, use the following command:

Set-ReceiveConnector "Connector Name" -ProtocolLoggingLevel verbose

In case you're wondering if there are any choices for the logging level - there aren't. It's either verbose or none.

To enable protocol logging from the Exchange console, go to Server Configuration | Hub Transport | select the Hub Transport server you want to configure | select the Receive Connector -> properties | General tab | change Protcol logging level to Verbose, as shown in the screenshot below.


Figure 1: Enabling SMTP logging on a Receive Connector

Unlike Exchange Server 2003/2000, you have to enable logging separately for Send Connectors (equivalent of SMTP Connectors), using the following command:

Set-SendConnector "Send Connector Name" -ProtocolLoggingLevel verbose

To do this using the Exchange console, go to Organization Configuration | Hub Transport | Send Connectors tab | select the Send Connector -> properties | General tab | change Protocol logging level to verbose.

Besides the visible Receive and Send connectors, an invisible Send Connector lurks under the hood - used to transport messages within the organization, between Hub Transport servers, Edge Transport servers, and Exchange Server 2003/2000 servers. It's the Intra-Organization Send Connector. You won't see it in the console, or in the shell if you use the get-SendConnector command. To configure protocol logging for this Intra-Organization Send Connector:

Set-TransportServer "TRANSPORT SERVER NAME" -IntraOrgConnectorProtocolLoggingLevel verbose

Where do protocol logs reside?
- Unlike Exchange Server 2003/2000, which maintain separate protocol logs for each instance of a SMTP Virtual Server, all Receive Connectors share "SmtpReceive" logs. Similarly, Send Connectors share "SmtpSend" logs.
- Receive Connector logs are located in
\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive
- Send Connector logs are located in
\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend

How do you change the path of SMTP logs?

To change the path of SmtpReceive logs:

Set-TransportServer "TRANSPORT SERVER NAME" -ReceiveProtocolLogPath "C:\New SmtpReceive Log File Directory"

To change the path of SmtpSend logs:

Set-TransportServer "TRANSPORT SERVER NAME" -SendProtocolLogPath "C:\New SmtpSend Log File Directory"

If you do decide to change the path, ensure the new directories/folders exist with appropriate permissions, as outlined in "How to Configure Protocol Logging" in the product documentation. In addition to the above, you can also control the maximum log file size, the maximum directory size, and the maximum age of log files. This ensures you don't have to worry about purging the logs manually over time, or scheduling a script to do this periodically.

SMTP logs are an important troubleshooting tool - enabling SMTP logging after the fact isn't any help when troubleshooting SMTP mail flow.

Related posts and links:

• Exchange Server 2007: How many logs hath thee?
  
• Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources
  
• Logging SMTP Protocol Activity
  
• SMTP Virtual Servers: Some irksome defaults you should change
  

RFC 2821, HELO again: Validating the HELO/EHLO domain

RFCs 2821 and 1869 specify the format of HELO/EHLO commands issued by a SMTP client to initiate a session.

RFC 2821 on HELO/EHLO command:

4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.

(paragraph snipped here)

In any event, a client MUST issue HELO or EHLO before starting a mail transaction.

These commands, and a "250 OK" reply to one of them, confirm that both the SMTP client and the SMTP server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared.

Syntax:

ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF

The syntax, as the last 2 lines show - depending on whether you're using EHLO or HELO, should be:
HELO foo.somedomain.com
or
EHLO foo.somedomain.com
(followed by a CR LF)

The IIS/Exchange SMTP stack validates this syntax by default. SMTP clients that do not adhere to this syntax - by appending a period or a space at the end of the domain or address literal (IP address) get a 501 5.5.4 Invalid Address error. Exchange Server 2007, which has a brand new SMTP stack of its own, also continues this domain validation, with a slight modification in the verbiage: 501.5.5.4 Invalid domain name.

However, some SMTP clients do format the EHLO/HELO commands with a trailing period/dot or a space. Though not RFC-compliant, many mail systems allow it, including webmail services like Google's Gmail and Microsoft's Hotmail/Live Mail (I wasn't able to test this with Yahoo Mail today...- Bharat).

You can stop IIS/Exchange SMTP servers from checking if the domain in EHLO/HELO is well formatted by changing the value of SmtpDomainValidationFlags metabase property in IIS to a non-zero value. The property does not exist by default, but you can create it using a tool like the Metabase Explorer (in IIS 6 Resource Kit Tools) - it's a DWORD, with an ID of 36992. You can get step-by-step instructions on how to do this in KBA 291828: "501 5.5.4 Invalid Address" error message from a sending UNIX server.

A post in Microsoft's Exchange newsgroups enquired if this was going to open up a security hole in SMTP. Other than allowing domains or address literals not formatted correctly according to SMTP standards, which many SMTP clients and webmail systems allow and probably use - as stated above, I can't imagine this change creating any serious security issues. Having said that, the particular post was in regard to not being able to receive email from Google Alerts. I continue to receive email from Google Alerts without making any changes to the default behavior of SMTP in IIS/Exchange.

However, the IIS/Exchange SMTP stack does domain validation for a reason. One possibility to consider when evaluating whether to turn it off - it's likely that it could allow sessions from spammers that indulge in such behavior.

Exchange Server 2007: How to turn off the Back Pressure feature on transport servers

In reference to previous post titled "Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources", the Back Pressure feature, that detects resource pressure on Exchange Server 2007 transport servers and stops accepting new message submission if low on resources, can be turned off. Here's how to do it:

1. Open the EdgeTransport.exe.config file from \Exchange Server\bin directory using notepad
2. Add the following key+value pair:
<add key="EnableResourceMonitoring" value="false" />
3. Save file
4. Restart Microsoft Exchange Transport Service (MSExchangeTransport)

Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources

In my hotel room in Orlando, getting ready for a presentation tomorrow morning at TechMentor. When trying to telnet to the SMTP port of an Exchange Server 2007 Hub Transport server, I got the following error:

452 4.3.1 Insufficient system resources

Not a good thing the night before a presentation - Murphy's law at work again!

The Application Event Log has Event ID 15002 from MSExchangeTransport saying "The resource pressure is constant at High. Statistics... ". The event goes on to tell you that inbound mail submission has stopped, and it's due to disk space being low on the volume where the queue database is located.

Figure 1: Event ID 15002 logged by MSExchangeTransport

Exchange Server 2007 transport queues are not the familiar .eml files you see in Exchange Server 2003/2000, which reside in the \mailroot\vsi <1>\queue folder (<1> is the instance number of the SMTP virtual server) on the file system. Queues have been moved to a JET database.

What's Back Pressure?
In Exchange Server 2007, the Transport service monitors system resources such as disk space and memory on Transport servers (the Hub Transport and the Edge Transport servers), and stops message submission if it is running low on these resources. It continues to deliver existing messages in the queue. When resource utilization returns to normal, it resumes message submission. The feature is called Back Pressure.

In this case, Exchange required 4 Gigs of free disk space on the volume where the Queue database was located - I had about 3.95 Gigs. :)

Changes to Back Pressure settings in Exchange Server 2007 SP1

The Back Pressure settings in Exchange Server 2007 RTM stop inbound mailflow if free disk space is below 4 Gigs. This static threshold has been lowered in SP1 to a more realistic 500 Mb.

The Resolution
Many configuration options for transport servers are saved in an XML file named EdgeTransport.exe.config (same file name on both Edge and Hub Transport servers) located in \Exchange Server\Bin\. You can edit the file to disable Back Pressure, or modify the parameters to more accurately define what's high utilization for your deployment or server configurations, as explained in the above docs.

Another resolution, and the one I used in this case, was to move the Queue database to another volume with ample of free space, using the following procedure:

1. Add the following key in the <AppSettings> section in EdgeTransport.exe.config:

   <add key="QueueDatabasePath" value="D:\Queue\QueueDB" />

   This is documented in "How to Change the Location of the Queue Database"
   
2. Restart the MSExchangeTransport service, and message submission resumes.

Related Posts:
- Exchange Server 2007: How to turn off the Back Pressure feature on transport servers

Configuring firewalls and name resolution for Edge Transport servers

If you're planning to deploy the Edge Transport server role in a perimeter network (aka "DMZ"), here are the ports you'll need to open:

Inbound:
From external network (internet) to Edge server: SMTP - tcp port 25
From Edge server to Hub Transport servers on internal network: SMTP - tcp port 25

Outbound:
From Edge to external network/internet: SMTP
From Hub servers to Edge: SMTP, LDAP for EdgeSync (tcp 50389), Secure LDAP for EdgeSync (tcp 50636).


Additionally, it's a good idea to open RDP (tcp port 3389) from your internal network to the Edge so it can be managed without KVM/console access.

The ports used for EdgeSync - 50389 and 50636 - can be configured using the ConfigureAdam.ps1 script:

ConfigureAdam.ps1 -ldapport:5000 -sslport:5001

DNS/Name Resolution:
1. since the Edge server is not a member of the AD Domain, it may not have the primary DNS suffix populated by default. Make sure you configure the appropriate DNS suffix on the Edge Transport server - this is done from System Properties | Computer Name tab | Change | More | Primary DNS suffix of this computer. Important: You cannot change the primary DNS suffix of the Edge server after you install the Edge Transport server role.
2. the Edge server should be able to resolve fqdns of Hub Transport servers. This can be done by either using static entries in the HOSTS file on the Edge, or allowing the Edge server to use an internal DNS server. (This would require allowing DNS traffic from Edge servers to internal DNS servers). Alternatively, you could create a DNS zone in the perimeter network that the Edge server can access, and populate it with A records of the Hub Transport servers.
3. the Hub Transport servers should be able to resolve fqdns of the Edge Transport servers. This can be accomplished by adding A records for Edge servers in your internal DNS zone.

A Late New Year's Resolution: Do Not Resolve Anonymous Senders

It's probably a little late to make another New Year's resolution, but I'll try to convince you to make one nevertheless.

By default, when an internal/authenticated user sends you a message, you see the user's display name (e.g. "Joe Adams") in Outlook/OWA, et al. Messages from unauthenticated users, including those from internet senders, show up with their SMTP address - e.g. jadams@somedomain.com. Exchange/Outlook users have been used to seeing this.

You can change SMTP settings to resolve anonymous senders. On Exchange Server 2003: SMTP Virtual Server properties | Access tab | Authentication | check "Resolve anonymous senders". On Exchange 2000, this is done by creating the ResolveP2 registry value described in KBA 288635.

However, not only is resolving anonymous senders a bad idea, it's also a security risk. SMTP, the protocol, allows senders to easily spoof headers. Anonymous senders can send mail to your users, using your CEO's email address for instance, and the message will actually appear as if it was sent by an internal/authenticated sender. A spam message, or one with malicious code - if it gets by anti-spam & anti-virus scanners - buys instant credibility by getting the sender's address resolved to a valid internal sender.

This is one of the reasons I've always wanted Microsoft Outlook to provide an option to show SMTP headers at first look - without the time-wasting, mouse-clicking exercise of selecting a message, right-clicking, selecting Message Options, and viewing what is usually a long message header in a small scrollable text box. It would be great to provide users the option to turn on a "mini" header that shows the actual originating host, and for advanced users - including sysadmins / Exchange administrators who look at headers all day, an option to turn on "full" headers. Sadly, this doesn't exist, even in Outlook 2007. (You could use a little macro that KC posted on her blog a little while ago - and have a button on the Outlook toolbar that shows you the headers with a single click and saves them in a text file.)

What's worse - and I just discovered this, thanks to a newsgroup poster and Exchange MVP Andy David's response - when you check the option to resolve anonymous senders, unauthenticanted senders can now send mail to recipients that have been set to receive email from authenticated users only! That's a big surprise, and totally unexpected - Exchange actually treats anonymous senders as authenticated senders, at least for the purpose of message delivery to such restricted recipients.

Further, not only can someone using a valid internal recipient's email address send mail to such recipients, but even total strangers (addresses that do not resolve to a valid internal recipient, like foo@somedomain.com) can.

I tested this a few times yesterday, and I'm still in disbelief!

Having read KBA 828870: Resolve Anonymous Senders Functionality in Microsoft Exchange 2003 a few times, I don't find any mention of this, though the article clearly recommends that this should not be enabled on any server that receives mail from the internet, and if it is - message from anonymous senders appear as authenticated mail.

KBA 827616: How to restrict the users who can send inbound Internet e-mail to another user or to a distribution group in Exchange 2003 does mention this. It says:

Note If you enable the Resolve anonymous e-mail setting on your front-end SMTP servers, anonymous senders can bypass the From authenticated users only setting.

There may be scenarios where resolving anonymous senders is justified, for instance on internal SMTP virtual servers, where access is controlled or restricted to certain hosts. If you're in a cross-Forest deployment, you should attempt to authenticate the SMTP communication, as stated in KBA 828870 above.

As I said in the beginning of this post, if it's not already too late to make another New Year's resolution, make one today to not resolve anonymous senders on SMTP virtual servers that receive internet mail.

Enabled by default: SMTP Tarpit in Exchange Server 2007

From a recent discussion, and something I've been wanting to post about for a while: SMTP tarpitting is enabled by default on ReceiveConnectors in Exchange Server 2007.

What is tarpitting? It's the process of introducing a delay in SMTP connections from hosts that are suspected of inappropriate SMTP behavior - for instance, by sending messages to non-existent addresses in your domain. (Tarpit is a noun, I use tarpitting as a verb to describe the process. The word probably can't be found in a dictionary, but perhaps appropriate usage to describe the process, just like telnetting, and emailing - Bharat)

If you've used Recipient Filtering on Exchange Server 2003 and selected the option to drop messages for recipients that do not exist in AD, it's a best practice to use SMTP tarpitting to get some level of protection from directory harvesting attacks. Directory harvesting is typically used by spammers to send email to addresses in your domain - which may or may not exist in your directory - to figure out which addresses are valid and which ones are not.

With the option in Recipient Filtering enabled, the SMTP virtual server will respond with a 550 error (550 5.1.1 User unknown) when it comes across an email address in the message's RCPT TO command - before the message body is transmitted. With tarpitting enabled, this response is delayed a few seconds, configurable using a registry setting (in Exchange Server 2003 on Windows Server 2003 SP1 - it is a Windows Server 2003 feature), as described in Microsoft KBA 842851. Most spammers will drop the connection if there's such a delay - it is more expensive for spammers to continue spamming/harvesting with such delays in place.

Does this sound too good to be true? What's the down side? Or are there any? On servers with high volume of SMTP traffic, you may notice more open connections, and open connections consume resources. The trick is to make sure this delay is not too high, resulting in more open connections for much longer, but high enough to make the sending hosts displaying suspicious behavior to drop connections.

Having said that, I've not come across many cases of performance degradation that could specifically be attributed to tarpitting delays, but you'll need to test this in your environment to figure out what works best.

Also note, authenticated connections are not subjected to tarpitting delays. Additionally, tarpitting only makes sense on ReceiveConnectors exposed to internet hosts.

Exchange Server 2007's ReceiveConnectors are configured with a tarpit interval of 5 seconds by default. A good way to observe this behavior is by telnetting to the SMTP port of an Exchange Server 2007 server and first sending a message to a valid recipient, and then trying to send a message to a recipient that does not exist.

To check the SMTP tarpit interval on your ReceiveConnectors, use the following shell command:

get-ReceiveConnector | select name,tarpitinterval

You can set it to a higher value - I have mine set to 10 seconds - using set-ReceiveConnector:

set-ReceiveConnector "Receive Connector Name" -tarpitinterval 00:00:10

The value is in hours:minutes:seconds.

At the time of writing, the documentation for set-ReceiveConnector command says this can be set in days as well (number of days and number of hours separated by a dot), but further it also states the maximum value for tarpitinterval is 10 minutes (00:10:00) - which is confirmed by the shell when you try to set it to a value higher than 10 minutes. (Nevertheless, technically speaking the documentation isn't wrong - you can in fact set it in days - e.g. 00.00:09:00 - as long as the value of days is zero! :) I'm told the doc will soon be changed/corrected).

To disable the tarpit behavior, set the value to 00:00:00.

SMTP Virtual Servers: Some irksome defaults you should change

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.

Related posts and links:

• Exchange Server 2007: How many logs hath thee?
  
• Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources
  
• Logging SMTP Protocol Activity
  
• A Late New Year's Resolution: Do Not Resolve Anonymous Senders
  

Exchange Server 2007: How To Allow Relaying

In Exchange Server 2003, unauthenticated hosts can be allowed to relay by adding their IP address(es) in SMTP Virtual Server properties | Access tab | Relay. This is commonly done for application servers, and devices that need to send mail - like copiers that can scan documents and send by email.


Figure 1: Controlling relay restrictions in Exchange Server 2003

In Exchange Server 2007, SMTP Virtual Servers have been replaced by Receive Connectors, and the SMTP stack is now native to Exchange (unlike Exchange Server 2003, you no longer need to install IIS' SMTP service/stack). Understandably, the way you allow relaying has changed as well.

Do you really need to allow relaying?
Before you setup unauthenticated relaying, it's important to understand the need for relaying. If your application server or devices like copiers need to send mail only to internal recipients - mail for which Exchange has an AcceptedDomain (or a Recipient Policy in Exchange Server 2003/2000) and therefore will receive inbound mail for - it is not considered relaying. The application server or device should be able to do this without any configuration on Exchange.

Recipient Policies and Exchange Server 2007

Exchange Server 2003 Recipient Policies tell Exchange which domains to receive inbound email for, and to generate email addresses. Exchange Server 2007 splits this functionality into AcceptedDomain - which, as the name suggests, tells Exchange which domain(s) to accept inbound email for - and EmailAddressPolicy which actually generates the email addresses. Unlike Exchange Server 2003/2000, there's no RUS to watch AD for new recipients or changes to existing ones. Recipients are provisioned in Exchange - using the console or the shell - and EmailAddressPolicy applied in real-time.

Just like previous versions, Exchange Server 2007 allows authenticated relaying by default. So if your application server or device can authenticate, that's the way to go.

The best way to allow unauthenticated relaying, or certainly the more secure and recommended one, is to create a new Receive Connector. I recommended this approach even on Exchange Server 2003/2000 - it's not a good idea to use your internet-exposed SMTP virtual server to allow unauthenticated relaying, even if restricted by IP addresses.

Scott Landry wrote about this recently on the Exchange team blog in "Allowing application servers to relay off Exchange Server 2007".

To create a new Receive Connector, you need another IP address on your Exchange server. (The other alternative is to create a new Receive Connector that listens on a different port instead of the default SMTP port (TCP port 25). Most app servers and devices don't like this, and many won't let you configure an alternate port for sending smtp mail. I would simply add another IP address to the server. As a sidenote, Exchange Server 2007's Receive Connectors also consider the RemoteIPRanges in addition to the IP address + port combination for binding. More about that in a future post.).

The easy way: With the new IP address added to the Exchange server - let's say it is 192.168.1.17, and your app server, device or copier that needs to relay is 192.168.1.100, fire up Exchange shell and use the following command:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings '192.168.1.17:25' -fqdn server.domain.com -RemoteIPRanges 192.168.1.100 -server MYEXCHANGESERVER -permissiongroups ExchangeServers -AuthMechanism 'TLS, ExternalAuthoritative'

What this does - creates a new Receive Connector called RelayConnector for usage type: custom, binds it on port 25 on IP address 192.168.1.17, gives it the fqdn of server.domain.com, and allows the IP address 192.168.1.100 to connect to it. Additionally - and most importantly, it also assigns ExchangeServers permission group to it, and disables authentication - or rather, it assumes you completely trust the IP address 192.168.1.100 and have another means of authenticating it, such as IPSec.

This also bypasses all security for messages received from that IP address - doesn't apply any anti-spam filters, nor cares about message size limits, resolves P2 headers, and allows sending on behalf of users. Going back to Exchange Server 2003, this is somewhat similar to adding the sending host's address to Connection Filtering's Global Accept list.

A better, more secure way: If you want it to be more secure, you can create a Receive Connector with PermissionGroups set to AnonymousUsers:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings '192.168.1.17:25' -fqdn server.domain.com -RemoteIPRanges 192.168.1.100 -server MYEXCHANGESERVER -permissiongroups AnonymousUsers

Notice, we've left out the AuthMechanism parameter in the above command.

Next, allow anonymous users to relay. This is done by allowing anonymous users the extended right ms-Exch-SMTP-Accept-Any-Recipient for this Connector:

Get-ReceiveConnector RelayConnector | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

For more information about transport permissions, refer to "Exchange Server 2007 Transport Permissions Model" in Exchange Server 2007 documentation. Granular permissions can be assigned to security principals on Receive (and Send) Connectors. For instance, if you want to have these messages bypass the anti-spam filters, you can also assign the ms-Exch-Bypass-Anti-Spam permission.

What's the difference? The difference between the 2 approaches can be seen when you send test messages, as shown in the following screenshot:


Figure 2:The difference between the 2 approaches can be seen in how messages are displayed in email clients

The first message at 9:22 AM is sent by the first Connector, where the message received without authentication actually shows up as sent by me - the P2 headers are resolved. (More about resolving anonymous senders in previous post: " A Late New Year's Resolution: Do Not Resolve Anonymous Senders"). Whereas the second message at 9:34 AM actually shows up with the sender's SMTP address.

The second message also went through the anti-spam filters - a quick check of the message headers reveals the antispam headers.


Figure 3: Messages received using the second method do not bypass anti-spam filters by default

Should MX record point to CNAME records (aliases)?

Though the practice of pointing MX records to CNAME (alias) records is not that uncommon, it certainly isn't in keeping with internet standards.

When you point a MX record to a CNAME, you're in fact inviting double the DNS traffic to your DNS servers. Try this by performing a name resolution query using nslookup:

>nslookup -querytype=MX somedomain.com
somedomain.com MX preference = 5, mail exchanger = mx1.somedomain.com
somedomain.com MX preference = 10, mail exchanger = mx2.somedomain.com
mx2.somedomain.com internet address = 64.31.212.21

As you can see from the above query, the record mx1.somedomain.com is not resolved to an IP address. This is because it's a CNAME.

To resolve the CNAME, the sender's DNS server will have to perform a second query.

Not only is that inefficient, it is in fact explicitly prohibited by RFC 2181.

Section 10.3 of RFC 2181 states:

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

Searching for either NS or MX records causes "additional section processing" in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made.

Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias. Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query.

I've always assumed not pointing MX records to CNAME record(s) is merely a best practice or recommendation, and not a requirement. I stand corrected, as DNS geek (Zenprise seems to have more than its fair share of these :) Dmitri pointed out.

HOW TO: Prevent sending display names with internet messages

Exchange Server and many other MTAs including most web-based services send the sender's display name (e.g. "Joe User") in email messages, in addition to the smtp (email) address. If you want to prevent sending display names in outbound internet mail for any reason, you can turn this off.

Exchange Server 2003/2000 (Exchange System Manager):
- Global Settings | Internet Message Formats | Default -> properties | Advanced tab | uncheck "Preserve Sender's Display Name on messages" [screenshot]

In Exchange Server 2007, Internet Message Formats are replaced by Remote Domains. You can achieve similar result either by using the Exchange Management Console or the Exchange shell:

1) Using Exchange Management Console:
- Organization Configuration | Hub Transport | Remote Domains tab | Default -> Properties | Message Format tab | uncheck "Display senders name on messages" [screenshot]

2) Using the shell:

set-RemoteDomain * -DisplaySenderName:$false

RFC 2821 and the "implicit MX" rule: Can you really get mail without an MX record?

This question has been asked frequently enough, so it makes sense to clarify another SMTP myth that many IT folks hold dear:

No MX records = no email

Yes, mail can indeed be delivered to a domain even if it does not have MX records.

Let's take a look at what RFC 2821 says:
- Once the domain is identified SMTP must perform a DNS lookup and first attempt to locate an MX record.
- If no MX records are found but an A record is found, it is treated as if it was associated with an implicit MX record with a preference of 0 pointing to that host - also known as the "implicit MX" rule.
- Further, if MX records are indeed found but mail delivery to these fails, the "implicit MX" rule to use the A record should not be used and the situation reported as an error, unless one of the the MX records actually points to the host in the A Record.
- Finally, if more than one MX records are found with same preference values, an SMTP sender should rotate between these.

For instance, we try sending a message to foo@somedomain.com, and the domain does not have any MX records, as the following test shows:

Nslookup cannot resolve MX record:

C:\>nslookup -type=mx somedomain.com

somedomain.com
     primary name server = ns1.ispserver.net
     responsible mail addr = dns.ispserver.net
     serial = 2006040700
     refresh = 28800 (8 hours)
     retry = 7200 (2 hours)
     expire = 604800 (7 days)
     default TTL = 86400 (1 day)

However, there’s an A record (same name as the domain, designated as “@”, or the A record that you see as (same as parent folder) in Windows Server DNS management console) that resolves:

C:\>nslookup somedomain.com
Non-authoritative answer:
Name: somedomain.com
Address: 64.40.201.25

If the host that this A record points to accepts SMTP mail on the well-known (tcp) port 25, you can deliver mail to this domain without any MX records.

To create an A record for your domain using Windows Server's DNS management console, leave the (host) Name field blank when creating the new A record, and enter an IP address to map it to.

Nevertheless, not having MX records is not a good practice. Think about the implication it has on your DNS server— the sending host will first try to lookup MX records, and then lookup an A record for your domain. You're inviting extra load to your DNS server(s) by not having MX records.

MX records also allow you to route inbound mail to more than 1 hosts using the preference value to load-balance or failover.

Microsoft opens up SenderID

Microsoft announced today it's putting its SenderID technology under its Open Specification Promise program. This allows anyone to create products or services using SenderID technology. SenderID lets (receiving) mail servers determine whether a sending mail host is authorized to send email for a particular domain, based on SPF records published in the sending domain's DNS.

SenderID has been around for 2 years, and is used by about 5 million domains according to Microsoft. It is a good anti-phishing defense, and also another component in a multi-layered approach to fighting spam.

CNET has more.

Exchange Server 2007: Message Tracking from the command line

I've forever envied folks (including some colleagues— you know who you are... ) on the Linux/Unix side of things who were able to parse text log files generated by MTAs like Postfix/SendMail/EXIM in a fraction of the time it takes one to fire up Message Tracking Center on Exchange and search for a message. I tried for a while to put together some scripts that could do something as cool as those guys, but it was nowhere as close.

Thankfully, Exchange Server 2007 and its Exchange shell bring an end to that Linux/Unix-MTA envy (yes, I am indeed talking about the Exchange Management Shell.... I'll just call it Exchange shell, and you can probably tell hom much in love I am with the naming conventions... Powershell=cool name for new Windows shell, Exchange Management Shell=not even close! ).

Message tracking using the shell is easy. (Yes, it is a shell, and.... Yes, you'll need to remember a syntax. No, you may not always remember it. No, you don't need to remember every single option... Yes, there's help! Get over it. Or use the GUI - more about that in a little bit.)

The shell command: Get-MessageTrackingLog

Avoid typing too much: Using aliases for commands
Yes, that's a long command to type in every time. Luckily, the shell has tab completion which allows you to type a partial command and have the shell complete the rest. In case of multiple matches, you can continue to hit tab and cycle through all the matches till you find the one you want.

Windows Powershell, and therefore the Exchange shell, allow you to create your own preferred aliases for commands. I use the alias track for Get-MessageTrackingLog. To create an alias:

New-Alias track Get-MessageTrackingLog

Now you can simply use track blah.

What can you do with it? A lot.

Message Tracking log fields
First, let's take a look at a typical record in the tracking log. A single message generates multiple records in the log, one for each event. Familiarity with the fields and the kind of information they contain will help you filter and find what you're looking for. If you frequently use message tracking for troubleshooting or otherwise, this familiarity can be rewarding.

Timestamp : 9/30/2008 12:03:46 PM
ClientIp : 192.168.2.10
ClientHostname : myserver
ServerIp : 100.1.2.3
ServerHostname : mail2.somedomain.com
SourceContext : 08CAEC7BADA2C89C
ConnectorId : Default
Source : SMTP
EventId : SEND
InternalMessageId : 566
MessageId : <8ae81f81e2d0bc45b53db7d1661e75b801a4e86bc6d2@myserver.mydomain.com>
Recipients : {foo@somedomain.com}
RecipientStatus : {250 2.1.5 foo@somedomain.com }
TotalBytes : 21097
RecipientCount : 1
RelatedRecipientAddress :
Reference :
MessageSubject : RE: Your request for more information
Sender : me@mydomain.com
ReturnPath : me@mydomain.com
MessageInfo : 9/30/2008 12:03:38 PM

Filtering Message Tracking Logs
You can filter Message Tracking logs by the following parameters:

1. Start and End times: By default, Message Tracking logs are kept for a maximum of 30 days. If you're trying to find a message that may have been sent or received in the last day or two, or a specific period, it's inefficient to search 30 days worth of logs. It's a good idea to narrow down the search by specifying a start time, and preferably the end time as well.
   
2. Event ID: This is by far one of the more important parameters of Message Tracking logs that we need to understand. Whereas Exchange Server 2003/2000's Message Tracking log was an easy-to-use application that shielded the user from this complexity, it also provided much less flexibility. Message Tracking logs have a lot of details about a message as it originates from an internal user or external sender, and makes its way through the different stages of message routing and transfer, and finally gets delivered (or not). You can now track messages based on these events.
   
3. Sender: Sender's SMTP address
   
4. Recipients: SMTP address(es) of one or more recipients
   
5. MessageSubject: The subject field in the message header
   
6. MessageID: This is the MessageID in the header. It is constant for the lifetime of a message, and can be used to track messages across different mail systems.
   
7. InternalMessageID: an integer field assigned by the Exchange 2007 server that is currently processing the message. The same message will have a different InternalMessageID on different Exchange servers.

Here's a list of some of these EventIDs:

EventID	Description
DEFER	Message delivery delayed
DELIVER	Message delivered to a mailbox
DSN	A delivery status notification was generated. Messages quarantined by the Content Filter are also delivered as DSNs. the recipients field has the SMTP address of the quarantine mailbox.
EXPAND	Distribution Group expanded. The RelatedRecipientAddress field has the SMTP address of the Distribution Group.
FAIL	Delivery failed. The RecipientStatus field has more information about the failure, including the SMTP response code. You should also look at the Source and Recipients fields when inspecting messages with this event.
POISONMESSAGE	Message added to or removed from the poison queue
RECEIVE	Message received. The Source field is STOREDRIVER for messages submitted by Store Driver (from a Mailbox server), or SMTP for messages a) received from another Hub/Edge b) received from an external (non-Exchange) host using SMTP c) submitted by SMTP clients such as POP/IMAP users.
REDIRECT	Message redirected to alternate recipient
RESOLVE	Generally seen when a message is received on a proxy address and resolved to the default email address. The RelatedRecipientAddress field has the proxy address the message was sent to. The recipients field has the default address it was resolved (and delivered) to.
SEND	Message sent by SMTP. The ServerIP and ServerHostName parameters have the IP address and hostname of the SMTP server.
SUBMIT	The Microsoft Exchange Mail Submission service on a Mailbox server successfully notified a Hub Transport server that a message is awaiting submission (to the Hub). These are the events you'll see on a Mailbox server. The SourceContext property provides the MDB Guid, Mailbox Guid, Event sequence number, Message class, Creation timestamp, and Client type. Client type can be User (Outlook MAPI), RPCHTTP (Outlook Anwhere), OWA, EWS, EAS, Assistants, Transport.
TRANSFER	Message forked because of content conversion, recipient limits, or transport agents

Finding messages
Find messages by sender:

Get-MessageTrackingLog -sender "foo@somedomain.com"

Messages received or messages delivered to the mailbox: You can further separate or constrain these by message received:

Get-MessageTrackingLog -sender "foo@somedomain.com" -eventID RECEIVE

and messages delivered to the mailbox

Get-MessageTrackingLog -sender "foo@somedomain.com" -eventID DELIVER

Start and End date/time: To further constrain these by Start and End times:

Get-MessageTrackingLog -sender "foo@somedomain.com" -eventID DELIVER -Start "10/01/2006 9:00AM" -End "10/03/2006 5:00PM"

Formatting output
To show only selected fields, you can pipe the output to the Select-Object command, and specify the fields required. Here we want the timestamp, recipients, and subject fields:

Get-MessageTrackingLog -sender "foo@somedomain.com" -eventID DELIVER -Start "10/01/2006 9:00AM" -End "10/03/2006 5:00PM" | Select timestamp,recipients,messagesubject

To get all fields from a message in a list format, you can pipe the output into a fl (format list).

By default, the Get-MessageTrackingLog command returns up to 1000 results. This can be hard to work with in a command screen that keeps scrolling endlessly. In addition to the above parameters used to filter the logs, you can also restrict the number of results returned using the ResultSize parameter.

Get-MessageTrackingLog -sender "foo@somedomain.com" -eventID DELIVER -Start "10/01/2006 9:00AM" -End "10/03/2006 5:00PM" -ResultSize 25

Very cool!

Combine the above with the out-html | out-ie scripts/commandlets that I blogged about earlier (read previous post "More about the out-html | out-ie functionality"), and you have a nifty little message tracking report displayed in a browser. One step further, there's an out-email script that can be used to directly email the tracking results to a sender/recipient.

Having said that, yes, there's a Message Tracking GUI as well under Tools | Message Tracking in the Exchange console. I know it's a pre-release version, but all I can say is it's not something you'll fall in love with. (Although not a pre-release version any more, the remainder of the previous statement is still true). I would even go as far as to say I liked the old one better. It needed some tweaks but it worked for a lot of folks.

Message tracking using the Exchange shell is much faster than using the Message Tracking tool in the Exchange console, and chances are it will help you get rid of the Sendmail/Postfix-envy.

Related posts and links:

• How to Configure Message Tracking
  
• How to Search Message Tracking Logs
  
• Exchange Server 2007: How many logs hath thee?
  
• Exchange Server 2007: Setting Message Size Limits
  
• Are Distribution Groups really being used?
  

Logging SMTP protocol activity

Like many of my posts, this one also starts with "By default,... ". Like many folks, I'm always curious about the defaults used for almost everything in Exchange/SMTP (and IIS, Windows, AD et al), and at times intrigued by the choices made.

One of my pet peeves has been about how installing Exchange changes the maximum number of recipients on the SMTP virtual server from the 100 set by SMTP service sans Exchange, to a mind-boggling 64,000 recipients after our favorite mail server modifies the SMTP stack. There's plenty of fodder there for yet another blog post— a quite lengthy one if I have the time. :)

This one's about logging SMTP protocol activity, which isn't enabled by default. Yes, SMTP logging is disabled by default! Unfortunately, many administrators only find out about this *after* they start troubleshooting an SMTP-related issue. Of course, it's too late by then!

You can enable SMTP logging (also referred to as "protocol logging" or "SMTP protocol logging" by some) from SMTP Virtual Server | properties | General tab.


Figure 1: Enabling SMTP logging in SMTP Virtual Server properties | General tab

SMTP Log Formats
With the decision to enable SMTP logging made, you are faced with a choice of logging formats. Exchange 2003/2000 rely on IIS to provide protocol support. It's IIS doing the logging. It should be no surprise that the log file formats available and fields logged are designed for web servers:

1. W3C Extended log file format: The default logging format for SMTP and other IIS services. It includes some fields that are only relevant to Web and FTP services. This is the only format that's customizable - it allows you to select the fields you want to log.
   
2. NCSA Common log file format: Based on the NCSA httpd, widely accepted as a standard amongst web server vendors at some point, this format only logs basic access information. You cannot select the fields to log.
   
3. Microsoft IIS log format: Another fixed field format, it does log more information that the NCSA Common format. The time logged is local time.
   
4. ODBC Logging: Used to log to an ODBC-compliant database. Although it's possible to log directly to a database, rarely have I come across a deployment where this was required or used. Notably, it degrades performance.

For more details about log file formats, see IIS Log File Formats.

At this point, it should be clear which log file format is a good fit for logging SMTP activity. It's the only format that is, well, extended! (The rest only log certain fixed fields). It lets you select the fields that will help you troubleshoot SMTP. If you chose the W3C Extended Log File Format, pat yourself on the back for making a great choice!

SMTP Log Fields
You can select the fields the W3C format will log. By default it logs only 4 fields: Time (no date), c-ip (Client IP Address), cs-method (Method):, cs-uri-stem (Uri Stem) (which doesn't log anything , afaik), and sc-status (Protocol Status).
The above fields provide very basic and at times completely inadequate information for troubleshooting, particularly in higher volume environments.


Figure 2: When enabling SMTP logging, make sure the fields useful for troubleshooting are actually being logged.

The following fields should be logged:

1. Date
   
2. Time
   
3. c-ip (Client IP Address)
   
4. cs-username (User Name): The fqdn provided by sending server on HELO
   
5. s-sitename: SMTP virtual server instance name (e.g. SMTPSVC2)
   
6. s-computername (Server Name): Name of server, useful if aggregating logs from multiple servers into a monitoring/logging database
   
7. s-ip (Server IP Address): This is useful if the Exchange server has multiple IP addresses, or when aggregating logs from multiple servers to a database or spreadsheet
   
8. cs-method (Method): SMTP command e.g. HELO, MAIL, RCPT, DATA, QUIT
   
9. cs-uri-query (URI Query): The command parameter (like +from:foo@foo.com. This logs the from and to addresses, sending server fqdn given at HELO, and Message ID. (Note: Nothing between the DATA and end of data sequence is logged)
   
10. sc-status (Protocol Status): SMTP protocol response like 220, 250, 500,
    et al
    
11. sc-win32-status (Win32 Status): a numerical value, 0 if successful.


Optional: These are occasionally useful when troubleshooting performance problems

12. sc-bytes (Bytes Sent): if you really need this info - handy at times for troubleshooting
    
13. cs-bytes (Bytes Received): if you really need this info - handy at times for troubleshooting
    
14. time-taken (Time Taken): if you really need this info, handy at times for troubleshooting performance


15. s-port (Server Port): This is always logged as 0 afaik, even if the SMTP Virtual Server is listening on a port other than 25
.

Rolling over SMTP logs
Rolling over logs on a daily basis seems like a good choice. Smaller or low-volume environments can roll over weekly, monthly, or when the file reaches a certain size. The unlimited file size option means the log will never roll over - not recommended.

The option to use local time for file naming and rollover exists - the timestamps in the logs will always use UTC (if you've gone through the whole Daylight Savings Time issue earlier this year you probably understand very clearly why using UTC timestams in log files makes sense :).

Location of SMTP logs: By default, SMTP logs are located in %systemroot%\system32\LogFiles, in folders created for each SMTP virtual server instance - e.g. SmtpSvc1 for the default/first SMTP virtual server instance.

Starting logging is the first step, and brings with it some additional decisions to make and procedures to follow. It's a good idea to ask yourself why you're logging the information, how long does it remain valuable for that purpose, when will you remove old log files (and if any compliance policies in your organization require you to archive logs for a particular period of time).

Related posts and links:

• Exchange Server 2007: Logging SMTP Protocol Activity
  
• SMTP Virtual Servers: Some irksome defaults you should change
  

Address Literals and Microsoft Exchange

RFC 2821 specifies how address literals can be used to reach recipients - particularly useful when DNS resolution doesn't work for a particular domain or host. This is a literal form of the address which can be used as an alternative to the domain name. For IPv4 addresses, the address literal format is localpart@[1.2.3.4] - where 1.2.3.4 is the IP address of the host.

Exchange Server 2003 allows usage of address literals in Recipient Policy. You can create a Recipient Policy rule and insert the IP address (of your Exchange server) enclosed in square brackets e.g. "@[1.2.3.4]" to use the alias, or "%1g.%s@[1.2.3.4]" to use first initial and last name (depending upon the naming convention for primary email addresses).

Not all recipients need to be reachable using address literals, though it certainly doesn't hurt if they are. (It may get a tad too complicated in anything but single server environments... ). It's a good idea to have at least the common accounts used to report email problems - like postmaster (an RFC requirement), abuse, et al reachable.

If you create a Recipient Policy that doesn't apply to any users, you can then add one-off email addresses to accounts like postmaster. The Recipient Policy tells Exchange it needs to receive email for a certain domain and whether it is authoritative for that domain. (Yes, the literal IPv4 addresses get treated like domains by Exchange.)

If you decide to take this route, you will need to add the individual email addresses to user accounts using ADSIEdit - the Email Addresses tab in AD Users & Computers console does not let you add email addresses with square brackets.

If your servers are behind a NAT router/firewall, it makes sense to add both the internal and external (NATted) IP address of the host to the Recipient Policy.

IMF: Gateway thresholds per server

So far we've known that Exchange Server 2003's content filter - the Intelligent Message Filter (IMF), uses Gateway and Store thresholds and (Gateway) action that are configured once in Global Settings | Message Delivery | properties | Intelligent Message Filtering. These global settings apply to all SMTP Virtual Servers on all Exchange Servers in the Org that have IMF enabled.


Figure 1: Configuring Intelligent Message Filter's Gateway and Store thresholds for the entire Organization

Evan Dodds reveals the ability to configure per-server Gateway threshold and action for IMF in "Configure IMF gateway settings per server".

To enable the per-server Gateway thresholds, two registry values need to be created as follows:
Registry Key: HKLM\Software\Microsoft\Exchange\ContentFilter



Value: GatewayThreshold
Value type: REG_DWORD
Value data: 0-9

Value: GatewayAction
Value type: REG_DWORD
Value Data:
0x0 = No Action
0x1 = Delete
0x2 = Reject
0x5 = Archive

The above method allows you to control the Gateway threshold and action per server. You cannot control the Store threshold per server.

So the answer is, yes, it's possible using this undocumented registry hack, and Evan also suggests when one may need to use it.

Disabling NDRs

RFC 2821 requires a SMTP host to send non-delivery report if a message is accepted but cannot be delivered, and the reverse path is *not null*. Nevertheless, under certain circumstances it may be desirable to disable NDRs (entirely or for a particular domain).

In Exchange Server 2007, this can be done from the shell:

set-RemoteDomain * -DeliveryReportEnabled:$false

The above command disables NDRs for the * address space, which translates to all non-local domains that Exchange does not have an explicit path to.

From the console EMC:
Organization Configuration -> Hub Transport -> Remote Domain -> select domain -> properties -> Message Format tab -> uncheck Allow non-delivery reports

To disable NDRs for specific domains, create new Remote Domain (or select an existing Remote Domain), and configure it as above. Replace * in the shell command with the domain name you want to configure.

This is one of those tasks that lend themselves better to the shell. :)

Windows Vista and telnet

Fired up the console (command prompt) in Windows Vista and can't telnet to smtp or use telnet at all for that matter? Just noticed this on Windows Vista RC1 - Telnet is not installed by default... and the HyperTerminal app is history as well.

To add Telnet, go to Control Panel -> Programs -> Turn Windows features on or off and check Telnet Client.

Telling Exchange about (non-Exchange) SMTP servers

For anti-spam agents like IP Block List providers (aka DNSBLs/RBLs), and Sender ID, it is important to know about which non-Exchange SMTP servers receive inbound internet mail. This allows it to ignore the SMTP servers that belong to your organization when parsing headers (in topologies where the Edge server - or the Hub Transport server if you don't have an Edge server - sit behind other SMTP relay hosts).

In Exchange Server 2003, this can be done using Exchange System Manager by going to Global Settings | Message Delivery | Properties | General tab | Perimeter IP List and Internal IP Range Configuration | Add.

In Exchange Server 2007, this is done using the Set-TransportConfig commandlet:

Set-TransportConfig -InternalSMTPServers x.x.x.x,y.y.y.y,z.z.z.z

Related Posts:

- Exchange Server 2007: Making SenderID work with non-Exchange smtp hosts

HELO RFC 2821: Telnetting to Gmail's SMTP servers

Telnetting to SMTP port of a mail server is a common troubleshooting task to test SMTP connectivity and mail flow that most of us do ever so frequently. After the initial HELO/EHLO command, you issue a MAIL FROM command that provides a return path to the receiving server - generally the SMTP address of the sender e.g. foo@somedomain.com

With most servers, MAIL FROM:foo@somedomain.com works.

Today I was testing some X-header functionality with Google's Gmail service, after having performed similar tests against Exchange Server 2007 (Beta 2), Exchange 2003, and Hotmail. However, when I issued the MAIL FROM command when testing with Gmail, it threw up a syntax error! I use this almost several times a day, and never have I seen a syntax error being thrown up on MAIL FROM or RCPT TO.

Out of curiosity, I decided to lookup RFC 2821 to figure out if there was something I wasn't doing right or that Gmail was enforcing in its zeal to be strictly RFC-compliant. As it turns out, the RFC does require addresses to be enclosed in "<" and ">" brackets!

Specifically:

The first step in the procedure is the MAIL command.

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors...

I've never come across this particular issue with almost any MTA that I remember testing against... entering the addresses with those brackets seemed to work.

Exchange Server 2007: Internet email without Edge servers

The Edge Transport server role is not a required role. It's good to have if you don't want to expose your domain-joined Exchange servers to the internet, and the high amount of spam that mail gateways receive and filter. Nevertheless, many small environments— typically those with a single Exchange server, do not have that luxury.

In such environments, you can use a Hub Transport server to send/receive internet mail.


Default Receive Connectors
The default installation of a Hub Transport server creates two Receive Connectors:
1) Default Receive Connector: listens on SMTP port 25
2) Client receive connector: intended for remote clients to submit mail - this listens on port 587.

The Default Receive Connector only accepts mails from authenticated senders/hosts. It is configured to accept mail from Mailbox Servers, other Hub Transport servers, and Edge Transport servers.

To allow it accept inbound internet mail in an environment without an Edge Transport server, you need to configure it to accept mail from anonymous senders. Here's how you can do this from the Exchange shell:

set-ReceiveConnector -identity "Name of Default Connector" -PermissionGroups AnonymousUsers

Test the configuration by telnetting to the SMTP port of the server and sending a message.

Additional Steps:
- Make sure one or more Accepted Domains exist for domain(s) you've registered with a domain registrar
- Create an Email Address Policy (or modify an existing one) to generate email addresses for your recipients using the domain(s)
- Firewall: Most commercial firewalls require 2 configuration changes. 1) A rule that maps the internal IP address of the server to an external IP address reachable from the Internet. 2) An "access" rule that allows inbound SMTP traffic (tcp port 25) to the server
- DNS: 1) Ensure the DNS zone(s) for these domains can be reached from the internet. Many domain registrars now provide free DNS hosting with a domain registration, and allow you to make changes using a web browser. 2)Create an A record: Create an A record that resolves to the external/NATted IP address 3) Create an MX record that points to the A record.

Antispam
- By default, Hub Transport servers do not have anti-spam agents installed. Read related post "HOW TO: Install anti-spam agents on Hub Transport server".

IMF: Archiving spam

As explained in previous posts, the Intelligent Message Filter (IMF) offers a few configuration options. The primary interface for configuring IMF is under Global Settings | Message Delivery properties | Intelligent Message Filtering tab.


Figure 1: IMF configuration options in Global Settings | Message Delivery | Properties | Intelligent Message Filtering tab

Here you specify a Gateway Blocking Configuration by telling Exchange what the Gateway SCL threshold is, and selecting an action to be taken when the threshold is met or exceeded. IMF assigns each message scanned a rating called "Spam Confidence Level" or SCL. Messages with SCL values that meet or exceed the Gateway threshold can be blocked from users' mailboxes.

One of the following actions can be selected to treat such messages:

•  Do Nothing: This simply forwards the message to the Store, and depending on the Store configuration, typically the messages should end up in a user's Junk Mail folder. Important consideration: the Store threshold should be *lower* than the gateway threshold.
  
•  Reject: Exchange rejects the message during the SMTP session. The sending server is responsible for generating any Non-Delivery Report (NDR) to the sender.
  
•  Delete: Exchange accepts the message and deletes it, without notifying the sending host and without generating a NDR. This is also referred to as silent delete.
  
•  Archive: When the Archive action is selected, Exchange delivers the message in the UCEArchive folder.

Some considerations and FAQs about archiving messages - most of these are documented in the IMF v2 Deployment Guide:

1. Where are the messages archived?
Messages are archived in the UCEArchive folder. By default this folder is created in \exchsrvr\mailroot\vsi 1 folder - where 1 is the instance number of SMTP virtual server.

2. Is there a way to change the location of the UCEArchive folder?
Yes, this is done by inserting a registry value of type String (REG_SZ) in the following location:
HKLM\Software\Microsoft\Exchange\ContentFilter
Value: ArchiveDir
Type: REG_SZ (string)
Value data: path to archive folder

3. I set the action to Archive. Why don't I see the UCEArchive folder in the default location?
The UCEArchive folder is created when the first message meeting or exceeding the gateway threshold is received.

Things to check when you don't see the UCEArchive folder:
- Is the action set to Archive?
- Is IMF enabled on SMTP virtual server?
Read the earlier post on changes to IMF v2 introduced in Exchange Server 2003 Service Pack 2 "Exchange Server 2003 SP2 and IMF"
- Is IMF working? (Check performance counters)
Read the earlier post "Troubleshooting IMF: Important Performance Counter" for more info.
- Are you receiving any messages meeting or exceeding the gateway threshold?
Check performance counters (again!) - MSExchange Intelligent Message Filter\Total Messages Assigned an SCL Rating of (number) - where number is the SCL rating. Counters are available for SCLs 0-9.
- Is the archive folder location modified using the above registry value?

4. I see a bunch of files with .eml extension in the UCEArchive folders. How do I view them?
You can open these .eml files with Outlook Express or using Notepad.

5. Managing archive files using the above method (opening each .eml file in Outlook Express or using Notepad) isn't very efficient. Is there a better way?
There's a popular third-party tool called IMF Archive Manager that makes managing the archived messages easier. You can download it for free from gotdotnet.com.

6. I don't have the time or inclination to sort through so many archived messages. Should I just set it to delete or reject?
If you're just starting out with IMF, I would recommend archiving initially. This will allow you to review the archive folder to see if there are any false positives - messages that are not spam, but got a higher SCL rating for some reason. Archiving will also allow you to finetune your IMF configuration based on the number of false positives you get using the gateway SCL threshold you use. Once you are comfortable with what you see in the archived messages, you can choose to reject or delete messages if you want.

7. I don't see the SCL rating anywhere in the archived messages. Is there a way to save the SCL with the messages?
Yes, by adding the following registry value, IMF can be configured to save the SCL assigned to archived messages. Exchange inserts the X-SCL x-header.
Location: HKLM\Software\Microsoft\Exchange\ContentFilter
Value: ArchiveSCL
Type: DWORD
Value data: 1

IMF does not scan messages larger than 3 Mb

Microsoft has just released a knowledgebase article - KB 907691 - documenting the inability of its Intelligent Message Filter (IMF) - the anti-spam filter that was earlier offered as a free add-on for Exchange Server 2003 - to scan messages over 3 Mb. in size.

When IMF encounters a message that is larger than 3 Mb., it logs the following event in the Application Event Log:

Event ID: 7515
Category: SMTP Protocol
Source: MSExchangeTransport
Type: Error Message : An error occurred while Microsoft Exchange Intelligent Message Filter attempted to filter a message with ID <ID_Number>, Priority_Number From smtp:E-mail_ID and Subject Subject_Text. This message will not be filtered. The error code is 0x800710f0.

(In some of my tests IMF has behaved differently when scanning these large (over 3 Mb.) messages with and without attachments. I haven't been able to complete testing to come to any conclusion because of lack of time - will update this post if I find something - Bharat)

IMF became part of Exchange Server 2003 when Microsoft included it in Exchange Server 2003 Service Pack 2. The inability to scan messages over 3 Mb. in size is common to both IMF v1 and the new version 2 included with SP2.

The article states this is by design - typical spam messages are not as large, and it costs more to send such spam.

It'll be interesting to find out what Exchange administrators think about this!

IMF: How to exclude recipients from IMF filtering

Microsoft recently released a hotfix for Intelligent Message Filter that adds functionality to exclude certain recipients from IMF filtering using an exclusive list, or only apply IMF to certain users using an inclusive list. The latter should be great for limited testing in a production environment.

You do need to call Microsoft PSS to get the hotfix mentioned in KBA 912587. This updates MSGFILTER.DLL to version 6.5.7650.22.

With the hotfix applied, you need to fire up regedit and
- create a new key called ContentFilter in HKLM\Software\Microsoft\Exchange.
- create a new DWORD value called CheckRecipients
- if you want to use an exclusive list - which means messages IMF will bypass (not scan) the message if ALL recipients in the message are on the list, modify CheckRecipients DWORD value you just created and type 2 in Value data
- Create a new Multi-String value called RecipList - and add names of recipients you want to exclude from IMF filtering.

Again, the emphasis is on all recipients - if there's a single recipient of a message not on the exclusion list, it will get scanned by IMF.

To do the opposite - create an inclusive list - change the value of CheckRecipients to 1, and add names of recipients who would like to get their messages filtered by IMF to the RecipList value.

It is not required to restart the server after you apply this hotfix.

Note: Calling PSS for required hotfixes that resolve particular issues is free. Just have the KBA number handy!

IMF Confusion - Store threshold rating text in UI

A major source of confusion regarding the Store threshold value used by Intelligent Message Filter (IMF) is the IMF UI itself. This is documented in Intelligent Message Filter release notes.


Figure 1: The text for the Store SCL incorrectly states that messages with SCL greater than or equal to the Store threshold will be moved to Junk Mail

What it says: In ESM | Global Settings | Message Delivery | properties | Intelligent Message Filtering tab, the Store Junk E-mail Configuration section reads Move messages with an SCL rating greater than or equal to. If you never read the Release Notes - and I know many of us don't, particularly in smaller environments where IMF is more popular - you follow what the UI says and assume setting a store SCL fo 6 would makes messages with a SCL of 6 or higherto be moved to the Junk Mail folder.

What it does: The Release Notes clarify this - the UI should say "Move messages with an SCL rating greater than". Only messages with a higher SCL than that value are moved to Junk Mail.

Apparently, Exchange Server 2003 SP2 did not fix this either and SP2 Release Notes make no mention of this. For many Exchange environments that did not use IMF v1 - a separate download - SP2 is their first encounter with IMF.

Related Posts:
- TechEd 2007: Notes from the BOF Session on Fighting Spam With Exchange Server 2007
- Exchange Server 2003 SP2 and IMF
- Troubleshooting IMF: Important performance counter
- IMF: Archiving spam
- IMF: Where's the whitelist?
- IMF does not scan messages larger than 3 Mb
- IMF: Updates not showing up in Add/Remove Programs?
- Intelligent Message Filter (IMF) v1 download removed from microsoft.com
- Update: Manually removing IMF v1
- IMF: How to exclude recipients from IMF filtering
- IMF: Gateway thresholds per server

Troubleshooting IMF: Important performance counter

Earlier today I saw some strange behavior with Intelligent Message Filter (IMF) v2. Incoming internet mail wasn't getting scanned by IMF. Outlook did not show the SCL values for any message!

That in itself wasn't the strange part. I'm positive I have the right gateway and store thresholds, and I have IMF enabled on the SMTP Virtual Server - I double-checked that as soon as I saw the issue.

Next stop - check IMF performance counters. A word about monitoring SMTP (and IMF in particular) with Perfmon— the default view is a graph, and if you're dealing with a server that doesn't get much traffic (the server in question being my primary Exchange server on the home network - it doesn't get hundreds of messages on a Sunday night), switching to the Report view and looking at the numbers makes it much easier to detect any activity. This could potentially save a lot of time, as it often does for me.

I quickly added the following counters of MSExchange Intelligent Message Filter object:

• 1. Total Messages Scanned for UCE
  
• 2. Messages Scanned for UCE/sec
  
• 3. %UCE of Total Messages Scanned
  
• 4. %UCE of Messages Scanned in the previous 30 minutes

Also added the following from SMTP Server object:

• 1. Messages Received Total
  
• 2. Messages Received/sec

With the Report view fired up, I started sending messages - some with all the characteristics of UCE, and some simple test messages. Here's where the strange behavior comes in - the SMTP Messages Received counters were rising, and surprisingly so were Total Messages Scanned for UCE. However, Outlook still didn't show any SCL values and all the obvious spam was still hitting my Inbox!

Here's where another important IMF counter comes in - Total UCE Messages Acted Upon (and its sibling - UCE Messages Acted Upon/sec). Once these were added to the Perfmon console, I spent a few minutes sending some more messages. The UCE Messages Acted Upon counters did not move at all, whereas Total Messages Scanned was inching higher.

IMF was scanning, but not acting on those messages!

Next stop (and don't ask me why this wasn't the first thing I checked :) - Event Logs. The familiar Event ID 7514 that I was trying to reproduce for another test earlier in the day showed up in the Application Event Log! This is an error logged by MSExchangeTransport. Description: An error occurred while loading Microsoft Exchange Intelligent Message Filter. The error code is 0x80004005.

The error was caused by saving the MSExchange.UceContentFilter.xml file as text. This file is used by the new Custom Weighting feature introduced with IMF v2 in SP2. The file needs to be saved with encoding set to Unicode.


Figure 1: The Custom Weighting file MSExchangeUceContentFilter.xml should be saved in Unicode format

Opened file in notepad, changed to Unicode and saved. Restarted SMTPSvc. I sent some more test messages - now I could instantly see the messages acted upon counter rising. Spam started showing up in the Junk Mail folder and Outlook started showing the SCL values, as expected.

Creating an additional SMTP Virtual Server in a EVS

Creating an additional SMTP Virtual Server in a non-clustered environment is pretty straightforward. The same task is a little more complicated in a clustered environment.

Before you begin:
Need to consider whether you want the new SMTP VS to listen on the same IP address but on a different port or listen on the default SMTP port on a new IP address. Most likely you'll end up choosing the later, but the former choice may be perfectly valid for certain requirements like setting up an authenticated SMTP VS (not referred to in a MX record).

Click here to see the Flash movie

Creating a new IP Address Resource
(you can skip this step if you're going to use the same IP address as the Default SMTP VS, but with a different port)

If you decide to create a new IP address, do that in Cluster Administrator.
1. In Cluster Administrator, select the group your Exchange Virtual Server (EVS) resides in (we'll call it "Exchange Group").
2. Right-click the group New Resources
3. In the new resource dialog box type in the Name (optional: type in description), select IP Address as the Resource Type
4. In the Dependencies dialog box, do not select any resource as a dependency.
5. In TCP/IP Address Parameters type the IP address, subnet mask, and the network on which you want to create this resource on (the public network where users can access it, let's call it "Public" here)
6. Click Finish. Do not bring the resource online yet.

To make this IP address visible in ESM when creating an additional SMTP VS, you will need to make the Network Name resource for your EVS dependent on this IP Address. If you do not do this, it will not show up as a choice and your new SMTP VS will be forced to bind to the EVS IP address which has the default SMTP VS bound as well, creating a conflict.

Note: The following step will take your Exchange Virtual Server offline. Users will not be able to access the EVS till you bring it back online.
7. Right click on the Exchange Group Take Offline.
8. Locate the Network Name resource for the EVS Properties Dependencies tab click Modify
9. In Modify Dependencies, select the IP Address 2 and click the right arrow (-->) to add it as a dependency for the Network Name
10. Click OK to exit.
11. Right-click the Exchange group Bring Online.

Now we're ready to create the SMTP Virtual Server.
1. Open Exchange System Manager console and locate your server (EVS)
2. Expand Protocols SMTP
3. Right-click SMTP New SMTP Virtual Server
4. In the New SMTP Virtual Server wizard, type in a name for the new VS click next
5. Select the new IP address you created earlier (should be selected by default)
6. Click Finish. The new SMTP VS instance is created.
Note the SMTP VS icon looks slightly different than the running Default SMTP VS.

We're not ready to start this SMTP VS yet. The next step is to go back to Cluster Administrator and create a resource for it.

1. In Cluster Administrator, go to your Exchange group, right-click group New Resource
2. Type in a name for the new resource - let's say "SMTP VS2 Instance"
3. Select "Microsoft Exchange SMTP Server Instance" as the Resource Type
4. In the Possible Owners dialog box click Next (all nodes that are possible owners for the EVS are selected by default)
5. In the Dependencies dialog box select Microsoft Exchange System Attendant click Next
6. In the Virtual Server Instance dialog box select the new SMTP VS (selected by default) click Finish.

The new SMTP VS is now created. Bring it online by right-clicking on the new instance in Cluster Administrator select resource right click Bring Online

You can now test the new SMTP VS.
1. Go to Exchange Sytem Manager and expand Protocols SMTP (hit refresh if it's already expanded). You will see the icon change. The SMTP VS has started.
2. From command prompt, telnet to the new SMTP VS on port 25.

Exchange Server 2003 SP2, using SenderID? You need this hotfix!

If you've just upgraded to Exchange Server 2003 Service Pack 2 and have enabled Sender ID filtering, you need to apply a hotfix to prevent the server from stopping to respond.

According to the KBA, the problem occurs because of a race condition caused by the SMTP protocol. A race condition occurs when a device or a system tries to perform two or more operations at the same time. Because of the nature of the device or system, the operations must be performed in the correct sequence in order to be completed correctly.

Windows Server 2003: http://support.microsoft.com/default.aspx?scid=kb;en-us;905214
Windows 2000 Server: http://support.microsoft.com/default.aspx?scid=kb;en-us;909426
[No hotfix available yet for Windows 2000]

Interestingly, the Windows 2000 version of the KBA (909426) was released on Oct. 17 with revision 1.0, 2 days before the public release of Service Pack 2 on Oct. 19.
The Windows Server 2003 version (905214) was last revised on Oct. 21 and is currently at revision 3.0.

Exporting Sender Filter List

Messages from specific senders can be blocked by implementing sender filtering. Blocked senders are specified in Global Settings Message Delivery properties Sender Filtering tab (see screenshot).

The Senders list is saved in the msExchTurfListNames attribute of the Default Message Filter object. It is a multi-valued attribute. It can be exported using ldifde/csvde if you take the trouble to find out distinguishedName or objectClass of the attribute.

Here's a little script (... quite complicated actually, considering it can be done using either of the above methods using a single command... ) that will export the list to a text file -
getSenderFilterList.vbs (zipped).

Usage:
getSenderFilterList.vbs /f:filename.txt - exports to file
getSenderFilterList.vbs /f:filename.txt /s:y - exports to file and suppresses console output

Exchange Server 2003 SP2 and IMF

Before you install Exchange Server 2003 SP2 you need to uninstall Intelligent Message Filter (IMF). When you do this, the settings from the SMTP virtual server where you allowed filtering are also removed.

After SP installation if you go to Intelligent Message Filtering settings (Global Settings -> Message Delivery -> Properties -> Intelligent Message Filtering tab) and setup IMF with same settings as earlier, that alone does not reactivate IMF.

You still need to enable IMF from the SMTP virtual server properties -> General tab -> Advanced Edit (see screenshot, Flash demo of IMFv1 and IMFv2 settings - not entirely intuitive location for these settings, imo) and check "Apply Intelligent Message Filter" - just as you need to check the relevant options for recipient filter, connection filter, sender filter, and the new option of applying SenderID filter.

Sending mail from telnet session

This procedure is commonly used to troubleshoot SMTP hosts. In combination with a nslookup query for MX records for a domain (listed after this) you can successfully figure out if a given domain can receive internet email successfully.

1) Open a telnet session to a SMTP - let's say foo.mydomain.com - or an IP address
telnet foo.mydomain.com 25
What you get back:
220 foo.mydomain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.1289 ready at Wed, 19 Oct 2005 10:27:34 -0700

2) Now you can say where you're sending mail from using HELO
helo foo2.somedomain.com
250 foo.mydomain.com Hello [65.239.32.15]

3) Provide sender's address
MAIL FROM:me@somedomain.com
250 2.1.0 me@somedomain.com....Sender OK

4) Provide recipient's address
rcpt to:someone@mydomain.com
250 2.1.5 someone@mydomain.com

5) To start message content, issue the DATA command
DATA
354 Please start mail input.

6) Enter the Subject
Subject: This is a test


7) Type in the body
This is a test from me@somedomain.com

8) To end the message, enter a dot in a new line followed by Enter
.

250 Mail queued for delivery.

10) Close the connection
quit
221 Closing connection. Good bye.

How to determine the mail exchanger (MX) for a domain

You can use the following procedure to determine the mail servers designated as "mail exchangers" for a domain. This is done by inserting a MX record for those servers in the DNS. Best practice for MX records is to point them to A records. A records are simple hostname to IP address mappings.
Pointing MX records to CNAME records may result in performance issues.

From a command prompt, type:
nslookup -querytype=MX somedomain.com

This should produce output similar to the following:
Server: ns1.mydomain.com
Address: 192.168.1.10

Non-authoritative answer:
somedomain.com MX preference = 10, mail exchanger = mx1.somedomain.com
somedomain.com MX preference = 20, mail exchanger = mx2.somedomain.com
mx1.somedomain.com internet address = x.x.x.x
mx2.somedomain.com internet address = x.x.x.x

HOW TO: Export all email addresses from a domain

Background: AD Users & Computers UI lets you list the mail column for each object, which displays the default (SMTP) email address for objects. You can export the list from ADUC as csv/txt. However, any additional email addresses in the proxyAddresses attribute are not exported.

There's no GUI to list/export all email addresses. Here's a script to do that - ListEmailAddresses.vbs.

File: ListEmailAddresses.zip

What does it exactly do?
- Queries Active Directory for Contacts & Groups
- Lists their email addresses
- Queries Users
- Lists enabled users' email addresses
- Lists disabled users' email addresses separately (was required for a certain project I did a long time back)
- Outputs to command line and also to a text file - c:\proxyaddresses.txt
- X.400 addresses are ignored

Updates:
08/07/2007: Download link updated to correct URL.

How to create a Recipient Policy based on Company names?

One of the more frequently asked questions in an environment where you want to host more than 1 company's email on a single Exchange server. Both companies have unique dns domains, let's say CompanyA.com and CompanyB.com.

You typically end up locating thw users from the 2 (or more) companies in their own respective OUs.

You go to Recipient Policy in Exchange System Manager to create a recipient policy that generates the email addresses for CompanyA, but there' s no option to be able to create a policy based on OUs! Unlike GPOs in Active Directory, Recipient Policy cannot be created base on OUs. Adding this feature would make lives of a gazillion Exchange admins easier, but the fact is you can't.

So what are the options? You could create the policy based on attributes like location, department, company etc. In this case, we will go ahead and create the policy based on the company attribute.

This can be easily accomplished from the Recipient Policy GUI.

1. Go to the Recipient Policy container | right-click in the right pane where the default policy is listed | New | Recipient Policy.
2. From the New Policy dialog box, select the "E-mail addresses" checkbox to create a policy that generates email addresses. (The other option is Mailbox Manager settings) | click OK.
3. Enter a name in the General tab of the policy - let's say "CompanyA Policy"
4. Click the Modify button - this presents the familiar ldap/ad search UI
5. In the Advanced tab, click the Field dropdown | select "User" | select the "company" attribute
6. From the "Condition" drop-down, select "Is (exactly)" condition
7. In the "Value" box type in the company name as it appears in your users' Company field in AD Users & Computers | click Add to add the condition to the filter
8. [Optional] You can click on the "Find Now" button to see which users will be selected by that filter
9. Click on OK to add the filter to the policy. You may get an ESM warning that informs you about applying the policy | click OK
10. Go to the E-mail addresses tab | modify the default SMTP address to @companyA.com
11. ESM will prompt you to update recipient's addresses. You can select Yes if you want to update immediately, or No if you are in a large domain where you want to schedule the update for later.

Wait for RUS to run. If set to run all the time, you can check the users' properties to see if the intended recipients have the new email address.

Repeat the procedure for CompanyB.com domain.

Things To Remember:
1. You can modify the Default Policy to use it for CompanyA.com, else the Default Policy will still apply if its conditions are met, and you may see email addresses that are not required for a certain set of users.
2. When creating a new user, you will have to remember to always populate the user's relevant attribute (company in this case) for the user to get the right email address.

Frequent reports of NDRs with 5.7.1 errors

Noticed an increase in NDRs with 5.7.1 error from posts in newsgroups and a colleague saw 2 of those within the last week. If you're using Exchange, you may see Event IDs 1709 and 1710 in your Application Log. Some common causes:
1) Allow computers which successfully authenticate to relay checkbox not checked on SMTP virtual server
2) DNS misconfiguration and Recipient Policy issues
3) Proxy addresses created manually that do not match any Recipient Policy (I was surprised by this one!)
4) If using ISA server, ISA's IP address changes but server publishing rule not changed

More info about what causes these on the Exchange site.

Exchange SP2 - Connection Filtering that actually works

I was excited to find out about Connection Filtering (screenshot) in Exchange 2003 - finally I could use RBLs (real-time block lists) without having to dabble with event sinks!! (This is from back in the days when RBLs were still sexy and could keep a good chunk of spam away from your users... )

Connection Filtering works with or without RBLs - you can also specifiy IP addresses manually in a Global Accept and Deny list.

However, in most enterprise environments Exchange does not perform the role of a smtp mail gateway to the Internet. That's usually assigned to the "more capable and secure" Linux/Unix servers running MTAs like Sendmail or Postfix. So all inbound email delivered to your Exchange servers is from the IP addresses of your own trusted mail gateways. Unfortunately, this renders Exchange's Connection Filtering useless!

Exchange Server 2003 SP2 changes that - it parses the headers of inbound email for the originating server's IP address, enabling connection filtering on any inside Exchange server. Bottomline, no matter where you put your Exchange Server 2003 SP2 box, connection filtering will just work!

Adding disclaimers to outbound SMTP messages

Disclaimers are increasingly becoming commonplace in email messages sent to external (and at times internal) recipients. Security policies at many organizations require these disclaimers.

If you've been looking for this feature in Exchange System Manager, it's not there yet! You need to use a SMTP Event Sink to get this done.

Microsoft has couple of KB artciles with code in VBScript and VisualBasic for creating and registering a disclaimer event sink:
1. KB317680 How to add a disclaimer to outgoing SMTP messages in Visual Basic script
2. KB317327 How to add a disclaimer to outgoing STMP messages in Visual Basic

Rui Silva's article on ExchangeOrg.com - Disclaimer Fun - provides some additional functionality, and compares performance of the VBScript and the VisualBasic DLL. One would assume the DLL beats the script to pulp - surprise, surprise! The script is the winner in this case - it took 9 minutes to process 5000 messages, the DLL tooko 15 (albeit less taxing to the CPU).

Message Tracking as part of OWA/Outlook

Message Tracking is one thing I've since long wanted to see built into the client - either as an OWA-only feature or perhaps in OWA and Outlook.

Problem: Users want to find out where a message they sent ended up - was it delivered? At what time? To which server? Same thing for inbound messages.

Solution: This is now an admin task, but perhaps just as easily implemented on the client side to let users do it themselves if they wish. Users can be allowed to track only those messages they sent or inbound messaages sent to them. The easiest implementation is perhaps to build the necessary web pages that query the tracking logs into the OWA interface (just like deleted message recovery is right now).

I threw the idea out there to the Exchange product team during TechEd. Let's see if Microsoft finds this feature useful enough to include it in Exchange.

Message Tracking in Exchange System Manager is great, but when you save the tracking info it is saved as XML only. There are no other options. Users find that info hard to comprehend when they come across it (with all XML tags, et al).

Another neat addition to that would be to include a little form with email fields that an admin can type in, to send that info to the concerned persons in a presentable format. It could have the internal recipient's email address already populated, and optionally one could enter addresses of more internal or external recipients.

Where did the Badmail go in Exchange 2003 SP1?

In previous versions of Exchange, all mail that cannot be delivered ends up in the Badmail directory. This folder grows infinitely till it runs out of disk space!

E2K3 SP1 changes that. By default, SP1 will suck up all Badmail in a virtual blackhole - no bad mail accumulates.

Would you rather keep your Badmail? Can be changed with couple of registry settings.
Value: MaxBadMailFolderSize - this is the size in KB.
Under HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing
If set to 0, badmail disappears. -1 reverts to pre-SP1 settings - accumulate till infinity. However, like circular logging, this doesn't "rotate" messages - just collects messages till the max folder size is reached and then stops collecting more bad mail.

Value: BadMailSyncPeriod - specifies how often to check the Badmail folder (in minutes).

In addition to the above, there's also a Badmail Archiving and Deletion script that can be used to archive messages in the Badmail directory.

With SP1 and above tools, it's easy to maintain a "Badmail-free" Exchange environment, or at least control how big the Badmail folder gets.