On Wed, 5 Oct 2005, Michael Peek wrote:
>
> I would like to deny hosts whose $sender_helo_name/address doesn't match
> their $sender_host_name/address. The problem with this is that so many
> legitimate hosts aren't configured to tell me who they really are.
Yup.
> So my next brilliant idea was to accept HELO's that are "close" to each
> other, and I defined close as being if the first 3 out of 4 octets of
> their IP addresses are the same.
That won't work either, because many legitimate mail servers say HELO
using private names that are not valid outside their local networks, or
names which are resolvable publicly but which refer to RFC 1918 addresses
(e.g. eBay's mail servers).
> Before I go much farther with this (like dropping the required "closeness"
> from 24 bits to 16 bits -- all I really care about is that the remote host
> isn't obviously lying), what clever things have you guys implemented?
The only safe thing to do with HELO is to examine it for properties that
definitely indicate that the software at the other end is malware.
Misconfiguration does not imply malice! Our checks are slightly more
aggressive than those recommended by others on this list (particularly the
all-numeric check), but they seem to be pretty reliable.
deny
message = Please use your name when saying HELO (not $sender_helo_name)
condition = ${if or{{ eq{$ACL_HELO}{bad} } \
{ eq{$sender_helo_name}{$local_part} } \
{ match{$sender_helo_name}{^[0-9.-]+\$} } \
{ match{$sender_helo_name}{\N[.][.]|.{55}\N} } \
{ match_domain{$sender_helo_name}{+our_domains} }} }
set ACL_HELO = bad
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
