greylite
Bernhard Graf
I see quite a few messages about spam and joe-jobs I would like to
direct your attention to http://mij.oltrelinux.com/net/greylite/ .
In combination with realrcpto patch, mailfront's cvm-validate or
something similar it will keep away the vast majority of unwanted email
from your qmail-queue.
Disclaimer: I discovered greylite yesterday, being in the middle of
setting up a new mailserver, so I didn't test it under heavy load.
Looks very promising so far though.
greylite definitely deserves being mentioned on qmail.org.
--
Bernhard Graf
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Hugo Monteiro
> This program was already announced by his author on this list, but since
> I see quite a few messages about spam and joe-jobs I would like to
> direct your attention to http://mij.oltrelinux.com/net/greylite/ .
>
> In combination with realrcpto patch, mailfront's cvm-validate or
> something similar it will keep away the vast majority of unwanted email
> from your qmail-queue.
>
> Disclaimer: I discovered greylite yesterday, being in the middle of
> setting up a new mailserver, so I didn't test it under heavy load.
> Looks very promising so far though.
>
> greylite definitely deserves being mentioned on qmail.org.
>
Unfortunatelly it's only (very) usable under single server installs. At
least without going over an NFS based solution for database
availability, and that if sqlite supports multiple simultaneous
connections to the same database (i.e. file).
I would also sugest a look at policyd.sf.net. It can be easily
integrated with qmail and works like a charm for systems with multiple
MXs boxes.
my 2¢,
Hugo Monteiro.
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
Bernhard Graf
> I would also sugest a look at policyd.sf.net. It can be easily
> integrated with qmail and works like a charm for systems with
> multiple MXs boxes.
I've had a look at policyd and postfix's policy delegation in general.
Looks quite sexy. I also found your patch against qmail-ldap, but I
wouldn't call it "easy".
For the moment I'll stick with greylite.
Bruce Guenter's mailfront has a nice plugin architecture in the most
recent versions. Writing a policy-plugin seems a reasonable option.
Phil Rhoades
On Sat, 2008-03-08 at 17:52 +0100, Bernhard Graf wrote:
> Hugo Monteiro wrote:
>
> > I would also sugest a look at policyd.sf.net. It can be easily
> > integrated with qmail and works like a charm for systems with
> > multiple MXs boxes.
>
> I've had a look at policyd and postfix's policy delegation in general.
> Looks quite sexy. I also found your patch against qmail-ldap, but I
> wouldn't call it "easy".
>
> For the moment I'll stick with greylite.
> Bruce Guenter's mailfront has a nice plugin architecture in the most
> recent versions. Writing a policy-plugin seems a reasonable option.
I had written my own Ruby/qmail-qfilter spam dropper/rejector that was
pretty much doing what I wanted but after Bernhard's comments about
greylite I decided to check it out and I must say I was pleasantly
surprised. At the moment I am running it in simple "suspicion" mode
(without any other modules eg no dnsbl, ucspi2socket or GeoIP) and it is
still taking out more than 98% of the crap.
After a few more days of testing, I might put back my own stuff to catch
the odd things that get past greylite. Very happy so far!
Regards,
Phil.
--
Philip Rhoades
Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275)
GPO Box 3411
Sydney NSW 2001
Australia
Fax: +61:(0)2-8221-9599
E-mail: ph...@pricom.com.au
dana klein
Hugo Monteiro wrote:I would also sugest a look at policyd.sf.net. It can be easilyintegrated with qmail and works like a charm for systems withmultiple MXs boxes.I've had a look at policyd and postfix's policy delegation in general.Looks quite sexy. I also found your patch against qmail-ldap, but Iwouldn't call it "easy".For the moment I'll stick with greylite.Bruce Guenter's mailfront has a nice plugin architecture in the mostrecent versions. Writing a policy-plugin seems a reasonable option.--Bernhard Graf
Clive Eisen
> This program was already announced by his author on this list, but since
> I see quite a few messages about spam and joe-jobs I would like to
> direct your attention to http://mij.oltrelinux.com/net/greylite/ .
>
> In combination with realrcpto patch, mailfront's cvm-validate or
> something similar it will keep away the vast majority of unwanted email
> from your qmail-queue.
>
> Disclaimer: I discovered greylite yesterday, being in the middle of
> setting up a new mailserver, so I didn't test it under heavy load.
> Looks very promising so far though.
>
> greylite definitely deserves being mentioned on qmail.org.
Thanks for highlighting this
Easy to implement and seems V effective
I've had to whitelist from *@gmail.com as they seem to rotate through a
huge number of IP addresses for sending so it takes ages for a message
to get through if at all.
Other than that it looks very good.
--
Clive
Phil Rhoades
On Tue, 2008-03-11 at 14:34 +0000, Clive Eisen wrote:
> Bernhard Graf wrote:
> > This program was already announced by his author on this list, but since
> > I see quite a few messages about spam and joe-jobs I would like to
> > direct your attention to http://mij.oltrelinux.com/net/greylite/ .
> >
> > In combination with realrcpto patch, mailfront's cvm-validate or
> > something similar it will keep away the vast majority of unwanted email
> > from your qmail-queue.
> >
> > Disclaimer: I discovered greylite yesterday, being in the middle of
> > setting up a new mailserver, so I didn't test it under heavy load.
> > Looks very promising so far though.
> >
> > greylite definitely deserves being mentioned on qmail.org.
>
> Thanks for highlighting this
>
> Easy to implement and seems V effective
>
> I've had to whitelist from *@gmail.com as they seem to rotate through a
> huge number of IP addresses for sending so it takes ages for a message
> to get through if at all.
>
> Other than that it looks very good.
Did you do the whitelisting within greylist?
Regards,
Phil.
--
Philip Rhoades
Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275)
GPO Box 3411
Sydney NSW 2001
Australia
Fax: +61:(0)2-8221-9599
E-mail: ph...@pricom.com.au
Bernhard Graf
> Phil Rhoades wrote:
> > Clive,
> >
> > Did you do the whitelisting within greylist?
>
> yeah
>
> I used a 1 line suspicion file
>
> 0 e s:@gmail.com$
You know, that sender addresses can be forged easily?
Or do you use SPF/DKIM to ensure that mails from @gmail senders really
come from a Google MTA?
Otherwise better look at
http://mij.oltrelinux.com/net/greylite/doc/practmatters.html and
http://mij.oltrelinux.com/net/greylite/files/whitelisted.rules
--
Bernhard Graf
Clive Eisen
> Clive,
> Did you do the whitelisting within greylist?
yeah
I used a 1 line suspicion file
0 e s:@gmail.com$
Bernhard Graf
Clive Eisen
> Clive Eisen wrote:
>
>> Phil Rhoades wrote:
>>> Clive,
>>>
>>
>> I used a 1 line suspicion file
>>
>> 0 e s:@gmail.com$
>
> You know, that sender addresses can be forged easily?
> Or do you use SPF/DKIM to ensure that mails from @gmail senders really
> come from a Google MTA?
nope
>
> Otherwise better look at
> http://mij.oltrelinux.com/net/greylite/doc/practmatters.html and
> http://mij.oltrelinux.com/net/greylite/files/whitelisted.rules
I could indeed - but I'd need to keep the list up to date
If it gets bad I will, but atm I'm getting no *FORGED* from gmail.com
--
Clive
Markus Stumpf
> ... and BTW
> http://www.heise-online.co.uk/news/Spammers-outwit-Google-s-captchas--/110286
This has no effect on the greylister, as the spammers will use the
Google mailservers and thus the mails will come from a legit mailserver
and legit mailservers will always bypass the greylister (which is why
greylisting works).
Greylisting only works for "mailservers" that have a "fire and forget"
strategy for mail delivery.
When I implemented greylisting for a ISP we used a rather huge whitelist
of mailservers constructed from logfiles for the start and added hosts to
the whitelist later with information from the whitelist database. This
way one can easily construct a list of legit mailservers for which
greylisting the traffic (for new triples) is simply an annoyance only.
\Maex
John Simpson
> Bernhard Graf wrote:
>> This program was already announced by his author on this list, but
>> since I see quite a few messages about spam and joe-jobs I would
>> like to direct your attention to http://mij.oltrelinux.com/net/greylite/
>> .
>>
>> In combination with realrcpto patch, mailfront's cvm-validate or
>> something similar it will keep away the vast majority of unwanted
>> email from your qmail-queue.
one thing to be aware of... the author doesn't seem to be willing to
do any real work in response to bug reports. he took two reports from
"qmailrocks" users, who he admits probably didn't know what they were
talking about, and turned it into a blanket condemnation of my
combined patch on his web site- WITHOUT EVER HAVING CONTACTED ME for
help, advice, or just to tell me that a problem existed. i only became
aware of it when one of my users pointed out the last item on his FAQ
page to me.
for the record, i've tried greylite on my own server, which is running
version 7.05 of my combined patch. greylite DOES work as advertised,
WITH MY COMBINED PATCH. it doesn't work (nor can it work) if a
successful STARTTLS command has been sent, but greylite fails
gracefully by dumping into a binary pass-through mode after sending
the server's response to the STARTTLS command (unless that response
starts with a 4 or 5.)
i did find a few MINOR bugs in his code, which are detailed here. i
haven't gone through all of the code yet, but i plan to.
http://qmail.jms1.net/starttls.shtml
i've emailed him about fixing the web page, but he seems to have
decided to ignore me, even though i have proven that his web site is
wrong. maybe if more people start pressuring him about it, he'll take
a few minutes and fix his web site- and who knows, maybe fix the two
bugs i found as well.
i am thinking seriously about not only using it myself, but
recommending it to others. i would like to work WITH him, to make
greylite better, but as long as his web site continues to mislead
people about my combined patch, i can't do so. i have already
explained to him that the error reports which led to that statement
cannot have been correct, however he has chosen to ignore that fact.
which is sad, because so far, greylite looks like a good program.
> Unfortunatelly it's only (very) usable under single server installs.
> At least without going over an NFS based solution for database
> availability, and that if sqlite supports multiple simultaneous
> connections to the same database (i.e. file).
sqlite's documentation says that, as of version 3.3.1, it does handle
concurrent access by multiple processes, and if compiled with a
certain switch, by multiple threads as well. it does specifically
state, however, that the file should not be stored on an NFS-mounted
filesystem.
--------------------------------------------------------
| John M. Simpson -- KG4ZOW -- Programmer At Large |
| http://www.jms1.net/ <jm...@jms1.net> |
--------------------------------------------------------
| Hope for America -- http://www.ronpaul2008.com/ |
--------------------------------------------------------