On Fri, 22 May 2009, Arvid Ephraim Picciani wrote:
Greetings.
I'm thinking of implementing:
- greylisting
- honeypots
- rejecting broken HELO at smtp time (such as "MUMS_XP_BOX")
- rejecting dynamic IPS at smtp time (PBL)
- firewalling hosts with 100% spam, forever.
Are there any oposing opinions on those?
My suggestions for SMTP-time message tests are embodied in my sample
milter-regex file at http://www.impsec.org/~jhardin/antispam/
I recall some people dont like greylisting for some reasons.
Some admins have to deal with users who have (to me, unrealistic)
expectations that email is a 100% reliable _real-time_ communications
mechanism, and are thus reluctant to add any unnecessary delay. If delay
is not a problem, or if you are willing to configure your greylist to
bypass known correspondents, then there's no issue.
Spammers to some degree are also rewriting their bots to work in the face
of greylisting, but it still seems (in the absence of actual statistical
analysis - the plural of "anecdote" is not "data") to help.
I am very happy with it, but I am running only a small domain.
Also i'm unsure if should firewall, since the postmaster of that host
might all sudden get things under control. But we currently have around
99% spam, so i think i need more drastic actions before our mailbox
overloads :(
My policy is to automatically TCP tarpit (not just firewall) repeat
offenders, but that behavior is based on the MTA log, so the tarpit will
open back up after a while on its own - if they aren't making it to the
MTA, they don't generate any new log entries. If the abuse continues, they
go back into the tarpit for a while. If the admin cleans things up and the
abusive behavior stops, they won't get tarpitted again.
At present that policy is based on a client in zen continuing to connect
even though they always get a 5xx reject, or someone with a reject in
/etc/mail/access continuing to connect, so it's not as dynamic as it could
be. For example, it would be possible to add some analysis of SA logs to
include IP addresses that were generating pure spam for recent traffic.
I'm getting lots of it from zombies, so i wonder if its legitime to scan
the sender before accepting. For example if it blocks icmp, its very
likely a home router. But i have no data on that, and no clue.
There are ways to tie p0f (OS fingerprinting) into the mail system, see
http://www.google.com/search?q=p0f+smtp
I will leave it to others to comment on the effectiveness of that, I have
no experience with it.
Spamhaus has only about half of the zombies. PBL even lacks half of the
german dialup ISPs. i'm thinking i need my own techniques to build such
lists.
Blocking at the MTA ising a DNSBL is risky, you want to be careful in
choosing which DNSBL you use for poison-pill-level access control. The
consensus is that zen.spamhaus.org is reliable enough for this (though of
course some will disagree).
There are other things to look at. For example, is your MTA configured to
accept invalid email addresses and quietly discard the message? If so,
that may make your domain more attractive to spammers than it would be if
you rejected invalid addresses during SMTP. Your saying "honeypot" above
makes me wonder if you have catchall turned on and are accepting mail to
invalid addresses and feeding that to your spam corpus. That's valid, but
it does have a cost, and I wouldn't do that on my main domain.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Insofar as the police deter by their presence, they are very, very
good. Criminals take great pains not to commit a crime in front of
them. -- Jeffrey Snyder
-----------------------------------------------------------------------
32 days since 9th Circuit incorporated 2nd Amdt - MSM still silent
