[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vps-mail] How can procmail identify report_safe-wrapped spam?



For SA 2.63:

1. I simply have procmail scanning the "body" looking
for the " X-Spam-Level:" header. I put "body" in
quotes because as you have noted, with the report_safe
function, it technically is no longer a header -- but
it IS still in the email, near the beginning (a few
lines after the report) - so procmail will find it in
a scan. 

2. If that isn't acceptable to you, try setting the
report_safe_copy_headers option; syntax: 

report_safe_copy_headers header_name ...
    If using report_safe, a few of the headers from
the original message are copied into the wrapper
header (From, To, Cc, Subject, Date, etc.) If you want
to have other headers copied as well, you can add them
using this option. You can specify multiple headers on
the same line, separated by spaces, or you can just
use multiple lines.

(From:
http://spamassassin.taint.org/doc/Mail_SpamAssassin_Conf.html)

-Abigail

--- Lang Zerner <lang@xxxxxxxxxxxx> wrote:

> Some of my VPS v2 customers complain that spam stays
> in their inboxes, 
> even when they're configured to have spam delivered
> to another mailbox, 
> or to /dev/null.
> 
> It appears that the SpamAssassin default is now to
> have report_safe on.  
> That means that when SpamAssassin identifies a
> message as spam, it adds 
> an "X-Spam-Status: Yes"header as usual, but *then*
> it wraps the spammy 
> message as a MIME attachment in an
> automatically-generated "report" message:
> 
> Spam detection software, running on the system 
> "mail-server.mydomain.com", has
> identified this incoming email as possible spam. The
> original message
> has been attached to this so you can view it (if it
> isn't spam) or block
> similar future email. If you have any questions, see
> the administrator of that system for details.
> 
> Unfortunately, the report message (which
> SpamAssassin creates to safely 
> wrap the spam and thus prevent inadvertent viewing
> of potentially 
> malicious scripts) is not itself spam, so its
> X-Spam-Status header says 
> it is *not* spam.  That means procmail no longer
> identifies the message 
> as spam, so users who want to redirect spam to
> /dev/null or another 
> mailbox no longer get the behavior they used to.
> 
> Okay, that's the problem.  Now, I'm trying to devise
> a solution.  One is 
> to turn off report_safe globally, so procmail can
> see the 
> "X-Spam-Status: Yes" header again.  This isn't
> ideal, for all the 
> reasons that report_safe is a good idea.  But
> without doing this, I 
> don't see any way for procmail to identify one of
> these report messages 
> other than scanning the body of the message, which
> isn't really reliable 
> because the body text may change in future versions
> of SA.
> 
> How can I get procmail to reliably identify
> report_safe messages as 
> spam?  Is there a way to make SpamAssassin put an
> identifying header 
> onto messages it wraps in report_safe messages?
> 
> Thanks,
> --Lang
> 

======================================================================
This is <vps-mail@xxxxxxxxxxxx>       <http://www.perlcode.org/lists/>
Before posting a question, please search the archives (see above URL).


Main Index | Thread Index
Match: Format: Sort by:
Search: