Milter-greylist

i found a mention of blacklist in greylist.conf(5) but that was it.

On Thu, Dec 21, 2006 at 12:57:08PM -0000, c.r.p. wrote:
> i found a mention of blacklist in greylist.conf(5) but that was it.

You can configure milter-greylist to permanently reject messages. Example:

acl blacklist addr 192.0.2.0/24 msg "go away, you naughty spam punk!"

-- 
Emmanuel Dreyfus
manu@...

--- In milter-greylist@yahoogroups.com, Emmanuel Dreyfus <manu@...> wrote:
>
> On Thu, Dec 21, 2006 at 12:57:08PM -0000, c.r.p. wrote:
> > i found a mention of blacklist in greylist.conf(5) but that was it.
> 
> You can configure milter-greylist to permanently reject messages.
Example:
> 
> acl blacklist addr 192.0.2.0/24 msg "go away, you naughty spam punk!"
> 
> -- 
> Emmanuel Dreyfus
> manu@...
>
Which is why I'm interested in a man page that spells out that
blacklist does not do DISCARDing , and that 
it does not populate a table so that blacklisting a honeypot account
will not do any real good.

It would be nice if blacklisting would work similiar to greylisting so
that it would populate the badSender table that greylisting does. As
it is now, 'blacklisting' seems to really be an automatic REJECTer.


as an aside - we got swamped with attempted spam last week and I
happened to be checking our network firewall for something else when I
noticed that the spammers were not using MX records. They were sending
 mail to all our IP's port 25. Setting up the firewall to block any
site that sent mail to an IP address that was not a mailserver lead to
a massive decrease in spam traffic. 
It would be nice if blacklist had an option that could populate an
iptable chain or access file or send the offending ip address to a
public SpamHaus type list.

On Fri, Dec 22, 2006 at 01:29:45PM -0000, c.r.p. wrote:
> Which is why I'm interested in a man page that spells out that
> blacklist does not do DISCARDing , and that 
> it does not populate a table so that blacklisting a honeypot account
> will not do any real good.

Update to the man page are welcome...

> It would be nice if blacklisting would work similiar to greylisting so
> that it would populate the badSender table that greylisting does. As
> it is now, 'blacklisting' seems to really be an automatic REJECTer.

Is milter-greylist of any interst for that? Just forward mail sent to
the honneypot address to a program that perform the blacklisting 
operation. 

> as an aside - we got swamped with attempted spam last week and I
> happened to be checking our network firewall for something else when I
> noticed that the spammers were not using MX records. They were sending
>  mail to all our IP's port 25. Setting up the firewall to block any
> site that sent mail to an IP address that was not a mailserver lead to
> a massive decrease in spam traffic. 

Hey, don't block them, let them fill a blackhole: they'll waste CPU cycle
instead of moving to someone else"s server


-- 
Emmanuel Dreyfus
manu@...

On Fri, 2006-12-22 at 13:36, Emmanuel Dreyfus wrote:

>> It would be nice if blacklisting would work similiar to greylisting
>> so that it would populate the badSender table that greylisting does.
>> As it is now, 'blacklisting' seems to really be an automatic
>> REJECTer.
> 
> Is milter-greylist of any interst for that? Just forward mail sent to
> the honneypot address to a program that perform the blacklisting 
> operation. 

I can respond to this, since it's a feature that I am very much
interested in. In fact, this feature is the reason I subscribed to the
group -- been lurking to get a feel for the community and see if anybody
else mentions the same idea. I guess now's the time.

The idea I was toying with was this: if the milter receives mail for the
bogus address (presumably an address hidden on our homepage along with
legit addresses), it rejects in the same way as if it were greylisting,
but silently adds the sender IP to the blacklist for a period. When the
same spammer retries, all their mail is rejected outright. Looking at my
mail logs makes me think that this would be quite effective.

The reason for pretending to greylist is to prevent the spammer from
discovering what the bad address is. Perhaps that's not worthwhile.

Thinking further, I suppose I could whitelist the bogus address and have
some other milter handle the auto-blacklist. But then it must either
accept or reject the mail. So mail sent to the honeypot address is
treated differently than that sent to other addresses, making discovery
of which address causes blacklisting relatively easy. Again, maybe
that's not worth worrying about, but I prefer not to give spammers any
clue about how to circumvent my defenses.

According to Alan M. Evans:
> I can respond to this, since it's a feature that I am very much
> interested in. In fact, this feature is the reason I subscribed to the
> group -- been lurking to get a feel for the community and see if anybody
> else mentions the same idea. I guess now's the time.
> 
> The idea I was toying with was this: if the milter receives mail for the
> bogus address (presumably an address hidden on our homepage along with
> legit addresses), it rejects in the same way as if it were greylisting,
> but silently adds the sender IP to the blacklist for a period. When the
> same spammer retries, all their mail is rejected outright. Looking at my
> mail logs makes me think that this would be quite effective.

