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