Ed,
Unless I am missing something in the question, all clients need to be ready
for a 50x response to a EHLO request.
500 means the command is not understood by the host server
501 or 502 means it is understood but not implemented for what ever reason.
The client should fall back on a 500 and the server MUST be ready for a
HELO. However, in practice, it is probably best to fallback on a 50x as it
has been shown that 501 or 502 can happen as well with an acceptable fall
back. This goes against the 2.2.1 section recommendation for EHLO support,
but it is what it is out there. So I recommend your client to be ready for a
50x fallback.
55x on the other hand means that the client SHOULD NOT try again regardless
of the client request, including HELO. That's it. No questions about it.
55x means don't try again.
In my opinion, section 7.7 inherently implies HELO when it indicated EHLO.
The reason I say that is because the section presumes EHLO ready clients,
but the site policy may also apply to HELO only clients just as well.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: <EdLevinson(_at_)ResultsLifeCoaching(_dot_)com>
To: "Vince Sabio" <vince(_at_)vjs(_dot_)org>
Cc: "ietf-smtp" <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, March 02, 2005 2:29 PM
Subject: Re: Site policy vs. HELO
The question posed is: Can a site whose policy is not to do EHLO be in
compliance with RFC2821? Or does Sect 7.7 provide an exception to 2.2.1?
<PseudoLegalese to try to be precise>
Better to ask, How can a site be in compliance with both sections? Then,
according to 2.2.1, they MUST support HELO and according to 7.7 they may
decide to "limit the use of the relay function to known or identifiable
sources". Elsewhere, Sect. 3.7, RFC 2821, states, "The relay server may
accept or reject the task of relaying the mail in the same way it accepts
or rejects mail for a local user." That suggests that a server treat a
HELO that same way it treats an EHLO, applying its policies using the
(obviously limited) information the HELO provides.
The paragraph in Sect 7.7 that precedes the one quoted makes that clear:
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server. However, cooperation among sites
and installations makes the Internet possible. If sites take
excessive advantage of the right to reject traffic, the ubiquity of
email availability (one of the strengths of the Internet) will be
threatened; considerable care should be taken and balance maintained
if a site decides to be selective about the traffic it will accept
and process.
Best.../Ed
At 01:03 PM 3/2/05 -0500, Vince Sabio wrote:
The following graf in RFC2821 appears to require an MTA (not an
RFC2476-type MSA) to fall back to HELO for compatibility with older SMTP
clients and servers):
[QUOTE RFC2821 SECT 2.2.1]
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.)
[END QUOTE]
However, it has recently been pointed out that the following graf in
RFC2821 may permit sites to _not_ be required to fall back to HELO -- and
issue a 550 response to HELO instead -- if local policy dictates:
[QUOTE RFC2821 SECT 7.7]
In recent years, use of the relay function through arbitrary sites
has been used as part of hostile efforts to hide the actual origins
of mail. Some sites have decided to limit the use of the relay
function to known or identifiable sources, and implementations SHOULD
provide the capability to perform this type of filtering. When mail
is rejected for these or other policy reasons, a 550 code SHOULD be
used in response to EHLO, MAIL, or RCPT as appropriate.
[END QUOTE]
So, the question: Is this a valid interpretation of Sect. 7.7 -- i.e.,
may
an MTA provide a 550 response to HELO where it would otherwise have given
a 250 response to an EHLO if the site policy for that MTA forbids HELO?
Die hard techie
Tel: 732.494.1606 Fax: 732.494.4495 Cell: 908.930.9409
email:e(_dot_)levinson(_at_)ieee(_dot_)org