On 10/7/2016 3:59 AM, Hardy wrote:
> Hi folks,
>
> 2nd Stage DNS blocking
> I could imagine I am not the first with this idea, and there is already
> a proper name for it. Let me describe:
> We receive spam via the usual MTA chain. Sometimes we receive mail from
> (free) mail providers like gmail and yahoo. Sometimes we fetchmail these
> latter ones to feed them to our MX.
> We only check the connecting server, and in some of the examples above
> it might even be trusted. But that one was tricked to take spam before.
> Random samples show me: We would not have taken most of the spam from
> the intermediate or even originating MTA or sender. I would like to run
> these "Received from" addresses against dnslists and/or blacklists in
> files.
> You obviously cannot do this before the acl data. I am not a regex wiz,
> and I think one needs an external script anyway to extract IPs. Hints?
> Ideas?
> Has anyone done before?
>
> Cheers
> Hardy
>
My experience is that the IP of any host that connects with spam to
relay to my server is either already in spamhaus ZEN (virtually all) or
will be within minutes. So, simply DNSBL checking ALL connecting host
IPs in acl_smtp_mail (via ZEN) rejects that spam without my server ever
receiving one byte of it.
What about the small amount of spam that gets past the ZEN check? For a
month, I manually ran the connecting host IP's of all spam that had
gotten through ZEN the previous day. 100% of those IPs were now in ZEN
(see my contention above that it takes very little time for a host
relaying spam to get into the ZEN DNSBL).
Because the ZEN host check catches well over 99% of spam, I conclude
that it would be a complete waste of resources to DNSBL check secondary
IPs in the headers.
Could an "innocent" host be tricked into relaying spam? Sure. (However,
in my experience, it doesn't happen.) And, guilty or not is not my
problem. I run the check on ALL hosts. All rejected hosts receive the
same message:
X-Warning: $sender_host_address is listed at $dnslist_domain.
$dnslist_text
example:
<barney@???>: 95.142.134.149 is listed at zen.spamhaus.org
(127.0.0.11, 127.0.0.4: https://www.spamhaus.org/query/ip/95.142.134.149)
But for the innocents: Spamhaus has easy procedures for innocent hosts
to get removed. My rejection message spells out precisely where to go to
resolve it. For example, in this case the URL:
https://www.spamhaus.org/query/ip/95.142.134.149
At that URL, spamhaus has an exquisitely detailed description of why the
host is on each list and how to get off it. Sadly, this particular
zombie host is oblivious.
Finally:
There are those who willingly would throw away tons of HAM to avoid one
SPAM. (A small few of my business customers apparently fall into that
category. They DROP my site's notices of pending paid subscription
expirations, which then leads to extra renewal fees I happily accept
when their account inevitably becomes locked.)
I am not in that group. As a businessman, I would instead willingly
receive a ton of SPAM to avoid losing one customer by treating his HAM
email as SPAM.
Nevertheless, using basically nothing but spamhaus ZEN, I eliminate 99%+
of SPAM with zero loss of HAM. (I do run SpamAssassin on received
email, but I still accept all email regardless of score. This turns out
to be almost nil, but what does get through is easily sorted
automatically by my IMAP client into a junk IMAP folder with a short
retention period.)
In summary, I really don't see the need for elaborate mechanisms for
spam rejection.
Virtually the entirety of my spam rejection system boils down to three
lines in:
# -------------------------
acl_check_mail:
# -------------------------
...
deny message =
X-Warning: $sender_host_address is listed at $dnslist_domain.
$dnslist_text
log_message =
$sender_host_address is listed at $dnslist_domain ($dnslist_value:
$dnslist_text)
dnslists = +defer_unknown : zen.spamhaus.org
> Hi!
> User proper tool for proper thing. Use tuned spamassassin or rspamd to
> do it. E.g. use SA instance with only rbl rules for lightweit check.
> Marcin
Using RBL checking after message receipt either provides no mechanism to
inform an innocent sender (using DROP) or risks actually becoming a
spammer if you bounce the message back to the ostensible "sender"!
--Phil
