2.2. The Extension Model

2.2.1. Background

In an effort that started in 1990, approximately a decade after RFC

821was completed, the protocol was modified with a "service

extensions" model that permits the client and server to agree to

utilize shared functionality beyond the original SMTP requirements.

The SMTP extension mechanism defines a means whereby an extended SMTP

client and server may recognize each other, and the server can inform

the client as to the service extensions that it supports.

Contemporary SMTP implementations MUST support the basic extension

mechanisms. For instance, servers MUST support the EHLO command even

if they do not implement any specific extensions and clients SHOULD

preferentially utilize EHLO rather than HELO. (However, for

compatibility with older conforming implementations, SMTP clients and

servers MUST support the original HELO mechanisms as a fallback.)

Unless the different characteristics of HELO must be identified for

interoperability purposes, this document discusses only EHLO.

SMTP is widely deployed and high-quality implementations have proven

to be very robust. However, the Internet community now considers

some services to be important that were not anticipated when the

protocol was first designed. If support for those services is to be

added, it must be done in a way that permits older implementations to

continue working acceptably. The extension framework consists of:

o The SMTP command EHLO, superseding the earlier HELO,

o a registry of SMTP service extensions,

o additional parameters to the SMTP MAIL and RCPT commands, and

o optional replacements for commands defined in this protocol, such

as for DATA in non-ASCII transmissions (RFC 3030[20]).

SMTP's strength comes primarily from its simplicity. Experience with

many protocols has shown that protocols with few options tend towards

ubiquity, whereas protocols with many options tend towards obscurity.

Each and every extension, regardless of its benefits, must be

carefully scrutinized with respect to its implementation, deployment,

and interoperability costs. In many cases, the cost of extending the

SMTP service will likely outweigh the benefit.

2.2.2. Definition and Registration of Extensions

The IANA maintains a registry of SMTP service extensions. A

corresponding EHLO keyword value is associated with each extension.

Each service extension registered with the IANA must be defined in a

formal Standards-Track or IESG-approved Experimental protocol

document. The definition must include:

o the textual name of the SMTP service extension;

o the EHLO keyword value associated with the extension;

o the syntax and possible values of parameters associated with the

EHLO keyword value;

o any additional SMTP verbs associated with the extension

(additional verbs will usually be, but are not required to be, the

same as the EHLO keyword value);

o any new parameters the extension associates with the MAIL or RCPT

verbs;

o a description of how support for the extension affects the

behavior of a server and client SMTP; and

o the increment by which the extension is increasing the maximum

length of the commands MAIL and/or RCPT, over that specified in

this Standard.

In addition, any EHLO keyword value starting with an upper or lower

case "X" refers to a local SMTP service extension used exclusively

through bilateral agreement. Keywords beginning with "X" MUST NOT be

used in a registered service extension. Conversely, keyword values

presented in the EHLO response that do not begin with "X" MUST

correspond to a Standard, Standards-Track, or IESG-approved

Experimental SMTP service extension registered with IANA. A

conforming server MUST NOT offer non-"X"-prefixed keyword values that

are not described in a registered extension.

Additional verbs and parameter names are bound by the same rules as

EHLO keywords; specifically, verbs beginning with "X" are local

extensions that may not be registered or standardized. Conversely,

verbs not beginning with "X" must always be registered.