The Extension Model

Background

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

821 was 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.