> For spam that is passed, with version 20030616-p10 of amavisd-new, you
> should see something like:
>
> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com
...
Thanks, that pinpointed the difference clearly.
> Notice all the differences, I have not seen amavisd-new produce
> 'autolearn=no'.
> (I set my $sa_tag2_level_deflt = 1.0; to insure it would be marked.)
I'm following your recommendation.
> > What other mail transport could be using spamassassin? I use postfix
> > (exim not installed), fetchmail, amavisd-new, and as far as I know,
> > nothing else.
> >
>
> Do you have a ~/.procmailrc or /etc/procmailrc file?
> If so, what are the contents?
I created /etc/procmailrc a few days ago in an attempt to get postfix
to use spamassassin. Perhaps it is amavisd-new that should instead use
spamassassin and this rc file should be deleted.
DROPPRIVS=yes
PATH=/bin:/usr/bin:/usr/local/bin
SHELL=/bin/sh
# Spamassassin
:0fw
* <300000
|/usr/bin/spamassassin
# Spamassassin
:0fw
* <300000
|/usr/bin/spamassassin
> > So amavis is trying to filter with clamav, but clamav is having its
> > problems. It was suggested I reinstall clamav, change ownerships of
> > /var/log/clamav (and log file contents), /var/run/clamav/ (directory
> > empty), and /var/lib/clamav (and its two files) to clamav:clamav, and
> > that clamav be placed in the amavis group. This is what I have. The
> > current clamav.log is empty, but in a log of yesterday, there's a lot
> > of info, but it is a binary file.
>
> You can use 'vi' to view the contents of .gz files.
> How many of these older files do you have?
I see that in fact I have log files in /var/log/clamav going back
several months.
> If you followed the
> instructions to purge clamav, then there should only be logs dated
> after you purged. There should not be any older. If there are older,
> then either you did not purge, or the purge did not run correctly.
I assumed that # dpgk --purge clamav would do the trick. I just ran it
again and get:
(reading database ... 87261 files and directories currently installed.)
Removing clamav ...
However, it didn't touch the log files in /var/log/clamav although
$apt-show-versions says clamav is currently not installed. I'll
reinstall clamav, but not tinker with anything lest I make things
worse.
As for reading the clamav.log files, I'm in the habit of using the
zless command (I use emacs rather than vi). However, this command
tells me the compressed file is binary. Something is wrong, so I just
unpacked a couple to look at them. All the logs going back to
September have zero content. The most recent log with content is 18
September, and its typical entry is this:
Wed Sep 7 10:42:32 2005 -> +++ Started at Wed Sep 7 10:42:32 2005
Wed Sep 7 10:42:32 2005 -> clamd daemon 0.86.2 (OS: linux-gnu,
ARCH: i386, CPU: i386)
Wed Sep 7 10:42:32 2005 -> Log file size limit disabled.
Wed Sep 7 10:42:32 2005 -> Running as user amavis (UID 106, GID 107)
Wed Sep 7 10:42:32 2005 -> Reading databases from /var/lib/clamav
Wed Sep 7 10:42:33 2005 -> Protecting against 39353 viruses.
Wed Sep 7 10:42:33 2005 -> ERROR: Socket file
/var/run/clamav/clamd.ctl could not be bound: Permission denied
But so much water has gone over the dam that I don't know if this
means anything. In my zeal to define my hardware firewall for
security, I may have closed a needed port, but I don't see that my
problems indicate this.
> It
> should have removed all binaries, directories and files related to
> clamav. If you get errors that certain /clamav directories could not be
> removed, then they have to be very carefully removed by hand before you try
> to reinstall clamav and clamav-daemon. In clamd.conf, make sure you have:
> User clamav
I have only uninstalled/reinstalled clamav, not clamav-daemon. I'm now
removing all logs (why "carefully") and purge and reinstall both, and
restart the daemons. All went smoothly.
I do have "User amavis" in clamd.conf.
...
> > Nov 4 07:31:31 teufel postfix/local[2733]:
> > 6C15117B1: to=<[EMAIL PROTECTED]>, relay=local, delay=5,
> > status=sent (delivered to command: procmail -a "$EXTENSION")
>
> Is this evidence you have installed and are using procmail?
Apparently, and as noted above I set procmailrc to have postfix use
spamassassin.
> > Nov 4 07:31:31 teufel postfix/qmgr[21306]: 6C15117B1: removed
> > Nov 4 07:31:31 teufel amavis[2770]: (02770-03) Not-Delivered,
> > <[EMAIL PROTECTED]> -> <[EMAIL PROTECTED]>, quarantine
> > spam-ea38889258a990fcadce38ba769da151-20051104-073131-02770-03,
> > Message-ID: <[EMAIL PROTECTED]>,
> > Hits: 9.687
>
> So, it passed at 7.6 and quarantined at 9.7. Not what you seem to have
> configured.
>
> > I don't know how messages are getting into quarantine.
>
> Find out where this went:
> find / -name
> spam-ea38889258a990fcadce38ba769da151-20051104-073131-02770-03
Apparently nowhere. Find returned nothing.
> Are you sure you are editing the amavisd.conf that amavisd-new is
> using? See if you have more than one. The one normally used by amavisd-new
> on Debian is /etc/amavis/amavisd.conf
No, that's it except for a backup of a version from Feb 2004 burried
deep in a custom partition and directory (although I presume it
couldn't be found, I commented it anyway).
> find / -name amavisd.conf
> (or)
> updatedb
> locate clamd.conf
Besides /etc/clamav/clamd.conf, I have old fossils such as
/etc/clamav/clamd.conf.bak and clamd.conf.01. As for amavisd.conf,
locate tells me there is one copy where it is expected and the copy
burried in my custom partition.
> Also:
> grep amavisd.conf /usr/sbin/amavisd-new
> to see which amavisd.conf amavisd-new is looking for.
The return is: /etc/amavisd.conf
>
> > $virus_quarantine_to = undef;
> > # $QUARANTINEDIR = '/var/lib/amavis/virusmails'; (commented)
> > I do have this virusmails directory, but it is empty.
> > $spam_quarantine_to = undef;
>
> I would double check permissions and ownership of /var/lib/amavis
>
> chown -R amavis:amavis /var/lib/amavis
> chmod -R 750 /var/lib/amavis
I've got 755 for /var/lib/amavis, which should be harmless enough, I
assume. But I find 700 for /var/lib/amavis/.spamassassin and 600 for
its contents. I find 755 for /var/lib/amavis/virusmails. There are two
subdirectories in /var/lib/amavis that have names in the form
"amavis-20051104T223005-10762" which contain an empty subdirectory
"parts" (750), and a file named "email.txt". One is actually spam, but
has a spam score of 0 (not recognized as being spam), and the
email.txt in the other directory is simply the report back of my last
fetchmail run. My fetchmail just ran again as I write this, and now
the email.txt that had a spam message has been replaced by the
fetchmail report back that just occurred (I've no idea of what's
happening here). I'm changing to the the permissions you recommend
(but leaving the plain text files not executable).
The /var/lib/amavis/razor-agent.log has been running the last two
days, and seems to recognize mail as being either known spam or not
known spam. I left its permission 640.
--
Haines Brown
KB1GRM
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
