Greetings,
I've spent many hours spread out over weeks scouring the Internet and
message archives and FAQs and such, and am unable to find a solution to
the problem I'm having.
I have a Postifx+AmavisNew+SpamAssassin+ClamAV setup for my mail
server. It's all running on Ubuntu Server 10.04 LTS. I've had this
configuration for many years, and have always had a problem receiving
some RTF attachments. Here are the pertinent details:
Postfix: 2.8.5-2
Amavisd-new: 2.6.4
ClamAV: 0.97.5
SpamAssassin: 3.3.1
Perl: 5.10.1
Sometimes (but not always) when I receive an RTF attachment, the mail
can't be delivered. A single amavis child pegs a CPU. Through much
debugging, I've turned off ClamAV, turned ClamAV back on, and then
turned off SpamAssassin. When I disabled Amavis's call to SpamAssassin,
the mail cruised right through my system fine. This lead me to believe
it was a problem with SpamAssassin.
I managed to capture (though a deferred email that I captured with
'postcat') a single email that contained a problematic RTF attachment.
Running 'spamassassin -t < emailfile' resulted in the process locking
up to the point that I had to 'kill -9' the process in another window. I
waited 15 minutes for the process to finish, and it never did.
My questions are these:
Is there a way to disable SpamAssassin from scanning certain attachment
types (e.g.: RTFs)?
If not, is there a way to tell SpamAssassin to only scan the first X
bytes of an email? I've tried the amavis config of
'$sa_mail_body_size_limit' and set it to a ridiculously low number
(e.g.: 10 bytes) but this did not resolve the problem.
Is there a bug/flaw in SpamAssassin or one of its add-ons that I should
be looking to upgrade to get away from this issue?
What other details/information do you need from me to assist me in
troubleshooting this issue?
Thanks in advance for any time and consideration you give to this
email.
PS: I can't share my problematic RTF file since it contains a legal
contract I'm not allowed to share with the public.
