[EMAIL PROTECTED] wrote:
>Philip Prindeville wrote:
>
>
>>Could we add an example of using envelope info?
>>
>>
>
>SpamAssassin doesn't see the envelope. Some MTAs add headers for
>envelope-header and envelope-recipients (Return-Path:, X-Apparently-To:, etc.)
>
>If you're careful about how you call SpamAssassin you can fake envelope rules
>using these headers.
>
>For example MIMEDefang adds the following headers prior to calling
>SpamAssassin:
>
>Return-Path: (envelope-sender)
>Received: (sendmail-style)
>Apparently-To: (envelope-recipients)
>
>(in mimedefang.pl, sub spam_assassin_mail)
>
> # Synthesize a "Return-Path" and "Received:" header
> my @sahdrs;
> push (@sahdrs, "Return-Path: $Sender\n");
> push (@sahdrs, split(/^/m, synthesize_received_header()));
> push (@sahdrs, gen_msgid_header()) if ($MessageID eq "NOQUEUE");
> # Add To: header if one missing
> if (open(IN, "<./HEADERS")) {
> my $hto = grep { /^To:/i } <IN>;
> close(IN);
> push(@sahdrs, "To: undisclosed-recipients:;\n") unless $hto;
> }
>
> if ($AddApparentlyToForSpamAssassin and
> ($#Recipients >= 0)) {
> push(@sahdrs, "Apparently-To: " .
> join(", ", @Recipients) . "\n");
> }
> unshift (@msg, @sahdrs);
> my $sa_ver = Mail::SpamAssassin->VERSION();
> # Only keep major version number
> $sa_ver =~ s/\..*//;
> if ($sa_ver >= 3) {
> if (!defined($SASpamTester)) {
> my $object = spam_assassin_init(@_);
> return undef unless $object;
> }
> return $SASpamTester->parse([EMAIL PROTECTED]);
> } else {
> return Mail::SpamAssassin::NoMailAudit->new(data=>[EMAIL PROTECTED]);
> }
>
>
>
Ah, that works:
# coming from alsa-devel is already suspicious...
header LOCAL_ALSA_DEVEL Return-Path =~
/<[EMAIL PROTECTED]>/
describe LOCAL_ALSA_DEVEL Return-Path: from "alsa-devel"
score LOCAL_ALSA_DEVEL 3.0
I'm kind of curious as to why some of the lists on lists.sourceforge.net
seem to
do a better job blocking spam than others, even amongst lists that have
wide-open
submisssion policies.
Are the filtering policies set per-list?
Using the following with great success:
# charsets we aren't interested in
header LOCAL_CHARSETS Subject:raw =~
/=\?(gb2312|shift-jis|iso-2022-jp|iso-8859-([2-9]|1[0-9])|windows-125[013-8]|utf-8)\?/i
describe LOCAL_CHARSETS Subject: contains charsets we don't accept
score LOCAL_CHARSETS 6.0
# don't believe it...
header LOCAL_ACCOUNT From =~ /[EMAIL PROTECTED](paypal|ebay)\.com>/i
describe LOCAL_ACCOUNT From: contains eBay or PayPal address
score LOCAL_ACCOUNT 6.0
Too bad that I had to write LOCAL_CHARSETS and can't use the FARAWAY
rules instead. Sigh. I tried to understand the logic of the existing
rules, and it
seems to be too wide open. Given that email that will fit into
iso-8859-1 is
supposed to be "downgraded" to that charset, you should never see English
language text in iso-8859-2 (or -4 or -15, etc)... So the rule
shouldn't be admitting
-2 or -4 or -15 but does anyway.
-Philip
