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 SMTP 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. 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, should be as follows (depending on whether you’re using HELO or EHLO):
HELO foo.somedomain.com
or
EHLO foo.somedomain.com
(followed by a CR LF)

How Exchange Server treats HELO/EHLO command with a trailing dot or a space

The IIS/Exchange 2003 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 (and Exchange 2010), 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).

Disabling HELO/EHLO domain validation

Exchange 2003: 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.

Exchange 2010/2007:In Exchange 2010 and Exchange 2007, domain validation is disabled by default. You can use the Set-ReceiveConnector cmdlet to disable or enable domain validation.

Set-ReceiveConnector <Receive Connector Name> -RequireEHLODomain <$true | $false>

The change kicks in immediately for new SMTP connections. The connector no longer requires the SMTP client to provide a domain in the HELO/EHLO command. If the client provides a domain in the HELO/EHLO command, it isn’t validated.

The impact

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.

Tags
Administration   Anti-Spam   Security   SMTP