RE: Rules using envelope info?
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]);
}
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
Re: Rules using envelope info?
On Tue, Feb 28, 2006 at 10:59:29AM -0800, [EMAIL PROTECTED] wrote: If you're careful about how you call SpamAssassin you can fake envelope rules using these headers. It's worth noting that there's a pseudo-header called EnvelopeFrom which is available to header rules which attempts to figure the EnvelopeFrom value from various headers that MTAs may put in the message. There's also envelope_sender_header which lets you specify which header to use, which may be necessary depending on your MTA. See the Mail::SpamAssassin::Conf POD for more info. :) -- Randomly Generated Tagline: CS... You guys are hopeless anyway... - Prof. Farr pgp2a9CZegUZ8.pgp Description: PGP signature
Re: Rules using envelope info?
[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. Actually, if these headers are present, SA will treat them as an extra From header. So really all you need to do is create a rule checking against the From header and SA will take care of the rest, provided your MTA drops the right hints in the headers.
Re: Rules using envelope info?
[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_CHARSETS6.0
# don't believe it...
header LOCAL_ACCOUNTFrom =~ /[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
Re: Rules using envelope info?
Theo Van Dinter wrote: On Tue, Feb 28, 2006 at 10:59:29AM -0800, [EMAIL PROTECTED] wrote: If you're careful about how you call SpamAssassin you can fake envelope rules using these headers. It's worth noting that there's a pseudo-header called EnvelopeFrom which is available to header rules which attempts to figure the EnvelopeFrom value from various headers that MTAs may put in the message. There's also envelope_sender_header which lets you specify which header to use, which may be necessary depending on your MTA. See the Mail::SpamAssassin::Conf POD for more info. :) Hmmm I looked at that, and tried substituting EnvelopeFrom, but it didn't work. What am I missing? Is SA not using the Return-Path: line by default? debug: all '*From' addrs: [EMAIL PROTECTED] [EMAIL PROTECTED] ... debug: SPF: checking EnvelopeFrom (helo=lists-outbound.sourceforge.net, ip=66.35.250.225, [EMAIL PROTECTED]) debug: SPF: query for [EMAIL PROTECTED]/66.35.250.225/lists-outbound.sourceforge.net: result: pass, comment: Please see http://spf.pobox.com/why.html?sender=alsa-devel-admin%40lists.sourceforge.netip=66.35.250.225receiver=mail.redfish-solutions.com: lists-outbound.sourceforge.net A 66.35.250.225 debug: registering glue method for check_for_spf_pass (Mail::SpamAssassin::Plugin::SPF=HASH(0x1701c90)) ... Do I need to use: header EnvelopeFrom =~ /[EMAIL PROTECTED]/ instead? That doesn't seem to work either. -Philip
Re: Rules using envelope info?
On Tue, Feb 28, 2006 at 12:28:52PM -0700, Philip Prindeville wrote: What am I missing? Is SA not using the Return-Path: line by default? It will, depending on where it's found in the headers, and if there's a better header found first. debug: all '*From' addrs: [EMAIL PROTECTED] [EMAIL PROTECTED] Ok, it found it there. debug: SPF: checking EnvelopeFrom (helo=lists-outbound.sourceforge.net, ip=66.35.250.225, [EMAIL PROTECTED]) Same thing there. Do I need to use: header EnvelopeFrom =~ /[EMAIL PROTECTED]/ instead? That doesn't seem to work either. The header is just the address. envfrom= is output from the SPF debug line. header EnvelopeFrom =~ /[EMAIL PROTECTED]/ ought to do it. -- Randomly Generated Tagline: He's a few fries short of a Happy Meal. pgpdY00zxKuhX.pgp Description: PGP signature
Re: Rules using envelope info?
Theo Van Dinter wrote: header EnvelopeFrom =~ /[EMAIL PROTECTED]/ ought to do it. The header is just the address. envfrom= is output from the SPF debug line. Yup. That works. Now... Is anyone going to try to talk me out of this, on the basis of it being unsound? ;-) -Philip
Re: Rules using envelope info?
Now... Is anyone going to try to talk me out of this, on the basis of it being unsound? ;-) The check someone (possibly you) showed about giving 6 points to From @paypal.com appears to be unsound unless you are really sure you will receive no paypal stuff. Which would probably be true of a mailing list, but the test didn't seem to be part of a meta checking for a list. There are better checks for forged ebay/paypal stuff. Other than that, I see no problems with having sender-specific spam checks that are more draconian than general checks. Loren
Re: Rules using envelope info?
Loren Wilton wrote: Now... Is anyone going to try to talk me out of this, on the basis of it being unsound? ;-) The check someone (possibly you) showed about giving 6 points to From @paypal.com appears to be unsound unless you are really sure you will receive no paypal stuff. Which would probably be true of a mailing list, but the test didn't seem to be part of a meta checking for a list. There are better checks for forged ebay/paypal stuff. I don't have ebay or paypal accounts, so they have no reason to contact me. I'm running 3.1.0, but I haven't seen any built-in checks catching this stuff. What better checks are you referring to? Something I need to pull down from SARE? -Philip Other than that, I see no problems with having sender-specific spam checks that are more draconian than general checks. Loren
Re: Rules using envelope info?
What better checks are you referring to? Something I need to pull down from SARE? sare_spoof or something like that, as best I recall. Loren
