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 [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, equivalent of the SMTP Virtual Server we've known from Exchange Server 2003/2000 - Bharat). I hoped to see (SMTP) protocol logging turned on by default on these connectors. However, like the previous versions, it's not. You have to remember to enable (SMTP) protocol 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.



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 these 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.

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.

Back Pressure
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 those. 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.
- Many configuration options for transport servers are saved in the file \Exchange Server\Bin\EdgeTransport.exe.config (same name on Hub Transport servers as well). You can edit the file to disable Back Pressure, or modify the parameters to more accurately define what's high utilization for your deploy