Re: false positive in RCVD_IN_SORBS_DUL test
>Is your trusted_networks set correctly? Note: if you have a NATed mailserver >you >MUST set this manually, otherwise SA will mis-detect external mailservers as >being a part of your network and this rule will misfire. > >Other common signs of incorrect trusted_networks are ALL_TRUSTED matching spam, >and whitelist_from_rcvd not working. I have: internal_networks 10.0.0 and score ALL_TRUSTED 0 whitelist_from_rcvd does seem to be working. The server receives mail static NATed from the outside
Re: false positive in RCVD_IN_SORBS_DUL test
On Thu, 08 Dec 2005 03:31:21 +0100, you wrote: >2. next check if that IP delivered directly to you (= your mail server) or >not. >If yes, then this hit is legitimate. It's not your IP and it delivered >directly to you. That's exactly the kind of IP you want to check if it is >on a blacklist. I think this is the key. If it's from the first hop it should score, otherwise, not.
Re: False positive problem from mis-parsing Received lines?
From: <[EMAIL PROTECTED]>
On 12/7/05, Kai Schaetzl <[EMAIL PROTECTED]> wrote:
Not an incorrect format, but probably a format that SA mismatches, yes.
Looking at the rules (which look rather complex, so I may misinterpet it)
it seems it matches on the "dsl" part and on the IP address of the header
line instead of the HELO string. What's that MTA? Exim, Qmail?
The MTA is sendmail, but actually the Received: header is added by
Mail Avenger (an SMTP server that runs the mail through spamassassin
before passing it to sendmail).
The Received header is patterned on Received headers added by some
version of sendmail. Of course, since sendmail sets the format based
on sendmail.cf, there have probably been many different formats, but
it probably means this problem could affect other people.
If SpamAssassin has some particular prefered format for Received
headers, I'd certainly consider changing the format for the next
release of Mail Avenger. But if this is something that SpamAssassin
could fix, that would be good, too.
<< David, as Kai has tried to point out a couple times now, their
reverse DNS record is not EVER going to get past dialup list detection.
Let's play a little. We have this information:
Received: from adsl-71-133-227-154.dsl.pltn13.pacbell.net
(71.133.227.154) (HELO genstor.com)
It claims to be genstor.com. If I look up their MX record I get the
address of their name server: ns4.genstor.com. If I look that up I get
71.133.227.154. So far "sort of" so good. Now if I perform the reverse
lookup I get something WILDLY different that includes "dsl" in it
twice. This is a very typical reverse dns lookup on a dynamicly assigned
address. There is NOTHING going to get that address through the spam
assassin tests. (If it did I'd recreate the tests and install them here.)
If PacBell.net cannot see to setting up a PROPER rDNS record for the
company they're basically sunk even though they are (apparently) not on
any formal DUL lists.
The problem is NOT the format. It is the basic data content that is hosed.
{^_^}
Re: false positive in RCVD_IN_SORBS_DUL test
From: "Kai Schaetzl" <[EMAIL PROTECTED]>
Jdow wrote on Wed, 7 Dec 2005 19:18:31 -0800:
And it seems SORBS in whatever wisdom they have has Mouss'
free.fr smtp host tagged.
Well, if you would just go and check you'd know why it is on their list:
http://www.dnsstuff.com/tools/ip4r.ch?ip=212.27.42.29
As you see it's on their "spam received by a spamtrap" list. Listing it is
perfectly ok, it's just what this list contains. Many big mail providers
end up on this list. That's why one shouldn't use spam.dnsbl.sorbs.net (or
dnsbl.sorbs.net which includes it) at MTA level unless you use some
whitelisting for known mail servers you frequently get mail from. The same
can be done for SA. Or one uses the safer aggregation list which doesn't
contain spam.dnsbl.sorbs.net.
The wry quality I'd intended for the post didn't get through very well.
{^_-}
Sadly, it appears there is not much Mouss can do about it.
{^_^}Joanne
Re: False positive problem from mis-parsing Received lines?
On 12/7/05, Kai Schaetzl <[EMAIL PROTECTED]> wrote: > Not an incorrect format, but probably a format that SA mismatches, yes. > Looking at the rules (which look rather complex, so I may misinterpet it) > it seems it matches on the "dsl" part and on the IP address of the header > line instead of the HELO string. What's that MTA? Exim, Qmail? The MTA is sendmail, but actually the Received: header is added by Mail Avenger (an SMTP server that runs the mail through spamassassin before passing it to sendmail). The Received header is patterned on Received headers added by some version of sendmail. Of course, since sendmail sets the format based on sendmail.cf, there have probably been many different formats, but it probably means this problem could affect other people. If SpamAssassin has some particular prefered format for Received headers, I'd certainly consider changing the format for the next release of Mail Avenger. But if this is something that SpamAssassin could fix, that would be good, too. Thanks, David
Re: false positive in RCVD_IN_SORBS_DUL test
Jdow wrote on Wed, 7 Dec 2005 19:18:31 -0800: > And it seems SORBS in whatever wisdom they have has Mouss' > free.fr smtp host tagged. Well, if you would just go and check you'd know why it is on their list: http://www.dnsstuff.com/tools/ip4r.ch?ip=212.27.42.29 As you see it's on their "spam received by a spamtrap" list. Listing it is perfectly ok, it's just what this list contains. Many big mail providers end up on this list. That's why one shouldn't use spam.dnsbl.sorbs.net (or dnsbl.sorbs.net which includes it) at MTA level unless you use some whitelisting for known mail servers you frequently get mail from. The same can be done for SA. Or one uses the safer aggregation list which doesn't contain spam.dnsbl.sorbs.net. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: False positive problem from mis-parsing Received lines?
wrote on Wed, 7 Dec 2005 18:15:05 -0800: > A friend has suggested this may be a bug in the way that SpamAssassin > parses the Received header. Is this, in fact, a bug in SpamAssassin? > Or is my SMTP server generating Received: headers using an > incorrect format? Not an incorrect format, but probably a format that SA mismatches, yes. Looking at the rules (which look rather complex, so I may misinterpet it) it seems it matches on the "dsl" part and on the IP address of the header line instead of the HELO string. What's that MTA? Exim, Qmail? Received: from adsl-71-133-227-154.dsl.pltn13.pacbell.net (71.133.227.154) (HELO genstor.com) This are the matching rules: header HELO_DYNAMIC_DHCP X-Spam-Relays-Untrusted =~ /^[^\]]+ helo=\S*(?:cm|catv|docsis|cable|dsl|dhcp|cpe|node)\S*\d+[^\d\s]+\d+[^\]]+ auth= /i HELO_DYNAMIC_HCC X-Spam-Relays-Untrusted =~ /^[^\]]+ helo=\S*\d+[^\d\s]+\d+\S*\.(?:docsis|cable|dsl|adsl|dhcp|cpe)\.[^\]]+ auth= /i HELO_DYNAMIC_IPADDR X-Spam-Relays-Untrusted =~ /^[^\]]+ helo=[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]] + auth= /i It's a nuisance that there's not a single forcable Received format :-( Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: false positive in RCVD_IN_SORBS_DUL test
From: "Matt Kettler" <[EMAIL PROTECTED]>
mouss wrote:
Matt Kettler a écrit :
Russ Ringer wrote:
Why did this message trigger these rules?
The email was not sent directly from a dial-up IP.
Is your trusted_networks set correctly? Note: if you have a NATed
mailserver you
MUST set this manually, otherwise SA will mis-detect external
mailservers as
being a part of your network and this rule will misfire.
Other common signs of incorrect trusted_networks are ALL_TRUSTED
matching spam,
and whitelist_from_rcvd not working.
my own messages to this list get a RCVD_IN_SORBS on my own SA.
That's kinda weird. Let's get a trusted_networks setup done properly and if that
doesn't fix it, we'll revisit this.
Is it that weird given that it has gone out of his site, to this list's
reflector, and back to his machine? So it is not "ALL_TRUSTED" by any
means. And it seems SORBS in whatever wisdom they have has Mouss'
free.fr smtp host tagged.
Received: from [212.27.42.29] (HELO smtp3-g19.free.fr) (212.27.42.29)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2005 16:32:07 -0800
Test the IP address and be enlightened. That is off in the middle of
the ultimate path between him and the list.
{^_^}
Re: False positive problem from mis-parsing Received lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Kettler writes: > [EMAIL PROTECTED] wrote: > > I'm using SpamAssassin version 3.1.0 with default options, and have > > run into a serious false positive problem. When I receive mail from > > one of my correspondents, I get Received: lines like this one: > > > > Received: from adsl-71-133-227-154.dsl.pltn13.pacbell.net > > (71.133.227.154) (HELO genstor.com) > > (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) > > by scs.stanford.edu with SMTP; > > for [EMAIL PROTECTED]; > > Wed, 07 Dec 2005 14:39:46 -0800 (PST) > > > > That line alone is enough to flag a message as spam. It hits 3 > > different rules: > > > > 2.7 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) > > 3.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) > > 3.4 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr > > 1) > > > > While I agree that maybe mail received from a DSL line like the above > > should get a few points, it seems unreasonable to push it so far above > > the default 5-point threshold--particularly when nothing else in the > > message hit any rules. > > > > A friend has suggested this may be a bug in the way that SpamAssassin > > parses the Received header. Is this, in fact, a bug in SpamAssassin? > > Or is my SMTP server generating Received: headers using an > > incorrect format? (I don't see anything prohibiting that format in > > RFC 2822.) > > > No, I think this is outright ordinary. You directly got the mail from a DSL > node. Normally the parsing or trust-path problems would cause these rules to > fire for all DSL nodes, including those relayed through the ISP mailserver. > > In general SA (and most of the civilized world) assumes your server should > never > directly receive mail *directly* from a "home user" type system, and those > should be relayed through the ISP servers. actually, there may be a problem; it looks like SpamAssassin is treating "adsl-71-133-227-154.dsl.pltn13.pacbell.net" as the HELO string, instead of 'genstor.com'. - --j. > Some questions: > > If it is a dynamic-ip home user, why aren't they using pacbell's SMTP server? > > If it's a static-IP business user, why haven't they asked pacbel to set their > RDNS? Why have they left it the generic "nobody has really set this up for use > as a server site" values? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh CVS iD8DBQFDl6BDMJF5cimLx9ARApNKAJ0WsZnCu77MByxAK0hiFELaTEiUlACggK9k HCkzhHJ5+tzME21n6HAsyIY= =mMgm -END PGP SIGNATURE-
Re: False positive problem from mis-parsing Received lines?
[EMAIL PROTECTED] wrote: > I'm using SpamAssassin version 3.1.0 with default options, and have > run into a serious false positive problem. When I receive mail from > one of my correspondents, I get Received: lines like this one: > > Received: from adsl-71-133-227-154.dsl.pltn13.pacbell.net > (71.133.227.154) (HELO genstor.com) > (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) > by scs.stanford.edu with SMTP; > for [EMAIL PROTECTED]; > Wed, 07 Dec 2005 14:39:46 -0800 (PST) > > That line alone is enough to flag a message as spam. It hits 3 > different rules: > > 2.7 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) > 3.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) > 3.4 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr 1) > > While I agree that maybe mail received from a DSL line like the above > should get a few points, it seems unreasonable to push it so far above > the default 5-point threshold--particularly when nothing else in the > message hit any rules. > > A friend has suggested this may be a bug in the way that SpamAssassin > parses the Received header. Is this, in fact, a bug in SpamAssassin? > Or is my SMTP server generating Received: headers using an > incorrect format? (I don't see anything prohibiting that format in > RFC 2822.) No, I think this is outright ordinary. You directly got the mail from a DSL node. Normally the parsing or trust-path problems would cause these rules to fire for all DSL nodes, including those relayed through the ISP mailserver. In general SA (and most of the civilized world) assumes your server should never directly receive mail *directly* from a "home user" type system, and those should be relayed through the ISP servers. Some questions: If it is a dynamic-ip home user, why aren't they using pacbell's SMTP server? If it's a static-IP business user, why haven't they asked pacbel to set their RDNS? Why have they left it the generic "nobody has really set this up for use as a server site" values?
Re: false positive in RCVD_IN_SORBS_DUL test
Mouss wrote on Thu, 08 Dec 2005 01:35:32 +0100: > my own messages to this list get a RCVD_IN_SORBS on my own SA. my first > reaction is to remove all sorbs tests (because I don't believe in > sorbs), but I still wanna understand why this happens. You have to make a distinction between an IP being on the SORBS list and the fact that RCVD_IN_SORBS hits a mail. A procedure to check it may be done as follows (please correct or detail if someone feels fit): 1. first check which IP was found to be on this list. In general the SORBS list doesn't have many false positives, but if there is one the location to report or complain is dnsbl.sorbs.net. This is not an SA issue at all, specifically it's not an SA false positive. 2. next check if that IP delivered directly to you (= your mail server) or not. If yes, then this hit is legitimate. It's not your IP and it delivered directly to you. That's exactly the kind of IP you want to check if it is on a blacklist. If no, this means the IP didn't deliver directly to you. It could be another mail server/hub/forwarder in the chain to you or it could be a dialup client delivering to his ISP's server which then delivered to you. It's a bit pesky to check this. You have to read the header lines carefully. Anyway, when this happens it's likely that SA cannot determine which hosts belong to your network and thinks that ISP's server belongs to your network. So, it thinks that dialup client is delivering directly to *you* and that's exactly what we want to check on an RBL, don't we (see above)? The problem is that this assumption is wrong. To correct it you have to tell SA where your network boundary is and that's what the trusted_networks Matt mentions is for. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
False positive problem from mis-parsing Received lines?
I'm using SpamAssassin version 3.1.0 with default options, and have run into a serious false positive problem. When I receive mail from one of my correspondents, I get Received: lines like this one: Received: from adsl-71-133-227-154.dsl.pltn13.pacbell.net (71.133.227.154) (HELO genstor.com) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by scs.stanford.edu with SMTP; for [EMAIL PROTECTED]; Wed, 07 Dec 2005 14:39:46 -0800 (PST) That line alone is enough to flag a message as spam. It hits 3 different rules: 2.7 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) 3.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) 3.4 HELO_DYNAMIC_IPADDRRelay HELO'd using suspicious hostname (IP addr 1) While I agree that maybe mail received from a DSL line like the above should get a few points, it seems unreasonable to push it so far above the default 5-point threshold--particularly when nothing else in the message hit any rules. A friend has suggested this may be a bug in the way that SpamAssassin parses the Received header. Is this, in fact, a bug in SpamAssassin? Or is my SMTP server generating Received: headers using an incorrect format? (I don't see anything prohibiting that format in RFC 2822.) Do people have suggestions for working around the problem (other than just re-scoring those three rules, which may be useful in other circumstances)? Thanks, David
Re: false positive in RCVD_IN_SORBS_DUL test
mouss wrote: > Matt Kettler a écrit : > >> Russ Ringer wrote: >> >>> Why did this message trigger these rules? >>> The email was not sent directly from a dial-up IP. >> >> >> >> Is your trusted_networks set correctly? Note: if you have a NATed >> mailserver you >> MUST set this manually, otherwise SA will mis-detect external >> mailservers as >> being a part of your network and this rule will misfire. >> >> Other common signs of incorrect trusted_networks are ALL_TRUSTED >> matching spam, >> and whitelist_from_rcvd not working. >> >> > > > my own messages to this list get a RCVD_IN_SORBS on my own SA. That's kinda weird. Let's get a trusted_networks setup done properly and if that doesn't fix it, we'll revisit this. my first > reaction is to remove all sorbs tests (because I don't believe in > sorbs), but I still wanna understand why this happens. Yes, you should, because you're experiencing one symptom of a much larger problem. SA really needs to understand your network topology to parse Received: headers properly. This affects a lot more than just DUL tests and will cause you more problems later. > > can I use a domain name in trusted_networks? No it must be IP addresses. and don't think that "trusted" here has anything to do with whitelisting. It doesn't. Read the wiki: http://wiki.apache.org/spamassassin/TrustPath trusted_networks should be a list of known trustworthy mailservers that do not forge Received: headers. Generally speaking you should have your mailservers, and no other mailservers listed here.
Re: false positive in RCVD_IN_SORBS_DUL test
Matt Kettler a écrit : Russ Ringer wrote: Why did this message trigger these rules? The email was not sent directly from a dial-up IP. Is your trusted_networks set correctly? Note: if you have a NATed mailserver you MUST set this manually, otherwise SA will mis-detect external mailservers as being a part of your network and this rule will misfire. Other common signs of incorrect trusted_networks are ALL_TRUSTED matching spam, and whitelist_from_rcvd not working. my own messages to this list get a RCVD_IN_SORBS on my own SA. my first reaction is to remove all sorbs tests (because I don't believe in sorbs), but I still wanna understand why this happens. can I use a domain name in trusted_networks?
adding header via pure perl
How would I go about adding a header in the perl code below, the value
of the header would be dynamic on a per message basis so I don't think a
local.cf mod would help me.
I've tried dynamically touching $spamtest->{conf}->{headers_spam} and
$spamtest->{conf}->{headers_ham}, as well as a few other incantations,
but haven't quite found the magic to make it work.
We're using SA3.04 on Windows
(using $hdr & $hdrval below)
Please and Thank you,
Steven
---
sub is_message_spam {
my $message_txt = $_[0];
my @messages = @{$_[3]};
my %opts = %{$_[4]};
my $hdr = "X-Spam-InternalId";
my $hdrval = $_[5];
my $spamtest = new Mail::SpamAssassin(\%opts);
if (!defined($spamtest)) {
logthis("SPAMTEST: Unable to create SpamAssassin
object",[EMAIL PROTECTED]);
return 0;
}
my $mail = $spamtest->parse($message_txt);
my $status = $spamtest->check($mail);
$mail = $status->get_message();
$_[1] = $mail;
$_[2] = $status;
@{$_[3]} = @messages;
$_[0] = $status->rewrite_mail();
if ($status->is_spam()) {
return 1;
} else {
return 0;
}
}
Re: SpamAssassin 3.0.5 RELEASED
On Wed, Dec 07, 2005 at 08:41:58AM -0500, Rose, Bobby wrote: > Is anyone else having problems getting to www.apache.org? I've tried > from work and from home. The site acts like it's trying to load and > then eventually gives the generic cannot find server or DNS error. It's > not DNS because the FQDN resolves. I saw something earlier today about the main apache web server being down, I assume for hardware issues (though the mail I saw wasn't specific). It seems to be back up now, fwiw. :) -- Randomly Generated Tagline: A fool searches for a greater fool to find admiration. pgpmr5M3xvhNA.pgp Description: PGP signature
Re: false positive in RCVD_IN_SORBS_DUL test
Russ Ringer wrote: > Why did this message trigger these rules? > The email was not sent directly from a dial-up IP. Is your trusted_networks set correctly? Note: if you have a NATed mailserver you MUST set this manually, otherwise SA will mis-detect external mailservers as being a part of your network and this rule will misfire. Other common signs of incorrect trusted_networks are ALL_TRUSTED matching spam, and whitelist_from_rcvd not working.
false positive in RCVD_IN_SORBS_DUL test
Why did this message trigger these rules? The email was not sent directly from a dial-up IP. RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [209.30.176.199 listed in combined.njabl.org] RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [209.30.176.199 listed in dnsbl.sorbs.net] Received: from smtp109.sbc.mail.mud.yahoo.com (68.142.198.208) by mail.avtcorp.com with SMTP; 7 Dec 2005 21:03:26 - Received: (qmail 42892 invoked from network); 7 Dec 2005 21:03:25 - Received: from unknown (HELO proxyplus.universe) ([EMAIL PROTECTED]@209.30.176.199 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 7 Dec 2005 21:03:25 - Received: from cindy [156.56.61.27] by Proxy+; Wed, 07 Dec 2005 15:17:34 -0600 for <[EMAIL PROTECTED]> From: "cindy darling" <[EMAIL PROTECTED]> To: "Judy Grecco" <[EMAIL PROTECTED]> Subject: RE: Request for quote using SA 3.03 Do I need to upgrade? Thanks, ->Russ
Re: SpamAssassin 3.0.5 RELEASED
On Wednesday 07 December 2005 06:44 am, François Conil wrote: > Rose, Bobby wrote: > > Is anyone else having problems getting to www.apache.org? I've tried > > from work and from home. The site acts like it's trying to load and > > then eventually gives the generic cannot find server or DNS error. It's > > not DNS because the FQDN resolves. > > Same here. Out mirror here is up and running fine and does have the 3.0.5 release: http://www.axint.net/apache/ pgppMOVsiTbAJ.pgp Description: PGP signature
Re: Rule for Stock Spam
On Wednesday 07 December 2005 06:33 am, Matthew Daubenspeck wrote: > Recently I have been receiving a TON of Stock Spam lately. For the most > part, the subject is news related (news, updated news, breaking news, > etc) and the message itself is empty except for a .GIF file with Stock > information on it. Has anyone seen these and come up with a custom rule > to stop them? Works great here (watch wrapping): header __SUBJ_NEWS Subject =~ /(^news$)|(^[a-z]+ news$)|(^news alert$)|(^press release$)|(^news report$)|(^winner$)|(^plea?s[ae]nt news$)/i meta SENET_BRK_NEWS_GIF (__SUBJ_NEWS && (HTML_IMAGE_ONLY_04 || HTML_IMAGE_ONLY_08)) describe SENET_BRK_NEWS_GIF Breaking news (gif) score SENET_BRK_NEWS_GIF8.0
Re: Are Duplicate Rules OK?
On Wed, Dec 07, 2005 at 12:22:46PM -0500, Matt Kettler wrote: > last parsed. (They're parsed default dir, site dir, user prefs, and in > alpha-order within directories) ... and as usual, run with -D and it'll tell you the exact order it's using (along with a bunch of other potentially interesting things). :) -- Randomly Generated Tagline: "My opinions are my own. My employer doesn't want them." - Unknown pgp9ABAy6t9Gw.pgp Description: PGP signature
RE: URIBL False positive
Jeff Chan wrote: > Thanks. americanbroadcastdx.com was never on any SURBLs, so > it's probably the bug. Please consider upgrading to 3.1 or > possibly even 3.0.5 as this may fix the bug: > > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3997 > > The developers will know for sure about which versions the > patch is in. Or you could perhaps apply the patch manually to 3.0.4. > They would know that too. > > It may be worth asking if you have any unusual DNS > arrangement such as proxying firewalls, etc. Nothing unusual there. It uses the firewall (IPCop) as a caching DNS server, and the ISP's DNS as a fallback (not that that would help if the firewall were down). I'll see what I need to do to update. I think I used yum to install it in the first place, but something's hosed in the package dependencies. I'll get to work on that & see if I can get a newer spamassassin installed. Thanks for your help! Brian Leyton IT Manager Commercial Petroleum Equipment
Re: Are Duplicate Rules OK?
Clay Davis wrote: > How does SpamAssassin handle rules that are duplicated in different .cf > files? Yes. Which takes precedence? last parsed. (They're parsed default dir, site dir, user prefs, and in alpha-order within directories)
Re: URIBL False positive
On Wednesday, December 7, 2005, 8:31:06 AM, Brian Leyton wrote: > Jeff Chan wrote: >> >> OK I can't remember if that one has the bug fix or not. 3.1 >> definitely does. >> >> What was the specific FP domain? > Here's the scoring section of the SA report: > Content analysis details: (5.5 points, 5.0 required) > pts rule name description > -- > -- > -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% > [score: 0.] > 2.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist > [URIs: americanbroadcastdx.com] > 0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist > [URIs: americanbroadcastdx.com] > 1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist > [URIs: americanbroadcastdx.com] > 4.3 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist > [URIs: americanbroadcastdx.com] > Brian Leyton > IT Manager > Commercial Petroleum Equipment Thanks. americanbroadcastdx.com was never on any SURBLs, so it's probably the bug. Please consider upgrading to 3.1 or possibly even 3.0.5 as this may fix the bug: http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3997 The developers will know for sure about which versions the patch is in. Or you could perhaps apply the patch manually to 3.0.4. They would know that too. It may be worth asking if you have any unusual DNS arrangement such as proxying firewalls, etc. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: Storing Global Rules in mysql
is there a way to store global filter rules in mysql? I have written an web frontend for administering spamassassin rules. But at the moment i got the problem to store all rules in one file (it's to big and makes the server slow). i searched with google, but i found just solutions to store userprefs in mysql. Check this thread from a week ago: http://marc.theaimsgroup.com/?l=spamassassin-users&m=113336589703466&w=2 Short answer: No, you can't.
RE: URIBL False positive
Jeff Chan wrote: > > OK I can't remember if that one has the bug fix or not. 3.1 > definitely does. > > What was the specific FP domain? Here's the scoring section of the SA report: Content analysis details: (5.5 points, 5.0 required) pts rule name description -- -- -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.] 2.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist [URIs: americanbroadcastdx.com] 0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist [URIs: americanbroadcastdx.com] 1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: americanbroadcastdx.com] 4.3 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: americanbroadcastdx.com] Brian Leyton IT Manager Commercial Petroleum Equipment
Re: URIBL False positive
On Wednesday, December 7, 2005, 8:14:43 AM, Brian Leyton wrote: > Jeff Chan wrote: >> What version of SpamAssassin are you using? There is a bug >> in 3.0.x that can cause intermittent errors like this. > "Spamassassin -V" reports: > SpamAssassin version 3.0.4 > running on Perl version 5.8.6 > Brian Leyton > IT Manager > Commercial Petroleum Equipment OK I can't remember if that one has the bug fix or not. 3.1 definitely does. What was the specific FP domain? Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
RE: URIBL False positive
Jeff Chan wrote: > What version of SpamAssassin are you using? There is a bug > in 3.0.x that can cause intermittent errors like this. "Spamassassin -V" reports: SpamAssassin version 3.0.4 running on Perl version 5.8.6 Brian Leyton IT Manager Commercial Petroleum Equipment
Re: submit to spamcop
On Tuesday, December 6, 2005, 7:01:45 AM, Jean-Paul Natola wrote: > I received another one of those HTML messages about stock quotes [...] > The previous ones were stopped due to the IP being listed in spamcop, > I would like to report the IP this one came from BUT , I would like to make > sure its not some innocent person, that was used as a relay vicitm At this point of Internet history there should be very few open relays, if that's what you're referring to. Any mail server that would allow mail to be relayed through it would tend to get so flooded with spam as to be unusable. Also most MTAs like sendmail, postfix, etc., for a long time now have shipped with default configurations that *don't* allow open relaying. So open relays aren't common. These days most spams are probably sent by virus/trojan/malware- infected PCs without the owners' knowledge. Given that most people who run proper mail servers probably keep them reasonably secure and most spam is sent through infected machines, you generally won't be harming many legitimate senders by blacklisting the sender IPs of the very common spam types. Most of those are simply infected or compromised machines. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: URIBL False positive
On Tuesday, December 6, 2005, 1:26:32 PM, Brian Leyton wrote: > I'm relatively new to SpamAssassin, but I've managed to get it working well > in conjunction with MimeDefang. I'm having a strange problem though, which > I hope someone can help me figure out. > I'm on a hobby mailing list, and occasionally emails to this list are being > tagged as spam by SpamAssassin, based on the website mentioned in the emails > being on multiple URIBL lists. Strangely though, when I go to the SURBL > checker at rulesemporium.com, the site is NOT shown as being listed on any > of these lists. > Bayes correctly considers these emails to NOT be spam, but the 4 URIBL > positives are enough to put the score over the top. What version of SpamAssassin are you using? There is a bug in 3.0.x that can cause intermittent errors like this. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Storing Global Rules in mysql
Hi there, is there a way to store global filter rules in mysql? I have written an web frontend for administering spamassassin rules. But at the moment i got the problem to store all rules in one file (it's to big and makes the server slow). i searched with google, but i found just solutions to store userprefs in mysql. Thanx Peter
Are Duplicate Rules OK?
How does SpamAssassin handle rules that are duplicated in different .cf files? Which takes precedence? Thanks, Clay
Re: SpamAssassin 3.0.5 RELEASED
Rose, Bobby wrote: Is anyone else having problems getting to www.apache.org? I've tried from work and from home. The site acts like it's trying to load and then eventually gives the generic cannot find server or DNS error. It's not DNS because the FQDN resolves. Same here. -- François Conil Administrateur Systèmes et Réseaux Oh man... my mom just asked me to rewind the dvd for her
RE: SpamAssassin 3.0.5 RELEASED
Is anyone else having problems getting to www.apache.org? I've tried from work and from home. The site acts like it's trying to load and then eventually gives the generic cannot find server or DNS error. It's not DNS because the FQDN resolves. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 10:10 PM To: dev@spamassassin.apache.org; users@spamassassin.apache.org Cc: Warren Togami Subject: SpamAssassin 3.0.5 RELEASED -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (NOTE: this is a maintainance release of the 3.0.x branch. If you are already running the more up-to-date, stable 3.1.0, pay no attention! This is only for people who are stuck on 3.0.x for some reason.) We got enough votes for those tarballs we voted on last week, so it's an official release now. Here are the checksums: md5sum of archive files: 0d6066561db3e4efff73f00c34584cb8 Mail-SpamAssassin-3.0.5.tar.bz2 12c9f14ffaeb5cb3b5801cc5b5231cdd Mail-SpamAssassin-3.0.5.tar.gz e0d0e556d5929bb209aedc91ccdb2358 Mail-SpamAssassin-3.0.5.zip sha1sum of archive files: 30dcfce390a311dfff9430c1b00ae4f7e4357ca8 Mail-SpamAssassin-3.0.5.tar.bz2 99051775deb4566077fdca57a274531bade19bc8 Mail-SpamAssassin-3.0.5.tar.gz 7632e774d111764f041efb9e42453fc38885a1c2 Mail-SpamAssassin-3.0.5.zip And they're available at http://www.apache.org/dist/spamassassin/ . Abbreviated changelog: - - bug 4464: Trivial doco change - - bug 4346: Skip large messages in sa-learn - - bug 4570: Optimize a regexp that was blowing perl stack trying to parse very long headers - - Bug 4275: Fix some incorrectly case-insensitive URL parsing regexps - - bug 3712: more efficient parsing of messages with lots of newlines in header - - bug 4065: Recognize new outlook express msgid format - - bug 4390: Recognize URLs obfuscated using backslashes - - bug 4439: Fix removal of markup when there are DOS newlines - - bug 4565: new Yahoo server naming is causing FORGED_YAHOO_RCVD false positives - - bug 4522: URI parsing with JIS encoding - - bug 4655: fix redhat init script for spamd to be smarter about stopping processes - - bug 4190: race condition in round-robin forking algorithm - - bug 4535: parse mime content boundary with -- correctly - - bug 3949: fix ALL_TRUSTED misfires - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Exmh CVS iD8DBQFDllKcMJF5cimLx9ARAicsAJ9scH3eWPq7rf3g2usGIPjZnf5cQQCglK8g WdqjzNMaHzszmTI5xT8nHjk= =aU+H -END PGP SIGNATURE-
Rule for Stock Spam
Recently I have been receiving a TON of Stock Spam lately. For the most part, the subject is news related (news, updated news, breaking news, etc) and the message itself is empty except for a .GIF file with Stock information on it. Has anyone seen these and come up with a custom rule to stop them? Thanks in advance. -- Matthew Daubenspeck http://www.oddprocess.org Gentoo Linux 2.6.14-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 2800+ 08:29:50 up 19:42, 2 users, load average: 0.14, 0.17, 0.16
Re: ISP relay /whitelist question
Jean-Paul Natola wrote on Tue, 6 Dec 2005 21:06:49 -0500: > I she > tried using their SMTP but then I get this in the log > > 2005-12-05 13:48:59 H=dsl-201-128-150-16.prod-infinitum.com.mx (acerL1) > [201.128.150.16] F=<[EMAIL PROTECTED]> rejected RCPT > <[EMAIL PROTECTED]>: relay not permitted I assume you wanted to say "*if* she tried using their SMTP I get this in the log"? The log shows that she did *not* try their SMTP but yours. And it rejected it correctly because she's not an allowed SMTP AUTH user. Tell her to use Prodigy's mail server. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de & http://msie.winware.org
Re: Learning at an MTA
Alan Gutierrez a écrit :
if the user didn't copy the FP message (he just moved it to the
Junk/Error folder, then it should be "redelivered" after sa-learn (but
one must make sure it is not delivered to the Junk folder again).
I hope this is the final piece of the puzzle, but, how do you resend?
by using the MDA (maildrop in my case). using the MTA is feasible, but:
- requires getting around delivery loop. see below
- will add Received headers
- the message will be filtered again, and may thus end up in the Junk
folder oince again (just because you retrain doesn't mean SA will catch
it next time). If so, the user will get crazy and shoot you:)
instead, by running the MDA with a special option (or env var if you
prefer) to skip Junk "classification", the message will be stored to the
right folder.
I've tried...
formail -s /usr/sbin/sendmail -t alan < redeliver
...but I'm getting a forwarding loop bounce message.
This is because of the Delivered-To header.
You should remove the one that contains the final recipient ("[EMAIL PROTECTED]" in
your example above). it should be the top-most Delivered-To header in
the message. If so, then 'grep -m 1 -v "^Delivered-To:"' should do.
Re: X-Spam headers placement issue
From: "Graham Murray" <[EMAIL PROTECTED]>
"jdow" <[EMAIL PROTECTED]> writes:
Don't bother to try to report spam with that header placement if you
expect outfits that use DCC to respond. Placing the headers at the
bottom that way will screw up the DCC hash they can use to identify
the message details as "truth".
But does spamassassin -r not strip all the headers it inserted before
reporting to DCC, Pyzor, spamcop etc? So the header placement should
make no difference to DCC.
That would work if no other spacing elements were changed along with the
header cleanup. It does make manual reports by forwarding email to
[EMAIL PROTECTED] more difficult, though. Sometimes it IS more polite to
report to the ISP than the spamnazis like spamcop.
{^_^}
