On Apr 1, 2004, at 11:17, Alan J. Flavell wrote:
> On Thu, 1 Apr 2004, Richard Welty wrote:
>> On Tue, 30 Mar 2004 18:01:17 +0100 Bruce Richardson
>> <itsbruce@???> wrote:
>>> Rejecting on the helo parameter is useless, as many clients put junk
>>> in
>>> there. In addition, rejecting on HELO can often mean that the remote
>>> client, if it is an mta, repeatedly tries to resend.
>>
>> so reject on HELO at RCPT TO: time.
>
> Absolutely. It's been said many times before. It optimises the
> chances of getting rid of unwanted callers, while still leaving open
> the possibility to get mail through to the postmaster if there's a
> genuine problem (assuming your logic allows postmaster/abuse mail
> through before applying these rules).
Or better yet, stall for 20 seconds or so if you don't like the HELO,
then perform the actual reject at a later stage (RCPT, for instance).
(I do various checks at SMTP connect, HELO, MAIL, RCPT, and/or DATA; if
I find any problem, I stall there and for all subsequent commands as
well, and finally reject after DATA).
If 60,000 of a spammer's target machines did this simultaneously, it
would essentially slow down the spread of the spam.
>> reject hosts that claim to be me
Good.
>> reject hosts that HELO with my IP
Better: Reject hosts that HELO with ANY IP:
message = You greeted me with an IP address. I want your name.
condition = ${if isip {$sender_helo_name}{true}{false}}
Per RFC, IP addresses should be enclosed as literals (i.e. in []).
Even that, few legitimate mailers (certainly no major MTA) do.
>> reject host where the HELO parameter is out of conformance with the
>> RFCs (it must be an FQDN or a IP in [] characters.)
> You reject underscores? Brave man. We tried that, but weren't
> allowed to maintain our position. Even the EU courts won't prevent
> the dominant vendor from imposing its "industry standard" i.e Internet
> non-standard.
You could set:
helo_verify_hosts = *
helo_allow_chars = _
-tor
