Using p0f in greyllisting?

Simon Waters wrote the following on 01/11/2006 09:13:
> 
> Whilst I like the idea, my gut instinct is too many
weak proprietary operating 
> systems lurk behind devices with nice solid free
software kernels doing NAT 
> and other fancy stuff to the IP protocol, to make OS
detection that useful.

So rather than greylisting on a specific OS, configure to
not greylist when it is a selected OS.

I think my preference would be to greylist all unknown OS's
and all Windows OS's except 2000 (but that might change ).

> Certainly what nmap tells me a fair chunk of the time,
and its OS detection is 
> better than passive OS detection.

That may be, but from what I can see with p0f and
amavisd-new, its good enough.
 
> i.e. not greylisting most stuff will get you more spam,
for more effort.

Maybe but we not trying to stop real MTA's here.

The other side of this is that we have the task of
continually reviewing the logs for, or more commonly,
reacting to clients complaints because they have not
received a mail from someone because the ISP does not run
its mail servers as we expect (no retry, long delay, etc.).
So we are continuously having to maintain the whitelists.
Using a p0f approach would potentially relieve us of the
need to whitelist anything. 

Another thing that has me thinking that this is a good idea
is, from reviewing the postgrey delayed log messages, that
almost all those mails that are attempted to be delivered
within a few seconds of my configured delay value show signs
of being from botnet addresses. This leads me to believe
that some of the pump-and-dump smtp engines will wait and
re-connect when the postgrey delay is less than the max
delay they are prepared to wait.

Alan




-- 
Unsubscribe mailto:postgrey-requestlist.ee.ethz.ch?subject=unsubscribe
Archive     http://lists.ee.ethz
.ch/postgrey
WebAdmin    http://lists.ee.ethz
.ch/lsg2.cgi