[Top] [All Lists]

Re: Site policy vs. HELO

2005-03-02 21:34:56

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.

I don't mean to be pedantic, but it is arguably still not clear. Based on that graf, a site could accept EHLO under "proper circumstances" (i.e., well-formed EHLO from a non-blocked site, etc.), yet still reject all use of HELO under any circumstances for "operational or technical reasons that make sense to the site providing the server," where, at that site, "care has been taken and balance maintained [in the decision] to be selective about the traffic it will accept and process."

the reason for not accepting HELO has to "be an operational or technical reason that makes sense".

consider three cases:

1. client uses HELO, and because it sends HELO it cannot supply any additional information to the server via SMTP extensions 2. client uses EHLO, but doesn't supply any additional information to the server via SMTP extensions 3. client uses EHLO but does supply additional information to the server. for example, it might use SMTP AUTH to authenticate itself to the server, or it might use a future extension to supply originator-supplied credentials to the server.

it makes no operational or technical sense for the server to distinguish case 1 from case 2. in both cases the server has the same information _about the message_ available to inform its decision. the single bit of information about whether the client used HELO vs. EHLO is meaningless to the server in deciding whether the message is valid or whether it merits handling by the server. (there are occasionally good operational reasons for a client to disable EHLO - for instance, some firewalls have been known to break EHLO by allowing the server to advertise SMTP extensions whose parameters were not acceptable to the firewall)

on the other hand, the server might quite reasonably use the additional information available in case 3 to change its handling of the message. but the additional information isn't in the EHLO vs. HELO bit, it's in the additional parameters supplied by the client.

or to put it another way - sure the server can do anything it wants, including bouncing random messages, bouncing all messages, delivering all mail to a bit bucket, whatever. whether the standards say you can or cannot do it is irrelevant. the question is whether it helps your mail work better. distinguishing between EHLO and HELO is likely to harm your mail service rather than help it in any way. specifically it's not a good metric for helping to decide whether traffic is valid.


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