[qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[Scott D. <SD...@Es...>]

Proposed Project Summary:

Create a web interface to SpamAssassin userprefs (and more) that
end-users or postmasters can utilize.  

This interface could be bundled with or into QmailAdmin.  I spoke with
Tom Collins about this on the phone - he's not opposed to the idea.

Packaging for RedHat, Debian and BSD style systems should be created.

Extensive documentation should be created.  (a la Like Matt Stimpson and
others? 'qmail toasters')




Reason:

Spam is on the rise.  Spam Sucks.  SpamAssassin kills spam well.
Configuring SA is very time consuming for help-desk staff in small-mid
size ISPs.

The installation of SpamAssassin is well documented and quite effective
for smaller user communities.  A configuration interface for SA
userprefs that can be utilized in a medium to large environment by the
average end-user is desired.  Configuration via shell and text editors
is too complex for most end-users.

SpamAssassin has many features that most end-users will want (or need!)
to take advantage of.  There isn't an easy-to-use interface that lets
end-users control their individual SA settings at this time.  For
extremely small sites this isn't a problem.  For the medium or large
size ISP with several hundred or thousand mailboxes and dozens or
hundreds of email domains, the support time and cost required to
successfully deploy SA is impractical at this time.




I suggest that these are the critical SA features that should be
incorporated in this design:

(note: these features should be configurable to apply to either the
entire mail system, per-domain or per-user..)

- Creation and modification of whitelists.
- Creation and modification of blacklists.
- Control over the score that determines if an email is spam or not.
- provide an interface to the trainable Bayes db.
- Provide a system-enabled action (be it delete, fwd to another mailbox
or move into a specific folder) that does not require interaction with
end-user email client settings.  (I suggest fwd: to a spambin mailbox,
which is auto-purged by the mail system.  i.e. delete all mail older
than x days)
- Provide a default configuration that is effective and end-user
friendly.  Auto-welcome to the system email with documentation and tips
to be included.  Customizable on a per-domain basis.



Secondary, important features that should be incorporated as the system
evolves:

- Provide control of which (if any) rbls are enabled.
- Provide control of which DCC systems are used.
- Provide a facility for anti-virus scanning and reporting.
- Provide reports to show usage, per-domain/user.  Link to MRTG?
- Possibly provide a notification mechanism (pager/email) if significant
deviation from stastical norms occurs.  I.E. client b starts sending
3000 emails/hour - indicating virus activity or a spam blast in
progress.



Comments from the folks that want to help build this interface:

My name is Scott Davis.  I live in Toronto, Ontario, Canada.  I've been
doing volunteer work for a small ISP here - attempting to implement SA.
SA is installed and will work, but we can not release it to our clients
at this time because of the support burden it would place on our
technical staff.

Generally, the ISP in question wants to give back to the developer
community.  We would like to see an easy-to-use end-user oriented
interface to this system.  We would like to volunteer time and (limited)
application development knowledge towards accomplishing the task.  

I'm new to this open-source development stuff.  You can reach me via the
list, or (416) 481-9794 if you're in North America.  If you want to talk
- just give me a call and I'll call you back.

Thanks!

Scott Davis.