[Top] [All Lists]

Re: Site policy vs. HELO

2005-03-02 12:29:38

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.


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.)


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.


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

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