Vince,
I would think section 7.7 inherently implies HELO to be included when it
mentioned "EHLO." It might be a slip in not including HELO along with EHLO.
I think the principle idea was about site policy rejection code
recommendation and using a 55x response code.
The fallback response code is 50x which is the class of "unknown command"
response codes. This is what you would normally expect for a non-ESMTP host
site who does not support or recognize HELO. See section 4.2.4 about 502 vs.
500.
For example:
The ESMTP compliant sender will issue an EHLO and generally, you can get a
clue by looking for "ESMTP" as part of the standard welcome line (BCP), but
this is not reliable. So the ESMTP client should always try EHLO first.
S: 250 %hostdomain%, %ProductName% ESMTP server %version% ready.
C: EHLO xxxxx
S: 500 Unrecognized command: EHLO
This is when you should fall back when a 50x is received. You should not
fall back for a 55x response which is what 7.7 is basically saying, and I
believe that includes a 55x response to HELO as well per the site policy.
PS: A 55x response to HELO/EHLO is a growing practice. It kills a
significant amount of bulk spammers specially thus who pipe line the
transaction. Simply add a strict SMTP compliancy and you will catch much of
it. The only issue you will run across - legacy applications using
incorrect domain literals and/or NAT translated addresses.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "Vince Sabio" <vince(_at_)vjs(_dot_)org>
To: "ietf-822" <ietf-822(_at_)imc(_dot_)org>
Sent: Monday, February 28, 2005 12:44 PM
Subject: Site policy vs. HELO
I'm bringing this question over here from the SPAM-L list.
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?
__________________________________________________________________________
Vince Sabio
vince(_at_)vjs(_dot_)org