Milter-greylist

Could you please have an option to allow random SPAM through? Like 10% or every mondays! I feel so lonely now!

     8: DELIVERED MAIL
     4: RETURNED BACK AFTER TEMPFAIL
108000: SENDER/RECIPIENT SPOOF
174000: MILTER-GREYLIST TEMPFAILED


Commands in order (Numbers Rounded Off above except first 2):
egrep 'to=.+stat=Sent$' /var/log/maillog|wc -l
egrep 'autowhitelisted for' /var/log/maillog|wc -l
egrep 'OFF IMPOSTOR' /var/log/maillog|wc -l
egrep 'milter=.+reject=.+00:01:00' /var/log/maillog|wc -l

In order to estimate tempfailed connections, it is important to scan maillog for '00:30:00' (or whatever your delay is) because some mailers will try every minute until greylist expires. For example, for hotmail mail, it will show as 30 in your maillog while essentially it is 1 tempfailed connection retrying. It is also important to include 'milter' in the line, otherwise you have 1 log entry from sendmail and one from milter.

In my mail server, SENDER/RECIPIENT SPOOF above gets 5xx rejected before milter-greylist. They are 100% SPAM without a doubt. For that to work, we had to enable check_compat and put the following in access.db:

Compat:me@...<@>me@...     550 .... OFF IMPOSTOR
From:me@...     OK 
From:my.dom     550 .... OFF IMPOSTOR

me@my.dom is the smtp auth sender from the envelope FROM: . So no relaying here if no smtp auth. I just thought I could share these with you folks.

So all these SENDER/RECIPIENT SPOOF would have been tempfailed by milter-greylist... 282000 SPAM versus 8 legit mails :) Well, actually for testing I removed access.db, iptables, tcpwrappers blocks. But you can understand the suffering we had to go through.




NOWWWWWWWWWWWWWWW..... As for milter-greylist...

More than the program, I would like to thank whoever wrote the README. It took me less than 10 mins to get up and going. I did not spend days wondering like a clueless idiot what to expect. Especially the parts "TRYING OUT FOR FEW USERS" and "RUNNING IT FOR THE WHOLE SITE". Very well done Emmanuel and whoever else contributed.

NOTE: 'acl' is obsoleted i believe. It doesnt make much difference, but references could be replaced in README.


I have few questions:

1. DUMPFREQ/DUMPFILE: Why is this necessary? Is this only necessary in case server crashes? I have 1000+ days uptime on the server so a crash is not every day occurance and a moot point on servers. Or is there any other reason for it like memory consumption gets high and entries are dumped to file to release memory? If not, is it safe to disable it with '-1'?

2. Is it possible to put references to files in greylist.conf? For example, I don't want to meddle with the config file and I want it to read a file for manual whitelisting (say /etc/mail/{whitelist,blacklist}). 

3. Auto whitelisting email addresses that I sent mail to. Since I am expecting a reply, I would like any address I send email to get whitelisted automatically (wherever their IPS might be from). How to do this?

4. It is not possible for me to greylist mail based on RBLs. I would like to scan them first with SpamAssasin and CLAMAV. If SPAM, tempfail. If virii, tempfail. Keep copies if I wanted to. I tried doing this with amavisd-new and amavisd-milter but they seemed too complicated and I am not sure if it can be done. 

Could someone show me a pointer how to do that with milter-greylist? For example, how to use SpamAssasin with milter-greylist?


Thank you many times again.

Okay, compat part got censored. In case someone wants to use, replace '#' with '@':

Compat:me#my.dom<#>me#my.dom 550 .... OFF IMPOSTOR
From:me#my.dom OK
From:my.dom 550 .... OFF IMPOSTOR

me#my.dom is the smtp auth sender from the envelope FROM: . So no relaying here if no smtp auth.

Dropping the following in firewall:

187.0.0.0/8
189.0.0.0/8
200.0.0.0/8
201.0.0.0/8

eliminated 80% of SPAM connections. I have no business in Brasil or from Brasil, so I will keep these iptables rules. These are nasty spam depots, blocking class C's did not help at all since they tried to send the same email from different /16's -- and even /8's.

Is this the right way? I don't really care. Works for me. Sorry for friends in Brasil.

d d wrote:
 > Dropping the following in firewall:
 > 
 > 187.0.0.0/8
 > 189.0.0.0/8
 > 200.0.0.0/8
 > 201.0.0.0/8

That list is incomplete.  Please have a look at this list:

http://www.iana.org/assignments/ipv4-address-space/

It seems you want to block all LACNIC networks.

 > eliminated 80% of SPAM connections. I have no business in Brasil or
 > from Brasil, so I will keep these iptables rules. These are nasty
 > spam depots, blocking class C's did not help at all since they tried
 > to send the same email from different /16's -- and even /8's.
 >
 > Is this the right way? I don't really care. Works for me. Sorry for
 > friends in Brasil.

Well, it's your decision to do that.  If you don't have any
users that care, then go for it.

