Performance

[Glenn Steen]

On 02/02/07, John Schmerold <john at katy.com> wrote:
> This list becomes an important archive of useful information, so I want
> to let everyone know we ended up eliminating the smtpd_helo_restrictions
> section. Too many mail servers are mis-configured. Besides, the RFC,
> states that the recipient server will accept the message regardless of
> whether or not the HELO statement is proper.
>
You are quite correct that one can interprete RFC 2821 (section 4.1.4)
that way (and that it was intended that way:-), but one has to take a
few things into account... It was written 2001 (well, actually
earlier) when spam wasn't that huge a problem, and this whole
statement is aimed at minimizing problems... I'd say that someone
intentionally using your "credentials" constitute violate the spirit
of the "law", if not the letter. And indeed, this "feature" doesn't
really break the letter of that "law" either... See the transcript
below (I use smtpd_delay_rejects=yes ... And I don't use any
greet_pause ... yet):

# telnet mail 25
Trying 172.18.3.86...
Connected to mail.ap1.se (172.18.3.86).
Escape character is '^]'.
220 mail.ap1.se ESMTP Postfix
ehlo mail.ap1.se
250-mail.ap1.se
250-PIPELINING
250-SIZE 16777216
250-ETRN
250 8BITMIME
mail from:<>
250 Ok
rcpt to:<glenn.steen at ap1.se>
554 <mail.ap1.se>: Helo command rejected: Access denied
quit
221 Bye
Connection closed by foreign host.

Please note that we follow the RFCs stipulation (MUST) to only reject
the EHLO and stick around in the same state... All ready to process
any mails, provided a valid EHLO/HELO is given. This is _exactly_ by
the letter of the RFC.

So, there is litle to no risk with this. The sender _will_ get a
somewhat informative reject code, and should be able to find the
problem at their end... Forcing _them_ to comply to the RFC;-).

-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se