[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-users
Subject:    Re: new anti spam feature: "zombielist", help wanted
From:       Michael Monnerie <michael.monnerie () it-management ! at>
Date:       2008-05-27 8:30:56
Message-ID: 200805271030.56659 () zmi ! at
[Download RAW message or body]


On Dienstag, 27. Mai 2008 Henrik K wrote:
> What do you do when you get a single spam from hotmail/gmail etc? You
> are going to defer a host that sends you mostly legimate mails?

No, it's not even about spam currently. It's plainly one of the three 
options I mentioned in my first e-mail (see also below) than can get 
you on the list.
Also, there's a counter, and only after several errors a host get's 
listed.
With the new daemon, it should be possible to count for a sender IP the 
number of hams/spams and then you could say "if a sender sends 50% spam 
during the last 24h, block it".

> You should modify it atleast to take account of how much ham has been
> sent.

That is currently not implemented as we do not look at this at all.

> I would continue this on amavis mailing list, since it's a bit
> offtopic.

It's also not an amavis thingy, but a good idea I will drop the message 
there also. It best fits on postfix-users I guess, but we will see.

[From another post:]
> what's the goal here exactly?

* reduce the CPU and network load:
- you don't need to ask RBLs too often
- if the sender server does not have a rDNS, you block it for a while
- sender's domains younger than 5 days are blocked
- and with the new daemon I want to be able to have finer control, so 
you can also block senders who constantly connect and then "lost 
connection after ..." (we've had this once from lot's of hosts, looked 
like a dDoS). The current implementation only gives one possible 
timeout value for delisting, while the new should have a timeout per 
rule (eg. delist IP after 6h if listed because of RBL, but 1d if listed 
because of no reverse IP).

[From another post:]
>> - no reverse lookup for that IP at all
> Good luck. I'd reject heaps of legimate mail with that.

We've started implementing that early 2007. By then, we've had some 
issues, but they are constantly reducing. We're in Austria/Europe, and 
one big advantage is that GMX is also rejecting in case of missing 
rDNS: http://faq.gmx.de/optionen/email/antispam/4.html
If nobody does start to enforce stricter rules, the SPAM problem won't 
go away. But anyway, it's of course configurable if you want to reject 
on a missing rDNS or not.
One solution could be to make a "transition phase", in that you greylist 
hosts without rDNS or reject e-mails for an hour with a message that 
they should create a rDNS entry and then allow for an hour... but not 
doing anything because that could possibly upset someone with a 
not-so-clean setup is not on our mind.
Currently, when we have a valid customer w/o rDNS then we whitelist then 
for 14 days, and send an info e-mail to them and their postmaster@, 
with the explanation what to do. Works quite well, very seldom we hear 
again after 14 days that they want to be whitelisted again - and only 
one I had somebody 3x whitelisted ;-)

> I just use a simple perl-script that blocks hosts with iptables. It
> uses File::Tail to monitor log, so blocking is done almost without
> delays. I don't see much point in using postfix to block things,
> since it takes more resources.
> http://hege.li/contrib/smtp_block.pl

That way you cannot even see when a host tried to send an e-mail, which 
makes looking for missing e-mails impossible. If you have a false 
positive, you cannot even look it up in mail logs. That's absolutely a 
no-go for us. Either we accept an e-mail or we reject it - on SMTP 
level. It might be a good idea for hosts that behave very badly though 
(say, both listed on RBLs and no rDNS), but the little overhead 
involved in rejecting at SMTP level is no real ressource pain.

But it's a good start for a daemon :-)

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0676/846 914 666                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: www.keyserver.net                   Key-ID: 1C1209B4

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic