Christian Meyer wrote:
> after upgrading to 2.6.3 from prior 2.6.2 spam which is detected by clamav
> and marked as "Sanesecurity.Spam..." is now no longer marked as spam;
> it's blocked as virus.
> Maybe it's the adjustment from your release notes?
> "uncommented the qr'^MAIL$' in @keep_decoded_original_maps"
> It seems this only affects mails where clamav splits them up.
> Virus scanner output:
> p004: Sanesecurity.Spam.9216.UNOFFICIAL FOUND
> p001: Sanesecurity.Spam.9216.UNOFFICIAL FOUND
> p002: Sanesecurity.Spam.9216.UNOFFICIAL FOUND
Jernej Porenta wrote:
> I have a case where email was blocked as infected (via winnow
> signatures), when no policy was found in $sql_select_policy, even when
> default @virus_name_to_spam_score_maps have a line for marking it as spam.
> My configs are like this (just the interesting part):
> @virus_name_to_spam_score_maps =
> (new_RE( ...
> [ qr'^winnow\.(phish|spam)\.' => 0.1],
> [ qr'^winnow\.malware\.' => undef ], ));
> Logs show this: [...]
> There is no policy settings for user x...@domain in the database
Michael Scheidell wrote:
> got an email with bad 8 bit (spam)
> spammers uses decimal 240 in place of space in subject line.
> clamav sees spam: (sane security) but sa doesnt'
> (I don't think amavisd passed it to spamassassin)
> X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char A0 hex):
> Subject: Her\240night\240moans\240gua[...]
> X-Spam-Status: No, score=0 tagged_above=-999 required=5
> tests=[AV:Sanesecurity.Junk.15877.UNOFFICIAL=0]
> I strip out the 8 bit header, and run it again, and I get this:...
> Second issue:
> it didn't quarantine it as a bad header either.
> $bad_header_quarantine_method='sql:';
> $spam_quarantine_method='sql:';
> (and I know spam quarantine works)
> In sql policy, have:
> virus_quarantine_to: NULL
> spam_quarantine_to: NULL
> banned_quarantine_to: NULL
> bad_header_quarantine_to: NULL
> clean_quarantine_to: sql:
> (and I know clean quarantine works.. In fact, that bad header
> one got 'clean' quarantined)
It seems to me these are all manifestations of the same problem,
namely that a clamd spam detection was not properly turned into
a spam detection - but I can't nail it down or reproduce it here.
It may be associated with caching results from previous mails.
I tried simulating Christian's hypothesis (multiple clamd hits),
as well as Jernej's "no policy in SQL", to no avail.
I'd appreciate if anyone who can reproduce the problem
would send me a log at $log_level=5 of the incident.
It is not necessary to have log level turned up indiscriminately
for all mail. If the problem is reproducible, one way to
turn logging level fully up selectively for a given *sender*
is to use a @debug_sender_acl lookup, e.g:
@debug_sender_acl = qw( test-sen...@example.org );
Another way of testing is to set up a second amavisd instance on a
different port and using a different set of pid/lock/tempdir/db files.
Something like the following can be appended to amavisd.conf:
if ($instance_name eq 'test') {
$log_level = 5;
$DO_SYSLOG = undef;
$LOGFILE = undef;
$max_servers = 1;
$TEMPBASE = "$MYHOME/tmp-am2";
$ENV{TMPDIR} = $TEMPBASE;
$pid_file = "$helpers_home/amavisd2.pid";
$lock_file = "$helpers_home/amavisd2.lock";
$db_home = "$MYHOME/var/db/amavis2";
$unix_socketname = undef;
$inet_socket_port = [8888];
}
then one can start up this instance of amavisd by providing a
command line option -i, its value is passed to a variable
$instance_name and can be used for any purpose by amavisd.conf,
e.g."
# amavisd -i test debug
$ mini_sendmail -fsen...@example.com -s127.0.0.1 -p8888 \
re...@example.com <test.msg
Michael Scheidell wrote:
> after upgrading to 2.6.3, I no longer get X-Spam-headers in the email
> if they score between 0 and 2. sometimes.. sometimes not.
> doesn't matter what user, and the headers are always in the quarantine
> records. - as in, score 1.0, headers in quarantine record, not in
> email (sometimes) score 2.1, headers everywhere. (best I can tell).
> Score (-97.345?) since AM:BOOST=-98.121, I get headers in quarantine
> record AND email.
> sql policy for the site (@.), AND user all have:
> spam_tag_level: -999
> there is no domain policy:
> select id,policy_id from users where email='@secnap.net';
> | id | policy_id |
> | 210 | NULL |
> /usr/local/etc/amavisd.conf:$sa_tag_level_deflt = 2.0;
> (but that should NOT override the SQL table. and doesn't.
> except sometimes :-)
This is probably something else, but again I'd need to see
a log at level 5 to figure it out.
Mark
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
