Re: Site policy vs. HELO

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" <[email protected]>
To: "ietf-822" <[email protected]>
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                                                  [email protected]
>
>