Re: Disabling SPAM filters in plugin

[Venge <ve...@in...>]

True,
    But procmail rules even the simplest form can give the benefits of speed
and reliability. Here would be a simple end to procmail filters:

http://jello.intac.net/devel/procmail/test.rc
http://jello.intac.net/devel/procmail/list.php3
http://jello.intac.net/devel/procmail/list.phps

I use alot of system command and i'm sure there are better ways to do it in
php.. but thats a start :)

The only drawback of php is that files seem to need to run as the httpd user
(apache here). I changed that by adding the following line to my real
~/.procmail.rc :

INCLUDERC=$HOME/procmailrc-web

Then in the MAILDIR to be your IMAP storage folder (since i use UWIMAP i use
the .webmail directory)

I know procmail can get rather complex, but even just simple Header and Body
filters can prove very useful against spam. My other idea was adding some
sort of continuous count of how many times a filter was acutally accounted
for. When a certain point was reached it would email the sysadmin with the
offending content and they can decide to add it to the system wide
procmailrc or the mail daemon's block list

~venge
----- Original Message -----
From: "Chris Moffitt" <ch...@mo...>
To: <squ...@li...>
Sent: Saturday, June 16, 2001 3:05 PM
Subject: Re: Disabling SPAM filters in plugin


> I agree that it would be cool to have a web front end to procmail.  I even
thought about it a little bit.  The problem I see is that the rules can be
so complex (herein lies the power of procmail though).
>
> I did do some searching on the web for alternatives to procmail.  A simple
(but pretty powerful) option I found was called pycmail -
> http://melkor.dnp.fmph.uniba.sk/~garabik/pycmail.html
>
> It is written in python and is amazingly small.  I've played with it a
little bit and it appears to work as advertised.  It sends to both mailboxes
and maildirs (which is great for us courier users).  The thing that I really
like about this filter package is how easy it is to read/write the rules (as
a human).  Here's an example from the package-
>
> md = USERHOME+"/Mail/"
>
> # well-known spammer
> if Contains(FROM, "sp...@ya..."):
>     Junk()
>     Stop()
>
> # sort mailing list: ba...@vi... is the address, it can be either
recipient
> # or in Cc:
> if "ba...@vi..." in ADDRLIST_TO+ADDRLIST_CC:
>     Set(MailBox(md+"bablo"))
>     Stop()
>
> # better handled mailing list, it has header X-Mailing-list
> # we write it to the mailbox and forward to a friend who was too lazy to
subscribe by himself
> # (this is better for the network, too...)
> if InHeader("X-Mailing-list", "debian-devel"):
>     Set(MailBox(md+"debian-devel"),
>         Forward("kri...@dm..."))
>     Stop()
>
>
> In my mind, these rules are easier to read than procmail.  It also seems
like it would be a little easier to write a configuration script to generate
these rules.
>
> The downside to this software is that it doesn't have the robust spma
filtering capabilites pre-built like procmail does.  Of course it's open
source so someone could always add more functionality if they wanted to.
>
> Just thought I'd throw it out there.  I might be willing to help,  but my
php skills are not that strong.  However, in my mind this doesn't
necessarily have to be php, it could be any cgi-bin setup, therefore it
would apply more broadly than just Squirrelmail...  Just my ramblings.  I do
think we should concentrate our efforts on some sort of functionality along
these lines.  The filter plugin just seems to be a sub-optimal solution(no
offense to the developers of SM or the plugin)!
>
> -Chris
>
>
> > Most sysadmin's including myself automatically turn on the blacklists.
> > The only one I am not a fan of is ORBs due to how harse it can be. The
> > problem I see with the current SPAM filters is that I don't see any
> > kind of folder listing when they are turned on. Mail does seem to get
> > filtered but not being able to see your folder list defeats the purpose
> > :).
> >
> > I was trying to write a procmail webrc that would allow the user to
> > write simple promailrc rules that would increase the speed and
> > functionality of filters. Since procmail gets called as the local
> > mailer (if you are using it of course) then the user could never see a
> > bit of spam. Allow the user to have the options to click on a piece of
> > mail and reject by: From: Subject: or words in the body. The best thing
> > about a procmail based filter would be that you could ship the
> > offending email off to /dev/null and the user would never see the mail.
> > I started to write this, but my php skills are lacking. I have the idea
> > there, just can't execute. Anybody wanting to help with this or dicuss
> > some ideas let me know.
> >
> > Thanks
> > Venge
> > ----- Original Message -----
> > From: "Brent Bice" <bb...@pe...>
> > To: <squ...@li...>
> > Sent: Friday, June 15, 2001 4:54 PM
> > Subject: Disabling SPAM filters in plugin
> >
> >
> >> > Perhaps it would be best if Brent could post his latest version
> >> > (which apparently works with 1.1.2) with the SPAM filters turned off
> >> > (since
> > they
> >> > have a nasty bug in them anyway)...
> >>
> >>     Well, I could certainly post the latest version and call it 0.71
> >>     or
> >> something (grin).  Disabling the FUNCTIONING of the SPAM filters (just
> >> to avoid the endless loop) would be relatively simple.  I'm not sure
> >> how painful it would be to also HIDE the SPAM filters in the options
> >> page.
> > I'll
> >> take a look at it later today and/or over the weekend.
> >>
> >>    I think I'm gonna be learning the IMAP protocol over the weekend so
> >>    I
> >> can suss out how to formulate an IMAP query from the filters plugin
> >> and try to rewrite the SPAM filtering bit. I might be able to make it
> >> a bit faster too.  I'll keep you all posted...
> >>
> >>    As an aside, there is one NICE thing about having client-side SPAM
> > filters
> >> to consider.  Even though I have all but ORBS turned on here too
> >> (grin), I often find SPAM that have been relayed through a new open
> >> relay that
> > wasn't
> >> in any of the databases.  But by the time I unwedge my SPAMbox -- er,
> >> I
> > mean
> >> my INBOX (grin) -- many of these open relays have been added to ORBS
> >> or RSS, and squirrelmail would dutifully filter 'em.  The same holds
> >> true for IPs that were added to DUL after my firewall had received a
> >> SPAM, but
> > before
> >> I opened my mailbox.  My only quibble was with it checking every IP in
> >> the header rather than just the IP my firewall received the message
> >> from.
> >>
> >> Brent
> >
>
>
>
> --
> SquirrelMail Plugins Mailing List (http://www.squirrelmail.org)
> Archives: http://www.squirrelmail.org/plug_archives.php
> Unsubscribe: http://www.squirrelmail.org/plug_admin.php
>