Milter-greylist

Hi all,

At home I run postfix as my MTA and I use 'gps' (the greylisting 
policy service) for greylisting. A feature that I really enjoy there 
which I think I could benefit with here at work is 'reverse 
greylisting' Full details are available on the gps web page:

http://mimo.gn.apc.org/gps/

Basically I've had some trouble with milter-greylist and Gmail's many 
email servers. I don't want to whitelist anything from gmail.com, but 
I think the idea of gps's reverse greylisting would be very helpful, 
especially considering the automatic fallback to weak greylisting 
(also explained on the page).

Can this be done with milter-greylist? If not, is it a feature worth 
requesting?

Collin

Collin Baillie <collin@...> wrote:

> http://mimo.gn.apc.org/gps/
(snip)

I sum it up for other readers:
greylist using (domain name of sender machine, sender e-mail, receiver
e-mail) instead of (IP, sender e-mail, receiver e-mail). eg: (yahoo.com,
sender@..., user@...)

> Can this be done with milter-greylist? If not, is it a feature worth 
> requesting?

The idea is interesting, but doesn't that let much more spam from
botnets? Zombies connected from the same ISP will have similar tuples.

About implementing it: contributed code is welcome, but please discuss
here how you are going to do it, especially on the configuration file
format front.

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

At 13:17 4/05/2007, manu@... wrote:

>I sum it up for other readers:
>greylist using (domain name of sender machine, sender e-mail, receiver
>e-mail) instead of (IP, sender e-mail, receiver e-mail). eg: (yahoo.com,
><mailto:sender@...>sender@..., 
><mailto:user@...>user@...)

Well, your example isn't technically correct. It would be more likely 
eg of "dyn-ip.adsl.isp.com", "spoofed.address@...", "victim@..."

Since the reverse lookup is done on the IP of the sending 'MTA'.

> > Can this be done with milter-greylist? If not, is it a feature worth
> > requesting?
>
>The idea is interesting, but doesn't that let much more spam from
>botnets? Zombies connected from the same ISP will have similar tuples.

The zombies aren't really zombies though are they? Maybe if they're 
virus-compromised machines, but the chances of more than one machine 
in the same ISP being infected with the same virus which is sending 
out the same 'from' address, is very very low. And as for spammers, 
how often do they send using the same 'from' address (ie they tend to 
generate random addresses)? How often to they send more than one span 
from the same address to the same address?

It is call _weak_ greylisting for a reason ;), but I've never had any 
problem with it in the year or so I have been running it on my domain.

>About implementing it: contributed code is welcome, but please discuss
>here how you are going to do it, especially on the configuration file
>format front.

I am not a coder, so I have no idea where to start. My coding skills 
are 2nd year univeristy and very rusty :D

Collin

Hi weak greylisting is possible with the -L option or with subnetmatch in greylist.conf The reverse greylisting is not possible with milter-greylist as far as

On Fri, May 04, 2007 at 02:53:17PM +0800, Collin Baillie wrote:
> The zombies aren't really zombies though are they? Maybe if they're 
> virus-compromised machines, but the chances of more than one machine 
> in the same ISP being infected with the same virus which is sending 
> out the same 'from' address, is very very low. 

I would not bet on that. The zombies are tightly controlled, and the
spammer can command them to do it if it works around a pam filter.

-- 
Emmanuel Dreyfus
manu@...

At 15:13 4/05/2007, Michael Menge wrote:
>Hi
>
>weak greylisting is possible with the -L option or with subnetmatch in
>greylist.conf
>
>The reverse greylisting is not possible with milter-greylist as far as i know.
>I don't see the advantage form reverse greylisting over the
>subnetmatch (weak greylisting). Could you give us an example where
>reverse would be of use and a subnetmatch not?


I had considered using -L, and now that you raise it, I may look 
closer at it. The difference of course is that if you use -L 24, you 
accept a whole 'C class' block (ie 255 hosts). Most people won't have 
255 email servers, and if they do, they're probably not all stuck on 
the same 'subnet' or 'C class' network. Doing reverse lookups and all 
the IPs used by a cluster of email gateways for a large provider (ie 
google, yahoo etc) and they *should* all resolve back to the same domain.

Blindly accepting 255 hosts sounds less intelligent (to me) than 
blindly accepting from all IPs which resolve to the same domain 
(sending from the same address to the same address). Yes it opens up 
_possibilities_ for abuse, but how would someone who may have an IP 
address which resolves to the same domain as a real email server, 
know the sender address and recipient address of those real email 
servers? Once again, how many spammers or viruses send from the same address?

As it stands I am whitelisting everyone in our organisation who uses 
gmail to commuicate with the internal network. However, this is going 
to be a pain I think, as we experience fairly frequent changes in staffing.

Collin

Collin Baillie schreef:
> 
> 
> At 15:13 4/05/2007, Michael Menge wrote:
>  >Hi

What you are trying to do sounds a lot like the urlcheck I wrote and 
emailed to the mailing list.

