Site policy vs. HELO

Vince Sabio <[email protected]>
Newsgroups gmane.ietf.rfc822
Message-ID <p05200f02be49018aa965@[10.185.203.80]>
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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.