me too. look at the archives, I've mentionned that some months ago, and
even more. Look for autoblack.
I've received bad feedbacks from Manu so I planed to add it myself,
which I nearly did but due to lack of time to finish the thing (and m-g
evolving quickly at the same time), I gave up. I've now dropped it completly
during an upgrade to gain a feature.
I ended up with plenty of blacklist rules, all acting as grey. That's tons of
spams blocked for good but that requires some log monitoring and manual
black list rules. Could have been better at low cost for m-g.
I don't want to add another link to Bind by creating a local RBL (even if
I already have plenty of nsupdate/dyn-zones in place).
nor do I want to add yet another milter or layer on top of milter, it's
already a maze.

> The reason for pretending to greylist is to prevent the spammer from
> discovering what the bad address is. Perhaps that's not worthwhile.

That's why I always use blacklist with code and ecode, (and flushaddr).

list "spam traps" rcpt { \
  .. all my honeypots here
}

acl blacklist list "spam traps" \
        code    "451" \
        ecode   "4.7.1" \
        msg     "Greylisting in action, please come back later" \
        flushaddr

That way, greylist.db is relatively free from those ugly spammers and my
honeypots are not exposed either. you still let some spams pass from those
guys but with blacklist+451+flushaddr and greylist as default, that's
good enough for me at the moment.

> Thinking further, I suppose I could whitelist the bogus address and have
> some other milter handle the auto-blacklist. But then it must either
> accept or reject the mail. So mail sent to the honeypot address is
> treated differently than that sent to other addresses, making discovery
> of which address causes blacklisting relatively easy. Again, maybe
> that's not worth worrying about, but I prefer not to give spammers any
> clue about how to circumvent my defenses.

You can still follow the path of monitoring the logs and populating
a DNS zone that g-m could use as a DNSRBL. Depends on your local constraints.

/Fabien

Fabien Tassin <fta+miltergreylist@...> wrote:

> I've received bad feedbacks from Manu

Is "bad feedbacks" a synonym for "no time to implement it myself, but
feel free to do it"? :-)

> I ended up with plenty of blacklist rules, all acting as grey. That's tons of
> spams blocked for good but that requires some log monitoring and manual
> black list rules. Could have been better at low cost for m-g.

Let's try to move forward on the autoblack idea: what would you expect
it to do? Do you want to feed a DNSRBL? Do you want to start refusing
any mail coming from the sender IP for some period?  

I'm not against the idea, but I'd like the mecanism to be general enough
to satisfy any use. 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

--- In milter-greylist@yahoogroups.com, manu@... wrote:
> 
> Let's try to move forward on the autoblack idea: what would you expect
> it to do? Do you want to feed a DNSRBL? Do you want to start refusing
> any mail coming from the sender IP for some period?  
>

I have been giving autoblacklisting a lot of thought, so please allow
me to give my ideas about this topic.

Currently, I run a setup with a 'honeypot' account; an account that I
have deliberately published on the web to attract spam, but that will
never receive a legitimate email message.

So far, I have been using the incoming undetected spam to train the
Spamassassin Bayesian filter ('train-on-error'). This has proven very
effective, especially with the honeypot account running with less
greylisting delay than the normal user accounts. The reduced delay
makes sure any spam training will have taken place before the spam
gets delivered to the regular accounts.

To take this approach one step further with milter-greylist, my
suggestion is to include the option to work with a honeypot account,
and use the connecting IP addresses to automatically build a black
list (which will expire within a given number of days to avoid the
list growing out of control).

I expect autoblacklisting in combination with greylisting to be
extremely effective. Spam assaults from a particular (hijacked) host
seem to come in mega-bursts, with hundreds of messages sent to a wide
range of users on my machine. In all cases both sender and receiver
addresses vary, as does the message. The common thread is the fact
that they come from a single host.

By delaying the user accounts for a little while, while allowing the
honeypot account to build its black list in real time, these bursts of
messages should effectively be countered.

I am very excited about the idea and love to hear any reactions.

Rudy.

reschauzier <reschauzier@...> wrote:
 
> To take this approach one step further with milter-greylist, my
> suggestion is to include the option to work with a honeypot account,
> and use the connecting IP addresses to automatically build a black
> list (which will expire within a given number of days to avoid the
> list growing out of control).

As of today you can do that by feeding a local DNSRBL and using it
within milter-greylist. What's wrong withthis approach, and what would
we win with having milter-greylist doing the job?

Is it to avoid the greylisting delay before your DNSRBL feeder sees the
message? Then perhaps hacking a plugin to the urlcheck feature would
make the deal:

urlcheck "autoblack" "http://www.example.net/blacklist.cgi?addr=%i" 5
acl greylist rcpt "spamtrap@..." urlcheck "autoblack" flushaddr

Then blacklist.cgi gets the sender IP in addr and can feed a DNSRBL on
first send, without suffering the greylisting delay. 

NB: urlcheck is available in CVS version.
 
> I expect autoblacklisting in combination with greylisting to be
> extremely effective. Spam assaults from a particular (hijacked) host
> seem to come in mega-bursts, with hundreds of messages sent to a wide
> range of users on my machine. In all cases both sender and receiver
> addresses vary, as does the message. The common thread is the fact
> that they come from a single host.

Hmmm... They use botnets, they can attack from thousands of different IP
at once, and they probably will soon.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...