view release on metacpan or search on metacpan
share/SpamAssassin/easy_ham_2/01399.ca6b00b7b341bbde9a9ea3dd6a7bf896
share/SpamAssassin/easy_ham_2/01400.f897f0931e461e7b2e964d28e927c35e
share/SpamAssassin/easy_ham_2/cmds
share/SpamAssassin/easy_ham_subset/00009.371eca25b0169ce5cb4f71d3e07b9e2d
share/SpamAssassin/easy_ham_subset/00064.cb4bd5482454f02b6c3d70343af090a8
share/SpamAssassin/easy_ham_subset/00087.03a92f5753c44cb83d28837121d82b06
share/SpamAssassin/easy_ham_subset/00182.8e6541320c6c08e0a899455a0a21f91c
share/SpamAssassin/easy_ham_subset/00271.b67b5b37ce874d5ccea3391922f14506
share/SpamAssassin/easy_ham_subset/00677.b957e34b4dd0d9263b56bf71b1168d8a
share/SpamAssassin/sa-learn.cfg
share/SpamAssassin/sa-learn.prefs
share/SpamAssassin/spam/0000.7b1b73cf36cf9dbc3d64e3f2ee2b91f1
share/SpamAssassin/spam/0001.bfc8d64d12b325ff385cca8d07b84288
share/SpamAssassin/spam/0002.24b47bb3ce90708ae29d0aec1da08610
share/SpamAssassin/spam/0003.4b3d943b8df71af248d12f8b2e7a224a
share/SpamAssassin/spam/0004.1874ab60c71f0b31b580f313a3f6e777
share/SpamAssassin/spam/0005.1f42bb885de0ef7fc5cd09d34dc2ba54
share/SpamAssassin/spam/0006.7a32642f8c22bbeb85d6c3b5f3890a2c
share/SpamAssassin/spam/0007.859c901719011d56f8b652ea071c1f8b
share/SpamAssassin/spam/0008.9562918b57e044abfbce260cc875acde
share/SpamAssassin/spam/0009.c05e264fbf18783099b53dbc9a9aacda
share/SpamAssassin/easy_ham/00010.145d22c053c1a0c410242e46c01635b3 view on Meta::CPAN
List-Subscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
<mailto:spamassassin-talk-request@lists.sourceforge.net?subject=subscribe>
List-Id: Talk about SpamAssassin <spamassassin-talk.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
<mailto:spamassassin-talk-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=spamassassin-talk>
X-Original-Date: Thu, 22 Aug 2002 10:16:36 -0400
Date: Thu, 22 Aug 2002 10:16:36 -0400
I have been trying to research via SA mirrors and search engines if a canned
script exists giving clients access to their user_prefs options via a
web-based CGI interface. Numerous ISPs provide this feature to clients, but
so far I can find nothing. Our configuration uses Amavis-Postfix and ClamAV
for virus filtering and Procmail with SpamAssassin for spam filtering. I
would prefer not to have to write a script myself, but will appreciate any
suggestions.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
share/SpamAssassin/easy_ham/00392.1a94887ca585cbdaeec97524b9308b63 view on Meta::CPAN
>>>>> On Sat, 24 Aug 2002, "Harlan" == Harlan Feinstein wrote:
Harlan> What's the trick again to have it default to showing
Harlan> text/plain instead of html?
In ~/.exmh/exmh-defaults add:
*mime_alternative_prefs: text/plain text/enriched text/richtext text/html
Order possible alternatives from _your_ most preferred to least
preferred.
--Hal
_______________________________________________
share/SpamAssassin/easy_ham/01313.f8778c3339382c5514c9e201847f75ee view on Meta::CPAN
Date: Thu, 22 Aug 2002 13:01:44 -0500 (CDT)
As the subject line indicates, I'm sure these are stupid questions, but
I'm having trouble getting SA working like I understand it should work,
and have about given up on trying to figure it out myself.
If a user has a line like:
whitelist_from *@yahoogroups.com
in his .spamassassin/user_prefs file, does that line not, in effect,
tell the program to take no action at all against any mail coming in from
yahoogroups.com, or is there still checking being done against it? And if
the latter, what does he need to place in user_prefs to cause such mail
to be ignored? I'm testing SA here with a few users who happen to be on
yahoogroups lists, before deploying it system-wide, and although the above
line has been added to their user_prefs files, much of their list mail is
still going to the spam folder due to all the usual things you would
expect to trigger SA.
Thanks in advance for any help.
--
Ken Scott,
admin@shellworld.net
share/SpamAssassin/easy_ham/01314.ba7b992d372c23964b8b4a1de885a095 view on Meta::CPAN
--lteA1dqeVaWQ9QQl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Aug 22, 2002 at 01:01:44PM -0500, Ken Scott wrote:
> whitelist_from *@yahoogroups.com
>=20
> in his .spamassassin/user_prefs file, does that line not, in effect,
> tell the program to take no action at all against any mail coming in from
> yahoogroups.com, or is there still checking being done against it? And if
It still gets checked, but a negative score is added in. And it doesn't
mean "coming in from" it means "From: address is @yahoogroups.com".
There's a Yahoo Groups compensation rule in 2.40 though. :)
> the latter, what does he need to place in user_prefs to cause such mail
> to be ignored? I'm testing SA here with a few users who happen to be on
ignored completely? you can't do that, put in a procmail rule.
> yahoogroups lists, before deploying it system-wide, and although the above
> line has been added to their user_prefs files, much of their list mail is
> still going to the spam folder due to all the usual things you would
> expect to trigger SA.
You'd want to either add your own compensation rule or up (negatively)
the whitelist score.
--=20
Randomly Generated Tagline:
There are perfectly good answers to those questions, but they'll have
to wait for another night.
share/SpamAssassin/easy_ham/01386.4421abca51be5e71c1651102468420e2 view on Meta::CPAN
X-Original-Date: Thu, 29 Aug 2002 13:33:53 +0100
Date: Thu, 29 Aug 2002 13:33:53 +0100
Urban Boquist wrote:
> Hi Matt, and thanks for your quick reply.
>
> Matt> Don't run SA on mails this large.
>
> That would be fine, if I only understood how I should do that. I can't
> find anything in the SA documention that mentions some kind of upper
> limit for the size of a message. What should I put in my user_prefs
> file?
>
> I run SA from procmail btw, but I can't imagine that procmail would be
> able to check the size of a message before handing it over to SA?
That's exactly what it can do:
:0fw <250000
| spamassassin -P
share/SpamAssassin/easy_ham/01503.5e13994a5676296ed31b14e83367031c view on Meta::CPAN
Received: from ns1.apexvoice.com ([64.52.111.15]
helo=popeye.apexvoice.com) by usw-sf-list1.sourceforge.net with esmtp
(Exim 3.31-VA-mm2 #1 (Debian)) id 17ty84-00085i-00 for
<spamassassin-talk@lists.sourceforge.net>; Tue, 24 Sep 2002 15:26:04 -0700
Received: from sthomas (64-52-111-64.apexvoice.com [64.52.111.64]) by
popeye.apexvoice.com (8.12.3/8.12.3) with SMTP id g8OMPrba011319;
Tue, 24 Sep 2002 15:25:53 -0700
From: "Steve Thomas" <sthomas@apexvoice.com>
To: "Cheryl L. Southard" <cld@astro.caltech.edu>,
<spamassassin-talk@lists.sourceforge.net>
Subject: RE: [SAtalk] user_prefs ignored
Message-Id: <PIEHJPLNKGMNAHJKHLFCCECJCEAA.sthomas@apexvoice.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20020924212731.GA24786@deimos.caltech.edu>
share/SpamAssassin/easy_ham/01503.5e13994a5676296ed31b14e83367031c view on Meta::CPAN
<mailto:spamassassin-talk-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=spamassassin-talk>
X-Original-Date: Tue, 24 Sep 2002 15:25:54 -0700
Date: Tue, 24 Sep 2002 15:25:54 -0700
This is just an semi-educated guess - if I'm wrong, someone please correct
me!
Spamd setuid's to the user running spamc. Since you're calling spamc from a
global procmailrc file, it's being run as root (most likely). If called as
root, spamd won't open user_prefs files.
>>From the spamc man page:
-u username
This argument has been semi-obsoleted. To have spamd use
per-user-config files, run spamc as the user whose config
files spamd should load. If you're running spamc as some
other user though (eg. root, mail, nobody, cyrus, etc.)
then you can still use this flag.
share/SpamAssassin/easy_ham/01503.5e13994a5676296ed31b14e83367031c view on Meta::CPAN
St-
| -----Original Message-----
| From: spamassassin-talk-admin@example.sourceforge.net
| [mailto:spamassassin-talk-admin@lists.sourceforge.net]On Behalf Of
| Cheryl L. Southard
| Sent: Tuesday, September 24, 2002 2:28 PM
| To: spamassassin-talk@example.sourceforge.net
| Subject: [SAtalk] user_prefs ignored
|
|
| Hi All,
|
| I am running SpamAssassin 2.41 with procmail as my local delivery agent
| with sendmail. I use spamc/spamd so that it runs site-wide from
| /etc/procmailrc.
|
| spamd is run as root with the flags "-d -a -c", and spamc isn't run with
| any flags.
|
| When I was testing the program, I deployed spamc from my personal
| ~/.procmailrc file, my ~/.spamassassin/user_prefs file was read each time.
| I can see this because I have a non-default "required_hits" value which
| gets reported in every e-mail on the "X-Spam-Status" line.
|
| Now that I run spamc from the global /etc/procmailrc file, my
| ~/.spamassassin/user_prefs file is no longer being read or processed from
| e-mails from outside computers. The "required_hits" value gets set back
| to the one in /etc/mail/spamassassin/local.cf. However, if I send local
| e-mail, my user_prefs file is read and processed correctly.
|
| Does anyone know how to fix this problem? if this is a spamassassin or
| procmail bug?
|
| Thanks,
|
| Cheryl
|
| --
| Cheryl Southard
share/SpamAssassin/easy_ham/01512.9a1a7937d7a0691e79d806bdfbda28a3 view on Meta::CPAN
retrieving revision 1.115.2.12
diff -b -w -u -d -r1.115.2.11 -r1.115.2.12
--- SpamAssassin.pm 24 Sep 2002 18:51:37 -0000 1.115.2.11
+++ SpamAssassin.pm 2 Oct 2002 13:19:28 -0000 1.115.2.12
@@ -696,7 +696,13 @@
}
###########################################################################
-# non-public methods.
+
+=item $f->init ($use_user_prefs)
+
+Read and parse the current configuration. C<$use_user_prefs> can
+be C<0> (do not read user preferences) or C<1> (do).
+
+=cut
sub init {
my ($self, $use_user_pref) = @_;
@@ -767,6 +773,9 @@
# TODO -- open DNS cache etc. if necessary
}
share/SpamAssassin/easy_ham/01591.7504f83163aa1c627354192d452a43e3 view on Meta::CPAN
> In my experience, there are spam messages that sneak past Spam Assassin,
> that Razor will pick up. Those are the ones that I'm calling "marginal".
> Basically, I'm hoping that "the collective" of Razor users make a better
> judge of spam than any single program like SA can, and therefore I can
> benefit from their judgement and get more extensive spam filtering. I've
> seen examples of this already, where SA doesn't score the spam high enough
> to bounce it, but Razor does.
I think perhaps you missed the fact that SA scores are adjustable. If
you want SA to tag all messages listed in Razor then you can put this
in your ~/.spamassassin/user_prefs file.
score RAZOR_CHECK 10
The default score is 3 and the default threshold needed is 5.
Therefore if you wish to have any razor listed messages tagged by SA
then setting a score for any razor listed messages to anything above 5
would be sufficient.
If you are already using SA then the above would be more efficient.
Otherwise you are running all of the mail through razor twice, once
share/SpamAssassin/easy_ham/01932.f8c1d938ebba259e2926cf4400891c86 view on Meta::CPAN
default on Win32 (overwhelmingly) is to bring up a context menu on a mouse up.
If you don't like it, complain about Win32, but don't cite this as a Mozilla
usability problem when we're following the conventions of the operating system.
(We simply listen for the WM_CONTEXTMENU message. That message fires when Win32
wants to fire it.)
- Validation - Err, no. Not a usability problem. To the average bear, this is
completely irrelevant.
- Preferences - IMO this should be much higher on the list. Preferences are a
tangled pathetic mess. Again, separating prefs for individual apps into unique
dialogs would simplify things a great deal, but we should also remove nearly
half the preferences that exist from the GUI. Mozilla is ridiculously
overconfigurable.
[1] http://www.blakeross.com/archives/2002_08_18_index.html#80418641
[2] http://mpt.phrasewise.com
share/SpamAssassin/easy_ham_2/00637.b8b627542a5af9e99890aff7a73c7754 view on Meta::CPAN
List-Subscribe: <https://example.sourceforge.net/lists/listinfo/razor-users>,
<mailto:razor-users-request@lists.sourceforge.net?subject=subscribe>
List-Id: <razor-users.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/razor-users>,
<mailto:razor-users-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=razor-users>
X-Original-Date: Tue, 13 Aug 2002 13:06:16 -0500
Date: Tue, 13 Aug 2002 13:06:16 -0500
At 12:20 PM -0500 8/13/02, Mike Burger wrote:
>Make sure you have this in your .spamassassin/user_prefs:
This might be a problem. I'll have to look into it further. I just
got SA working yesterday. It's being called from MIMEDefang. I'm
not sure if it will look for user preferences when run like that.
One would hope it would be I can't say for certain. I'll look in to
it.
># By default, the subject lines of suspected spam will be tagged.
># This can be disabled here.
>#
share/SpamAssassin/easy_ham_2/00641.a4e760e8ab2d1fb7302559751ab28d27 view on Meta::CPAN
> To actually answer Justin's question, (one can assume that he has
> rewrite_subject and report_header turned on because he wants them..and
> that he would like to be able to strip the added bits off before he sends
> them to razor) something as simple as the following would probably work
> just fine. Just pipe your message through this, then on into
> razor-report:
I wouldn't make that assumption. I'd assume that rewrite_subject was on,
and report_header was off, because that's the default configuration, and
not everyone knows to go look in the user_prefs file to make those
changes.
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Razor-users mailing list
share/SpamAssassin/easy_ham_2/01277.d7a43a4dd78dc466c8808f370ae2b2bb view on Meta::CPAN
- run the Update Agent on each affected server.
---------------------------------
Changing Notification Preferences
---------------------------------
To enable/disable your Errata Alert preferences globally please log in to RHN
and navigate from "Your RHN" / "Your Account" to the "Preferences" tab.
URL: https://rhn.spamassassin.taint.org/network/my_account/my_prefs.pxt
You can also enable/disable notification on a per system basis by selecting an
individual system from the "Systems List". From the individual system view
click the "Details" tab.
---------------------
Affected Systems List
---------------------
This Errata Advisory may apply to the systems listed below. If you know that
share/SpamAssassin/easy_ham_2/01281.c6dc8af12840f7e67f50ed2346e204de view on Meta::CPAN
spamassassin.sf.net is the US mirror, also accessible through
us.spamassassin.org.
> They appear to be the same page, but until recently I could get to the
> www. spamassassin.org one, but it hasn't been responsive the last couple
> days.
For me it worked until yesterday or the day before.
> But then, I also haven't been able to get anyone to answer my questions
> about user_prefs files (not the one from earlier today, but from a couple
> days ago).
About this question: No, that's currently not possible. But I was thinking
about implementing a feature like this; it might be in the next release.
Malte
--
-- Coding is art.
--
share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b view on Meta::CPAN
initialization code so that it can be manually set to true, even
if neither host is running Windows. (This may be useful, e.g.,
when using Unison running on a Unix system with a FAT volume
mounted.)
* Small improvements and bug fixes:
+ Errors in preference files now generate fatal errors rather
than warnings at startup time. (I.e., you can't go on from
them.) Also, we fixed a bug that was preventing these
warnings from appearing in the text UI, so some users who
have been running (unsuspectingly) with garbage in their
prefs files may now get error reports.
+ Error reporting for preference files now provides file name
and line number.
+ More intelligible message in the case of identical change to
the same files: ``Nothing to do: replicas have been changed
only in identical ways since last sync.''
+ Files with prefix '.#' excluded when scanning for preference
files.
+ Rsync instructions are send directly instead of first
marshaled.
+ Won't try forever to get the fingerprint of a continuously
share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b view on Meta::CPAN
Windows).
+ Added the option to compile unison on the Windows platform
with Cygwin GNU C compiler. This option only supports
building dynamically linked unison executables.
Changes since 2.7.4:
* Fixed a silly (but debilitating) bug in the client startup
sequence.
Changes since 2.7.1:
* Added addprefsto preference, which (when set) controls which
preference file new preferences (e.g. new ignore patterns) are
added to.
* Bug fix: read the initial connection header one byte at a time, so
that we don't block if the header is shorter than expected. (This
bug did not affect normal operation --- it just made it hard to
tell when you were trying to use Unison incorrectly with an old
version of the server, since it would hang instead of giving an
error message.)
Changes since 2.6.59:
share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b view on Meta::CPAN
precompiled binaries on Windows, please upgrade.
* Added a -debug command line flag, which controls debugging of
various modules. Say -debug XXX to enable debug tracing for module
XXX, or -debug all to turn on absolutely everything.
* Fixed a small bug where the text UI on NT was raising a 'no such
signal' exception.
Changes since 1.111:
* INCOMPATIBLE CHANGE: The names and formats of the preference files
in the .unison directory have changed. In particular:
+ the file ``prefs'' should be renamed to default.prf
+ the contents of the file ``ignore'' should be merged into
default.prf. Each line of the form REGEXP in ignore should
become a line of the form ignore = REGEXP in default.prf.
* Unison now handles permission bits and symbolic links. See the
manual for details.
* You can now have different preference files in your .unison
directory. If you start unison like this
unison profilename
(i.e. with just one ``anonymous'' command-line argument), then the
share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b view on Meta::CPAN
initialization code so that it can be manually set to true, even
if neither host is running Windows. (This may be useful, e.g.,
when using Unison running on a Unix system with a FAT volume
mounted.)
* Small improvements and bug fixes:
+ Errors in preference files now generate fatal errors rather
than warnings at startup time. (I.e., you can't go on from
them.) Also, we fixed a bug that was preventing these
warnings from appearing in the text UI, so some users who
have been running (unsuspectingly) with garbage in their
prefs files may now get error reports.
+ Error reporting for preference files now provides file name
and line number.
+ More intelligible message in the case of identical change to
the same files: ``Nothing to do: replicas have been changed
only in identical ways since last sync.''
+ Files with prefix '.#' excluded when scanning for preference
files.
+ Rsync instructions are send directly instead of first
marshaled.
+ Won't try forever to get the fingerprint of a continuously
share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b view on Meta::CPAN
Windows).
+ Added the option to compile unison on the Windows platform
with Cygwin GNU C compiler. This option only supports
building dynamically linked unison executables.
Changes since 2.7.4:
* Fixed a silly (but debilitating) bug in the client startup
sequence.
Changes since 2.7.1:
* Added addprefsto preference, which (when set) controls which
preference file new preferences (e.g. new ignore patterns) are
added to.
* Bug fix: read the initial connection header one byte at a time, so
that we don't block if the header is shorter than expected. (This
bug did not affect normal operation --- it just made it hard to
tell when you were trying to use Unison incorrectly with an old
version of the server, since it would hang instead of giving an
error message.)
Changes since 2.6.59:
share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b view on Meta::CPAN
precompiled binaries on Windows, please upgrade.
* Added a -debug command line flag, which controls debugging of
various modules. Say -debug XXX to enable debug tracing for module
XXX, or -debug all to turn on absolutely everything.
* Fixed a small bug where the text UI on NT was raising a 'no such
signal' exception.
Changes since 1.111:
* INCOMPATIBLE CHANGE: The names and formats of the preference files
in the .unison directory have changed. In particular:
+ the file ``prefs'' should be renamed to default.prf
+ the contents of the file ``ignore'' should be merged into
default.prf. Each line of the form REGEXP in ignore should
become a line of the form ignore = REGEXP in default.prf.
* Unison now handles permission bits and symbolic links. See the
manual for details.
* You can now have different preference files in your .unison
directory. If you start unison like this
unison profilename
(i.e. with just one ``anonymous'' command-line argument), then the
share/SpamAssassin/easy_ham_2/01391.00e6f3a6dc816f22335f1b0fd6098eda view on Meta::CPAN
List-Post: <mailto:spamassassin-talk@example.sourceforge.net>
List-Subscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
<mailto:spamassassin-talk-request@lists.sourceforge.net?subject=subscribe>
List-Id: Talk about SpamAssassin <spamassassin-talk.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
<mailto:spamassassin-talk-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=spamassassin-talk>
X-Original-Date: Wed, 24 Jul 2002 09:15:53 -0700
Date: Wed, 24 Jul 2002 09:15:53 -0700
Amis-v or there is another prefs file that SA is using. I had a heck of a time
figuring out where to find my site wide file because of my configuration.
If your using spamd and you want your users to have some control using
user_prefs then check their ~/spamassassin file.
If your using spamd and you have a site wide only policy then make sure that
spamd is started with the -x option.
If you used the -x option then the only place that it should get the rules from
would be from the local.cf in the /etc/mail/spamassassin directory. Assuming a
default install.
Theo Van Dinter wrote:
>
> On Wed, Jul 24, 2002 at 10:18:28AM -0500, Stewart, John wrote:
> > X-Virus-Scanned: by amavisd-new amavisd-new-20020630
share/SpamAssassin/spam_2/00556.098b57f5108ba34d21825f176e492786 view on Meta::CPAN
<p align="center"><font face="Verdana, Arial, Helvetica, sans-
serif" size="2" color="#132E65">More Info</font><br>
<br>
</a>Join our mailing list to be first to know about fresh
quality
programs and utilities. Our list includes selected, tested and
quality freeware, shareware and other software only.<br>
<br>
<!--START CODE-->
<center><A target="_blank"
HREF="http://lb.bcentral.com/ex/manage/subscriberprefs.aspx?
customerid=21671" ><IMG
SRC="http://lb.bcentral.com/images/alist/signup.gif" BORDER="0"
WIDTH="100" HEIGHT="35"></A>
<!--END CODE --></center><BR><BR>
</p><br><br>
</div>
</td>
</tr>
<tr align="right">
<td valign="top"> </td>