You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Jens E. Madsen Jr." <sj...@higher-speed.net> on 2004/02/13 22:19:59 UTC
Approaches to handling mail lists
Dear Spamassassin User List,
Thanks for the excellent program. It has proven to be very effective.
I am looking for a good way to handle mail list that go through
spamassassin. It should be able to handle both moderated and unmoderated
lists. It should also be user configurable so that I do not have to
change the system configuration file each time a user adds a mail list.
I currently provide procmail to filter either the tag in the Subject
line or the list id in the header to sort into my mail list buckets for
the users here. This is done at the user level. Subject tags always work
even if spamassassin tags it as spam. The List id is lost in the
attached spam email. I would like to have the mail list filter all mail
into the mail list bucket, even if it is spam.
In a previous thread some one mention using the following:
whitelist_from_rcvd *@incubator.apache.org
to white list all mail for spamassassin and I can easily show my users
how to do this. This should allow those user that are listed in RBLs or
whose mailer isn't liked by spamassassin to make it into the bucket.
My concern now is for the unmoderated or unfiltered mail list. How can I
put the mail into the correct bucket and tag the real spam as spam?
We do not mind having FPs since we do not use spamassassin to delete
mail, through procmail of course.
What would be nice is a user configurable option such as maillist that
could have a user set value, say -4, and not the -100 from whitelist.
Thanks,
Jens
Re: Approaches to handling mail lists
Posted by Matthias Fuhrmann <Ma...@stud.uni-hannover.de>.
On Sat, 14 Feb 2004, David B Funk wrote:
> On Fri, 13 Feb 2004, Matt Kettler wrote:
>
> > whitelist_from_rcvd *@incubator.apache.org incubator.apache.org
> >
> > But note, this will only match email which is FROM *@incubator.apache.org,
> > ie: not the mailing list..
>
> Actually with two changes that whitelist does work nicely for mail
> that I receive from this list.
> Try:
> whitelist_from_rcvd *@incubator.apache.org apache.org
thats what i tried too, but w/o success. getting a hint from the list and
switched to:
whitelist_to *@incubator.apache.org
now this works well:
X-Spam-Report: BAYES_00,LONGWORDS_15,USER_IN_WHITELIST_TO
regards,
Matthias
Re: Approaches to handling mail lists
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 13 Feb 2004, Matt Kettler wrote:
> whitelist_from_rcvd *@incubator.apache.org incubator.apache.org
>
> But note, this will only match email which is FROM *@incubator.apache.org,
> ie: not the mailing list..
Actually with two changes that whitelist does work nicely for mail
that I receive from this list.
Try:
whitelist_from_rcvd *@incubator.apache.org apache.org
With the caveat that your mail system needs to make the envelope-from
address available to SA. I customized my mail config to take the
envelope-from and interpolate it into a 'Return-Path:' header that
it feeds SA.
Makes lots of "list washing" much easier. ;)
Most lists follow the convention of using some kind of predictable list
management address in the envelope-from.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Approaches to handling mail lists
Posted by Matt Kettler <mk...@evi-inc.com>.
At 04:19 PM 2/13/2004, Jens E. Madsen Jr. wrote:
>In a previous thread some one mention using the following:
>
>whitelist_from_rcvd *@incubator.apache.org
And that person would be incorrect, for several reasons
1) mail posted to the list isn't "from" the list.. it's "to" the list.. you
need whitelist_to for this operation to work
2) whitelist_from_rcvd requires 2 parameters, not one. The above config
statement is invalid and needs to be something like:
whitelist_from_rcvd *@incubator.apache.org incubator.apache.org
But note, this will only match email which is FROM *@incubator.apache.org,
ie: not the mailing list..
Re: Approaches to handling mail lists
Posted by Chris Barnes <ch...@tamu.edu>.
Jens E. Madsen Jr. <sj...@higher-speed.net> wrote:
> My concern now is for the unmoderated or unfiltered mail list. How
> can I put the mail into the correct bucket and tag the real spam as
> spam?
I did it like this:
# Allow for things from listserv.tamu.edu
header LISTSERV_GOOD_SENDER Sender =~ /listserv.myhost.domain/
score LISTSERV_GOOD_SENDER -5
Listserv (tm) puts the address of the list in the Sender tag (keeping
the From tag pointing to the person who created the post). So I just
look at the Sender tag and give it a nice negative score.
--�
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes@tamu.edu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University
RE: Approaches to handling mail lists
Posted by Andrew Ott <ao...@actcom.net>.
Just write a rule for the address of that mailing list like so:
header MAILING_LIST_BRAVO Received =~ /bravo\.net/
describe MAILING_LIST_BRAVO Received form the Bravo mailing list
score MAILING_LIST_BRAVO -4
Just customize it to the correct domain or address
======================================================================
Andrew Ott Email: aott@prairieweb.com or aott@actcom.net
Network Admin/Webmaster Web: www.prairieweb.com or www.actcom.net
======================================================================
Death is Gods way of Dropping Carrier.
God is real, unless declared integer.
God, Root, What's the Difference? - UserFriendly.org
======================================================================
-----Original Message-----
From: Jens E. Madsen Jr. [mailto:sjj_maillists@higher-speed.net]
Sent: Friday, February 13, 2004 2:20 PM
To: spamassassin-users@incubator.apache.org
Subject: Approaches to handling mail lists
Dear Spamassassin User List,
Thanks for the excellent program. It has proven to be very effective.
I am looking for a good way to handle mail list that go through
spamassassin. It should be able to handle both moderated and unmoderated
lists. It should also be user configurable so that I do not have to change
the system configuration file each time a user adds a mail list.
I currently provide procmail to filter either the tag in the Subject line or
the list id in the header to sort into my mail list buckets for the users
here. This is done at the user level. Subject tags always work even if
spamassassin tags it as spam. The List id is lost in the attached spam
email. I would like to have the mail list filter all mail into the mail list
bucket, even if it is spam.
In a previous thread some one mention using the following:
whitelist_from_rcvd *@incubator.apache.org
to white list all mail for spamassassin and I can easily show my users how
to do this. This should allow those user that are listed in RBLs or whose
mailer isn't liked by spamassassin to make it into the bucket.
My concern now is for the unmoderated or unfiltered mail list. How can I put
the mail into the correct bucket and tag the real spam as spam?
We do not mind having FPs since we do not use spamassassin to delete mail,
through procmail of course.
What would be nice is a user configurable option such as maillist that could
have a user set value, say -4, and not the -100 from whitelist.
Thanks,
Jens
RE: Approaches to handling mail lists GUI
Posted by Patrick Shoaf <ps...@midmon.com>.
I have setup Webmin & Usermin to control setting and user settings. With
this pair, Webmin allows sysadmin to setup default values for his/her
system, then Usermin allows user to setup their own controls. Usermin also
has many other user modules, including MySQL, Postgresql, ssh access,
telnet access, and many more. Using Webmin, you can setup which module
individuals are allowed access to. The user/global configuration includes
Allowed/Denied Address configurations, Spam Classifications, Message
Modification options, and some other misc options. These options are saved
in the user's home directory. Usermin also allows manual editing of the
user's .procmailrc file. Webmin & Usermin do not allow editing of the rules.
At 10:53 PM 2/13/2004, Gary Funck wrote:
> > From: Douglas Kirkland [mailto:douglas@slugstone.net]
> > Sent: Friday, February 13, 2004 7:42 PM
>[...]
> >
> > The problem I is spamassassin has to many options to work with.
> > What you want
> > maybe not what I want. Like which rules will the user be allow
> > to change the
> > score. There is just to many for a normal user to understand.
> > Then there
> > would be the poor tech suport guy having the explain each one.
>
>I think that a user-oriented GUI would let the user tweak every SA option,
>but the just the ones that would give them the 80/20 types of control.
>I wouldn't let them adjust rule scores, but just the overall threshold
>for example.
>
> > No thanks you. Please build your own, it is not that difficuit to do.
>
>I've already got it; it's called 'vi'. <g>
Patrick J. Shoaf, Systems Engineer
<ma...@midmon.com>pshoaf@midmon.com
Midmon Internet Services, LLC
100 Third Street
Charleroi, PA 15022
http://www.midmon.com
Phone: 724-483-2400 ext. 105
or 888-638-6963
Fax: 724-489-4386
RE: Web interface ( was:Re: Approaches to handling mail lists)
Posted by Gary Funck <ga...@intrepid.com>.
> From: Douglas Kirkland [mailto:douglas@slugstone.net]
> Sent: Saturday, February 14, 2004 7:55 AM
[...]
>
> I use 'vi' to change my user_prefs file. I also build a web
> interface to the
> user_prefs for our customers. It has spam threshhold, Report
> Safe, Contact
> Info, Subject-line for Spam, ok_languages, ok_locales, white
> list, and black
> list. Also allow them to set scores for these three SpamCop.net,
> HTML Web
> Bugs, and MS Executable. Scoring is a big part for spamassassin so that
> should not be left out. I would like to get a few more in the
> web interface,
> but I just am not sure which one to add.
Sounds good. The piece that I think might be missing is something that
might look an add-on to a web based mail browser that is focused on
the incoming mail, possibly presorted into inbox, possible spam, and
likely spam. The user could select one of these mail boxes, and there
would be simple check boxes on the left to indicate spam/ham. These
messages would be relearned by the Bayes system. Further when a
mail is opened up, the user could check off "whitelist sender",
"whitelist recipient", "whitelist mailing list", "filter mailing list",
and so on.
Regarding scoring, I'd probably try and hide the raw scores, and follow
the "more_spam_to", "all_spam_to" sort of model, where the user says
qualitatively whether they want the scores to be higher/lower for
particuar sorts of features.
Web interface ( was:Re: Approaches to handling mail lists)
Posted by Douglas Kirkland <do...@slugstone.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 13 February 2004 19:53, Gary Funck wrote:
> > From: Douglas Kirkland [mailto:douglas@slugstone.net]
> > Sent: Friday, February 13, 2004 7:42 PM
> [...]
> >
> > The problem I is spamassassin has to many options to work with.
> > What you want
> > maybe not what I want. Like which rules will the user be allow
> > to change the
> > score. There is just to many for a normal user to understand.
> > Then there
> > would be the poor tech suport guy having the explain each one.
>
> I think that a user-oriented GUI would let the user tweak every SA option,
> but the just the ones that would give them the 80/20 types of control.
> I wouldn't let them adjust rule scores, but just the overall threshold
> for example.
>
> > No thanks you. Please build your own, it is not that difficuit to do.
>
> I've already got it; it's called 'vi'. <g>
I use 'vi' to change my user_prefs file. I also build a web interface to the
user_prefs for our customers. It has spam threshhold, Report Safe, Contact
Info, Subject-line for Spam, ok_languages, ok_locales, white list, and black
list. Also allow them to set scores for these three SpamCop.net, HTML Web
Bugs, and MS Executable. Scoring is a big part for spamassassin so that
should not be left out. I would like to get a few more in the web interface,
but I just am not sure which one to add.
Douglas
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFALkTrSpWn8R0Z08URAkWlAKCXmFHx8QtDnSq/Q2iXpv7tGFRy0ACfQ/nH
am+xQ60PTlPhmtXYltFPkcA=
=igc2
-----END PGP SIGNATURE-----
Re: Approaches to handling mail lists
Posted by Ryan Moore <ry...@perigee.net>.
Yea, I wrote one in PHP for our users that integrates with amavisd and
the POP mail system that we use (everything in sql). It just lets them
change required_hits and whitelist/blacklist people, works really well
for us. I think there are several PHP based scripts that frontend to
amavisd (or SA directly).
Ryan Moore
----------
Perigee.net Corporation
704-849-8355 (sales)
704-849-8017 (tech)
www.perigee.net
Gary Funck wrote:
>
>>-----Original Message-----
>>From: Gary Funck [mailto:gary@intrepid.com]
>>Sent: Friday, February 13, 2004 7:54 PM
>>
>
> [...]
>
>>I think that a user-oriented GUI would let the user tweak every SA option,
>>but the just the ones that would give them the 80/20 types of control.
>
>
> Ugh. Make that "I think that a user-oriented GUI would *not* let the user
> tweak every SA option,
> but the just the ones that would give them the 80/20 types of control."
>
>
>
RE: Approaches to handling mail lists
Posted by Gary Funck <ga...@intrepid.com>.
> -----Original Message-----
> From: Gary Funck [mailto:gary@intrepid.com]
> Sent: Friday, February 13, 2004 7:54 PM
>
[...]
> I think that a user-oriented GUI would let the user tweak every SA option,
> but the just the ones that would give them the 80/20 types of control.
Ugh. Make that "I think that a user-oriented GUI would *not* let the user
tweak every SA option,
but the just the ones that would give them the 80/20 types of control."
RE: Approaches to handling mail lists
Posted by Gary Funck <ga...@intrepid.com>.
> From: Douglas Kirkland [mailto:douglas@slugstone.net]
> Sent: Friday, February 13, 2004 7:42 PM
[...]
>
> The problem I is spamassassin has to many options to work with.
> What you want
> maybe not what I want. Like which rules will the user be allow
> to change the
> score. There is just to many for a normal user to understand.
> Then there
> would be the poor tech suport guy having the explain each one.
I think that a user-oriented GUI would let the user tweak every SA option,
but the just the ones that would give them the 80/20 types of control.
I wouldn't let them adjust rule scores, but just the overall threshold
for example.
> No thanks you. Please build your own, it is not that difficuit to do.
I've already got it; it's called 'vi'. <g>
Re: Approaches to handling mail lists
Posted by Douglas Kirkland <do...@slugstone.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 13 February 2004 19:12, Gary Funck wrote:
> I don't know if such a tool exists, but it would be great if there were
> a CGI driven GUI page that let users configure their
> $HOME/.spamassassin/user_prefs
> without knowing that's what they're doing. Whitelists/blacklists, spam
> cutoff
> threshold, spam tagging style, etc. could all go there. It'd be nice if the
> tool was integrated into a web mail interface, where they could go through
> their
> inbox, spam folders, and perhaps other folders and click in a check box for
> "spam", "ham", "whitelist sender", "whitelist maling list", and so on.
The problem I is spamassassin has to many options to work with. What you want
maybe not what I want. Like which rules will the user be allow to change the
score. There is just to many for a normal user to understand. Then there
would be the poor tech suport guy having the explain each one.
No thanks you. Please build your own, it is not that difficuit to do.
Douglas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFALZkjSpWn8R0Z08URAlmoAKCoxFGkpqPqQINBpTL7t8n6Yfj3eQCfTbLW
8LR641bkgGIoZ/ZSqQuk48k=
=H1Oa
-----END PGP SIGNATURE-----
RE: Approaches to handling mail lists
Posted by Gary Funck <ga...@intrepid.com>.
> -----Original Message-----
> From: Jens E. Madsen Jr. [mailto:sjj_maillists@higher-speed.net]
> Sent: Friday, February 13, 2004 1:20 PM
> To: spamassassin-users@incubator.apache.org
> Subject: Approaches to handling mail lists
>
>
> Dear Spamassassin User List,
>
> Thanks for the excellent program. It has proven to be very effective.
>
> I am looking for a good way to handle mail list that go through
> spamassassin. It should be able to handle both moderated and unmoderated
> lists. It should also be user configurable so that I do not have to
> change the system configuration file each time a user adds a mail list.
>
I don't know if such a tool exists, but it would be great if there were
a CGI driven GUI page that let users configure their
$HOME/.spamassassin/user_prefs
without knowing that's what they're doing. Whitelists/blacklists, spam
cutoff
threshold, spam tagging style, etc. could all go there. It'd be nice if the
tool was integrated into a web mail interface, where they could go through
their
inbox, spam folders, and perhaps other folders and click in a check box for
"spam", "ham", "whitelist sender", "whitelist maling list", and so on.
> I currently provide procmail to filter either the tag in the Subject
> line or the list id in the header to sort into my mail list buckets for
> the users here. This is done at the user level.
There are some nice procmail scripts out there that detect lists and
file automatically. Nancy McGough has collected a couple of them here:
http://www.ii.com/internet/robots/procmail/qs/#genericSBE
> Subject tags always work
> even if spamassassin tags it as spam. The List id is lost in the
> attached spam email.
take a look at 'report_safe_copy_headers'. Maybe something like:
report_safe_copy_headers List-ID Mailing-List Precedence
and so on.
see:
http://www.spamassassin.org/doc/Mail_SpamAssassin_Conf.html#message%20taggin
g%20options
> I would like to have the mail list filter all mail
> into the mail list bucket, even if it is spam.
>
> In a previous thread some one mention using the following:
>
> whitelist_from_rcvd *@incubator.apache.org
>
> to white list all mail for spamassassin and I can easily show my users
> how to do this.
Technically that isn't a filter for mailing lists only, however.
If fred@incubator.apache.org sends you something, it'll be whitelisted
as well.
> This should allow those user that are listed in RBLs or
> whose mailer isn't liked by spamassassin to make it into the bucket.
>
Could get complicated for the users, if they don't have a clear
GUI to establish those settings.
> My concern now is for the unmoderated or unfiltered mail list. How can I
> put the mail into the correct bucket and tag the real spam as spam?
>
See the link above, for some ideas. If the lists are filtered first,
they're never passed to SA, btw. That's what I do, and it works fine,
though sometimes even the most esteemed technical lists are spammed.
For a lot of lists, if you're filtering all incoming mail, you can
use whitelist_to. For example:
whitelist_to *@yahoogroups.com
whitelist_to *@*.gnu.org
would whitelist all yahoogroups and all the GNU groups in one fell swoop.
The To: check won't avoid spoofs however, and some mailing lists frankly
need a spam filter, so you need to balance risks versus ease of use.
Reading the docs. I couldn't tell if header checks could check for things
like List-ID, but it would seem so:
header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset: STRING]
Define a test. SYMBOLIC_TEST_NAME is a symbolic test name, such as
'FROM_ENDS_IN_NUMS'. header is the name of a mail header, such as 'Subject',
'To', etc.
'ALL' can be used to mean the text of all the message's headers. 'ToCc' can
be used to mean the contents of both the 'To' and 'Cc' headers.
'MESSAGEID' is a symbol meaning all Message-Id's found in the message; some
mailing list software moves the real Message-Id to 'Resent-Message-Id' or
'X-Message-Id', then uses its own one in the 'Message-Id' header. The value
returned for this symbol is the text from all 3 headers, separated by
newlines.
op is either =~ (contains regular expression) or !~ (does not contain
regular expression), and pattern is a valid Perl regular expression, with
modifiers as regexp modifiers in the usual style. Note that multi-line rules
are not supported, even if you use x as a modifier.
If the [if-unset: STRING] tag is present, then STRING will be used if the
header is not found in the mail message.
Test names should not start with a number, and must contain only
alphanumerics and underscores. It is suggested that lower-case characters
not be used, as an informal convention. Dashes are not allowed.
Note that test names which begin with '__' are reserved for meta-match
sub-rules, and are not scored or listed in the 'tests hit' reports. Test
names which begin with 'T_' are reserved for tests which are undergoing QA,
and these are given a very low score.
If you add or modify a test, please be sure to run a sanity check afterwards
by running spamassassin --lint. This will avoid confusing error messages, or
other tests being skipped as a side-effect.
-----
might be some interesting possibilities there.
> We do not mind having FPs since we do not use spamassassin to delete
> mail, through procmail of course.
>
Sounds good.
> What would be nice is a user configurable option such as maillist that
> could have a user set value, say -4, and not the -100 from whitelist.
Take a look at 'more_spam_to', I don't know what weight it scores (I think
-10) or whether that is configurable?