ietf-smtp
[Top] [All Lists]

Site policy vs. HELO

2005-03-02 11:03:58

[I had originally posted this question to the ietf-822 list, where it was pointed out that I *should* have posted it here. I apologize if this appears to be a cross-post; it's actually a re-post to the proper list.]

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


<Prev in Thread] Current Thread [Next in Thread>