However, blocking hole /8 networks is not a good idea in
general.  Those networks that you mentioned above are
handled by LACNIC, so most of their blocks are assigned
to South American and Latin American countries (Mexico,
Argentina, Colombia, Brazil etc.).  You're definitely
*NOT* blocking Brazil only, but a whole continent.

Also note that assignments can change at any time.
When IPv4 addresses for a certain RIR run short, blocks
from a different RIR that still has enough space might
be used.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is to C as Lung Cancer is to Lung."
        -- Thomas Funke

On Mon, Oct 12, 2009 at 11:17:27AM -0000, d d wrote:
> Dropping the following in firewall:
> 
> 187.0.0.0/8

Not all of that is in Brazil, for example:
187.160/12 is routed to Mexico.

And others will be routed to other South or Latin America countries,
as those are LACNIC networks (LACNIC = Latin and Caribbean NIC)

> 189.0.0.0/8
> 200.0.0.0/8
> 201.0.0.0/8
You can skip one line by using 200.0.0.0/7 ;-)

> 
> eliminated 80% of SPAM connections. I have no business in Brasil or from Brasil, so I will keep these iptables rules. These are nasty spam depots, blocking class C's did not help at all since they tried to send the same email from different /16's -- and even /8's.

I know what you mean, looking at my spam stats, I see that Brazil is one
of the top sources of spam.

But I don't block completely on IP level, I use country-based DNS blacklists
instead, in this case: br.countries.nerd.dk .
I never had a false positive with the blacklists under .countries.nerd.dk.

> Is this the right way?
Not really, as you're blocking not only Brazil.
And you're are probably also not blocking all of Brazil, there may be more
assignments.

> I don't really care. Works for me. Sorry for friends in Brasil.
It's always your choice ;-)
But why do you ask, if you don't care?

-- 
Ralf 'Snake' Gebhart

> That list is incomplete.  Please have a look at this list:

I am not looking for the complete list.

> However, blocking hole /8 networks is not a good idea in
> general.  Those networks that you mentioned above are
> handled by LACNIC, so most of their blocks are assigned
> to South American and Latin American countries (Mexico,
> Argentina, Colombia, Brazil etc.).  You're definitely
> *NOT* blocking Brazil only, but a whole continent.

I blocked these subnets based on last 3 months' logs. *All* of them are from Brasil with absolutely no single connection to my mail server from anywhere else. Besides, I have no business from anywhere in Latin America in general. Therefore I can afford to block /8 instead of blocking 500 different class Cs that keep changing all the time.

I didn't go ahead and block all of LACNIC or all of Brasil IPs (if they have any other) -- rather, I scanned my own mail logs and deduced it would be best to block these 4.

I was at such a point where it would be best to turn off the mail server altogether and let users find other means of communication... So I don give a ****** **** about someone being blocked out of the 5 million connections coming to my server from latin america.

> > I don't really care. Works for me. Sorry for friends in Brasil.
> It's always your choice ;-)
> But why do you ask, if you don't care?

Ralf, it was a rhetorical question :) Don't really care if there is an answer since deed is done!

#####
> 4. It is not possible for me to greylist mail based on RBLs. I would like to scan them first with SpamAssasin and CLAMAV. If SPAM, tempfail. If virii, tempfail. Keep copies if I wanted to. I tried doing this with amavisd-new and amavisd-milter but they seemed too complicated and I am not sure if it can be done. 
> 
> Could someone show me a pointer how to do that with milter-greylist? For example, how to use SpamAssasin with milter-greylist?
#####

Yahoo is not quoting properly. Anyway, I am calling clam from spamassassin. So this issue is resolved also with milter-greylist. If virii, tempfail. If SPAM, tempfail. Others go through.

Any solution for penpal feature?

d d <x55k@...> wrote:

> Is this the right way? I don't really care. Works for me. Sorry for
> friends in Brasil.

milter-greylist has GeoIP support (must be enabled at configure time),
you might want to give it a try:

racl block geoip "br" msg "I do not speak to Brasil"

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

--- In milter-greylist@yahoogroups.com, "d d" <x55k@...> wrote:
>
> > > I don't really care. Works for me. Sorry for friends in Brasil.
> > It's always your choice ;-)
> > But why do you ask, if you don't care?
> 
> Ralf, it was a rhetorical question :) Don't really care if there is an answer since deed is done!
>

I generally don't comment, instead reading the list to pick up when I need to make updates...

d d, isn't the greylisting properly blocking the spam from Brazil?  Since I implemented greylisting over a year ago, the spam that has gotten through has been minimal.  I used to have a block policy similar to yours, although a bit more discriminating (I wrote a program that would identify the specific IP range from which the spam originated by doing a whois lookup on lacnic, apnic, etc, and then blocking that range for a period of time based on certain rules -- in some cases permanently, and in some cases temporarily.) but since installing fail2ban, this system is effectively deprecated on my machine.

> --- In milter-greylist@yahoogroups.com, "California_Condor"
> d d, isn't the greylisting properly blocking the spam from Brazil?

Yes it is. I, nonetheless, do not want to keep 2GB monthly maillog of Brasil on my 9GB hard drive. So, I drop them off with IPtables and not log.