https://webmail.coltex.nl/spam/mxhostcheck.php?domain=zaobao.com.sg&ip=83.30.109.104&fuzz=22&delay=9

Pass it the sender domain, the sender ip, the subnet match (like -L), 
and how long the greylist timeout must be if it does not match.

Experiment with the options a bit.

If you just use a browser you can see exactly what I'm doing.

Cheers,

Seth

Hi, ... If you whitelist by IP you can specify the netmask so you can whitelist 1,2,4,8,...256,....all IPs if you want. The -L option is only for greylistet

>subnetmatch (weak greylisting). Could you give us an example where
>reverse would be of use and a subnetmatch not?

Yup. Right now, I'm experiencing problems with emails from Gmail. In 
the logs, the from IPs come from:

wr-out-0506.google.com[64.233.184.228]
nz-out-0506.google.com[64.233.162.229]
mu-out-0910.google.com [209.85.134.188]
an-out-0708.google.com [209.85.132.251]

and so on. If I could use the reverse greylisting, which should 
truncate the names to google.com, they would all work nicely together.

Collin

On Fri, May 04, 2007 at 04:45:42PM +0800, Collin Baillie wrote:
> wr-out-0506.google.com[64.233.184.228]
> nz-out-0506.google.com[64.233.162.229]
> mu-out-0910.google.com [209.85.134.188]
> an-out-0708.google.com [209.85.132.251]
> 
> and so on. If I could use the reverse greylisting, which should 
> truncate the names to google.com, they would all work nicely together.

But why do you want to greylist mail comming from Google mail farms? 
Since that mail is from a legitimate machine, you don't want delays,
you'd be better whitelisting it.

racl whitelist domain /-out-[0-9]\{4\}\.google.com/

-- 
Emmanuel Dreyfus
manu@...

At 15:13 4/05/2007, Michael Menge wrote:
>Hi
>
>weak greylisting is possible with the -L option or with subnetmatch in
>greylist.conf
>
>The reverse greylisting is not possible with milter-greylist as far as i know.
>I don't see the advantage form reverse greylisting over the
>subnetmatch (weak greylisting). Could you give us an example where
>reverse would be of use and a subnetmatch not?
>
>regards

Ok, after more experience with milter-greylist, I can agree that 
subnetmatch would work like weak greylisting.

However, weak greylisting (you may remember from reading the gps web 
page) is the last resort fallback for reverse greylisting failure.

Reverse greylisting is advantageous where (of course) a mail farm 
includes servers not on the same 'subnet'. Say I have a couple of 
servers 203.11.234.15, and 203.11.234.16 and I have 3 servers in 
64.117.82.98, 64.117.82.112 and 64.117.82.113, but they all resolve 
backe to mail*.my-odd-domain.com. NO decent subnet match would work 
in this case, where reverse greylisting would. Of course, if I don't 
have the reverse lookup of those servers working, the _fallback_ to 
weak or subnet match greylisting would fail.

Right now (Milter greylist 3.1) I can do

acl whitelist domain my-odd-domain.com

and everything get's through without being greylisted. But what if 
this was a public ISP which sold broadband services, and a spammer 
bought bandwidth from them. Suddenly I'm faced with, either receiving 
spam straight in, or losing valid emails because the server farm is 
from a very diverse IP range.

If Milter-greylist had reverse greylisting, if 
person.a@... emails me (thrugh the ISPs SMTP servers), 
their address, my address and the my-odd-domain.com triplet would be 
greylisted and eventually deliver. However if the spammer bulk emails 
me from his my-odd-domain.com broadband connection, the 
spammer@... address, my address and the my-odd-domain.com 
triplet would be greylisted, and effectively denied because his bulk 
email software performs true to form.

Reverse greylisting removes the need for (a) whitelisting domains, 
and (b) using a subnetmatch clause (unless the reverse lookup fails) 
and achieves fully functional greylisting not possible with any 
combination of whitelists/subnet matches.

Collin

Collin Baillie <collin@...> wrote:

> Reverse greylisting removes the need for (a) whitelisting domains, 
> and (b) using a subnetmatch clause (unless the reverse lookup fails) 
> and achieves fully functional greylisting not possible with any 
> combination of whitelists/subnet matches.

Well, I guess nobody opposes to the addition of fancy features. 4.0
alpha has become more a kind of swiss-knife anti-spam tool than just a
greylist filter. After all, nobody have to use new features.

Perhaps someone will want to code the feature. Usually, my only concern
is about preventing the config file to become even more messy than it is
now. What syntax would you propose for configuring reverse greylisting
in greylist.conf?

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

>now. What syntax would you propose for configuring reverse greylisting
>in greylist.conf?

Probably something simple like;

method normal|reverse


and if fallback to subnetmatch was implemented in the event of 
reverse lookup failure, then that too could be optional using:

reverse_fallback yes|no

and if 'yes' then subnetmatch would also have to be set.

I haven't a clue how to implement any of this though. It's been a 
long time since I was at uni, and my C/C++ skills aren't worth talking about :\

Collin