Mail-SpamAssassin-SpamCopURI
view release on metacpan or search on metacpan
lib/Mail/SpamAssassin/Conf.pm view on Meta::CPAN
_RBL_ full results for positive RBL queries in DNS URI format
_LANGUAGES_ possible languages of mail
_PREVIEW_ content preview
_REPORT_ terse report of tests hits (for header reports)
_SUMMARY_ summary of tests hit for standard report (for body reports)
_CONTACTADDRESS_ contents of the 'report_contact' setting
=head1 USER PREFERENCES
The following options can be used in both site-wide (C<local.cf>) and
user-specific (C<user_prefs>) configuration files to customize how
SpamAssassin handles incoming email messages.
=cut
package Mail::SpamAssassin::Conf;
use Mail::SpamAssassin::Util;
use Mail::SpamAssassin::NetSet;
use strict;
use bytes;
lib/Mail/SpamAssassin/Conf.pm view on Meta::CPAN
=cut
if (/^whitelist_from\s+(.+)$/) {
$self->add_to_addrlist ('whitelist_from', split (' ', $1)); next;
}
=item unwhitelist_from add@ress.com
Used to override a default whitelist_from entry, so for example a distribution
whitelist_from can be overridden in a local.cf file, or an individual user can
override a whitelist_from entry in their own C<user_prefs> file.
The specified email address has to match exactly the address previously
used in a whitelist_from line.
e.g.
unwhitelist_from joe@example.com fred@example.com
unwhitelist_from *@example.com
=cut
lib/Mail/SpamAssassin/Conf.pm view on Meta::CPAN
if (/^def_whitelist_from_rcvd\s+(\S+)\s+(\S+)$/) {
$self->add_to_addrlist_rcvd ('def_whitelist_from_rcvd', $1, $2);
next;
}
=item unwhitelist_from_rcvd add@ress.com
Used to override a default whitelist_from_rcvd entry, so for example a
distribution whitelist_from_rcvd can be overridden in a local.cf file,
or an individual user can override a whitelist_from_rcvd entry in
their own C<user_prefs> file.
The specified email address has to match exactly the address previously
used in a whitelist_from_rcvd line.
e.g.
unwhitelist_from_rcvd joe@example.com fred@example.com
unwhitelist_from_rcvd *@axkit.org
=cut
lib/Mail/SpamAssassin/Conf.pm view on Meta::CPAN
=cut
if (/^blacklist_from\s+(.+)$/) {
$self->add_to_addrlist ('blacklist_from', split (' ', $1)); next;
}
=item unblacklist_from add@ress.com
Used to override a default blacklist_from entry, so for example a distribution blacklist_from
can be overridden in a local.cf file, or an individual user can override a blacklist_from entry
in their own C<user_prefs> file.
e.g.
unblacklist_from joe@example.com fred@example.com
unblacklist_from *@spammer.com
=cut
if (/^unblacklist_from\s+(.+)$/) {
$self->remove_from_addrlist ('blacklist_from', split (' ', $1)); next;
lib/Mail/SpamAssassin/Conf.pm view on Meta::CPAN
if ($scoresonly) { dbg("Checking privileged commands in user config"); }
=back
=head1 PRIVILEGED SETTINGS
These settings differ from the ones above, in that they are considered
'privileged'. Only users running C<spamassassin> from their procmailrc's or
forward files, or sysadmins editing a file in C</etc/mail/spamassassin>, can
use them. C<spamd> users cannot use them in their C<user_prefs> files, for
security and efficiency reasons, unless allow_user_rules is enabled (and
then, they may only add rules from below).
=over 4
=item allow_user_rules { 0 | 1 } (default: 0)
This setting allows users to create rules (and only rules) in their
C<user_prefs> files for use with C<spamd>. It defaults to off, because
this could be a severe security hole. It may be possible for users to
gain root level access if C<spamd> is run as root. It is NOT a good
idea, unless you have some other way of ensuring that users' tests are
safe. Don't use this unless you are certain you know what you are
doing. Furthermore, this option causes spamassassin to recompile all
the tests each time it processes a message for a user with a rule in
his/her C<user_prefs> file, which could have a significant effect on
server load. It is not recommended.
Note that it is not currently possible to use C<allow_user_rules> to modify an
existing system rule from a C<user_prefs> file with C<spamd>.
=cut
if (/^allow_user_rules\s+(\d+)$/) {
$self->{allow_user_rules} = $1+0;
dbg( ($self->{allow_user_rules} ? "Allowing":"Not allowing") . " user rules!"); next;
}
=item header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset: STRING]
lib/Mail/SpamAssassin/Conf.pm view on Meta::CPAN
#
if ($scoresonly) { goto failed_line; }
=back
=head1 ADMINISTRATOR SETTINGS
These settings differ from the ones above, in that they are considered 'more
privileged' -- even more than the ones in the SETTINGS section. No matter what
C<allow_user_rules> is set to, these can never be set from a user's
C<user_prefs> file.
=over 4
=item test SYMBOLIC_TEST_NAME (ok|fail) Some string to test against
Define a regression testing string. You can have more than one regression test
string per symbolic test name. Simply specify a string that you wish the test
to match.
These tests are only run as part of the test suite - they should not affect the
plib/2.63/Mail/SpamAssassin/PerMsgStatus.pm view on Meta::CPAN
=head1 NAME
Mail::SpamAssassin::PerMsgStatus - per-message status (spam or not-spam)
=head1 SYNOPSIS
my $spamtest = new Mail::SpamAssassin ({
'rules_filename' => '/etc/spamassassin.rules',
'userprefs_filename' => $ENV{HOME}.'/.spamassassin.cf'
});
my $mail = Mail::SpamAssassin::NoMailAudit->new();
my $status = $spamtest->check ($mail);
if ($status->is_spam()) {
$status->rewrite_mail ();
$mail->accept("caught_spam");
}
...
plib/2.64/Mail/SpamAssassin/PerMsgStatus.pm view on Meta::CPAN
=head1 NAME
Mail::SpamAssassin::PerMsgStatus - per-message status (spam or not-spam)
=head1 SYNOPSIS
my $spamtest = new Mail::SpamAssassin ({
'rules_filename' => '/etc/spamassassin.rules',
'userprefs_filename' => $ENV{HOME}.'/.spamassassin.cf'
});
my $mail = Mail::SpamAssassin::NoMailAudit->new();
my $status = $spamtest->check ($mail);
if ($status->is_spam()) {
$status->rewrite_mail ();
$mail->accept("caught_spam");
}
...
( run in 0.711 second using v1.01-cache-2.11-cpan-8f98c5d2c55 )