Re: Poor performance with v3.2.0
Am Dienstag, 8. Mai 2007 20:09:42 schrieb Rosenbaum, Larry M.: I am getting really poor performance with v3.2.0 compared with v3.1.8. So do we. I'm quite sorry to bring this subject up again, but bayes expire is no explanation for us. We are running spamd 3.1x on a cluster of Debian Linux boxes, configured to do no outbound DNS, RBLs, bayes, SPF, whatever. It should simply do it's rules and nothing else. Usually I keep the boxes running on a load of about 5 and it was all quite well balanced. Yesterday I tried to switch to 3.2, configured likewise and had to downgrade soon afterwards for the load was exceeding 13. Same amount of email, same loadbalancing, same hardware. Of course, a new version with lots more rules is bound to be slower but that's really a killer for us since it effectively prevents us from upgrading at all. Is there any way to configure it so it may still yield OK results but be a bit, well, modest? Thanks... Stephan signature.asc Description: This is a digitally signed message part.
spamd core dumps?
Hi, we've got spamd running under pretty heavy load and sometimes it just crashes without any visible reason after some hours. Does a crashing spamd cause any coredumps I might examine? Or is there anyting I can do to reduce the probability of those crashes? It runs on Debian Linux 2.6.16, perl 5.8.4 on an average load between 3 and 4. Greetings... Stephan pgpyL1sNPkccq.pgp Description: PGP signature
Trusted or internal networks not recognized
Hi there, I'm currently about to customize a local (gentoo~) 3.1 installation to our specific needs. One of the first steps there was a special regex to catch our very own Received: headers To check if this works I modified some other SA code parts and enabled debug out. But here I had to realize that the Received line seems to be parsed correctly but the values are never recognized as part of either our trusted or internal network. Both are set like this (I simplyfied the example a bit) /etc/spamassassin/local.cf ---snip--- clear_trusted_networks trusted_networks 127.0.0 192.168 10 ... more networks to come here clear_internal_networks internal_networks 10.1.71.0/24 10.1.3.0/24 10.1.76.29/24 ... here too ---snip--- Then I changed the code in /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Conf.pm to see if the values are actually read in. Which is the case. However, if the lines are parsed I only see stuff like this: [32116] dbg: moep: untrusted relay found 10.1.76.29 [32116] dbg: received-header: relay 10.1.76.29 trusted? no internal? no Now the way I see it, the IP of our internal relay as well as other values inside the Received line are parsed correctly. My own debug output confirmed this. And the SA code later on should only check if the ip shown there is within the trusted or internal network. Which it should be bit SA always says no to both checks no matter what I specify in /etc/spamassassin/local.cf I tried all different mails, all different configurations, I tried using spamd or piping through SA directly, I never saw any 'yes' there. I'm not the perl expert so I'm finally stuck here with my own debugging efforts and don't know what to change or check anymore. But I would really need those internal networks to be recognized. Any suggestions? Greetings... Stephan pgpAgDVHtG2u7.pgp Description: PGP signature
Re: Trusted or internal networks not recognized
Am Dienstag, 28. März 2006 16:40 schrieb Bowie Bailey:
[32116] dbg: received-header: relay 10.1.76.29 trusted? no internal?
no
Ok. Show us the entire debug section where it parses the headers.
Keep in mind that the interpretation of each header is influenced by
the headers that precede it. Once SA finds one untrusted relay,
everything else is untrusted by definition.
Of course. That's why I mostly took emails for the test that only contain
internal or trusted hops. This way I wanted to make sure not to be caught by
this effect. However, I also places debug out into this section where this is
checked. You see the message Untrusted relay found
Here is where I put this:
/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Message/Metadata/Received.pm:124
# trusted_networks matches?
$DB::single=2;
if ($in_trusted $did_user_specify_trust !$relay-{auth} !
$trusted-contains_ip ($relay-{ip}))
{
dbg(moep: untrusted relay found $relay-{ip});
$in_trusted = 0; # we're in deep water now
}
# internal_networks matches?
if ($did_user_specify_internal) {
if (!$relay-{auth} !$internal-contains_ip ($relay-{ip})) {
dbg(moep: user did specify internal but $relay-{ip} is not in it);
$in_internal = 0;
}
} else {
# if the user didn't specify it, assume we immediately transition
# to the external network (the internet) once we leave this host.
dbg(moep: user did not specify internal);
$in_internal = 0;
}
[6250] dbg: plugin: Mail::SpamAssassin::Plugin::ReplaceTags=HASH(0x8bbd81c)
implements 'finish_parsing_end'
[6250] dbg: replacetags: replacing tags
[6250] dbg: replacetags: done replacing tags
[6250] dbg: config: score set 0 chosen.
[6250] dbg: dns: dns_available set to no in config file, skipping test
[6250] dbg: moep: use trusted for internal
[6250] dbg: received-header: parsed as [ ip=10.1.76.29 rdns=
helo=mp029.v300.gmx.net by=ih001.v300.gmx.net ident= envfrom= intl=0 id=
auth= ]
[6250] dbg: moep: untrusted relay found 10.1.76.29
[6250] dbg: moep: user did specify internal but 10.1.76.29 is not in it
[6250] dbg: received-header: relay 10.1.76.29 trusted? no internal? no
[6250] dbg: received-header: parsed as [ ip=212.227.35.113 rdns= helo=
by=www1.gmx.net ident= envfrom= intl=0 id= auth= ]
[6250] dbg: received-header: relay 212.227.35.113 trusted? no internal? no
[6250] dbg: metadata: X-Spam-Relays-Trusted:
[6250] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=10.1.76.29 rdns=
helo=mp029.v300.gmx.net by=ih001.v300.gmx.net ident= envfrom= intl=0 id=
auth= ] [ ip=212.227.35.113 rdns= helo= by=www1.gmx.net ident= envfrom=
intl=0 id= auth= ]
[6250] dbg: message: MIME PARSER START
[6250] dbg: message: main message type: text/plain
[6250] dbg: message: parsing normal part
[6250] dbg: message: added part, type: text/plain
[6250] dbg: message: MIME PARSER END
[6250] dbg: message: decoding other encoding type (8bit), ignoring
[6250] dbg: rules: local tests only, ignoring RBL eval
Yow the way I see it, contains_ip() doesn't work.
I postet some debugging results on dev@spamassassin.apache.org
Here's what I thought yesterday:
Mail::SpamAssassin::NetSet::contains_ip(/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/NetSet.pm:146)
sub contains_ip {
my ($self, $ip) = @_;
if (!defined $self-{nets}) { return 0; }
if ($ip !~ m/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/) { return 0; }
$ip = Mail::SpamAssassin::Util::my_inet_aton($ip);
foreach my $net (@{$self-{nets}}) {
return !$net-{exclude} if (($ip $net-{mask}) == $net-{ip})
}
0;
}
As far as I can see, (($ip $net-{mask}) == $net-{ip}) never gives true,
even when $ip == $net-{ip}
I debugged through it with many different IPs and subnet settings and it
didn't give true even once.
I'm about to prepare a workaround and a different implementation for this
method but I'm no good in perl so it still gives me headaches.
Greetings...
Stephan
pgpERkC5IPw9J.pgp
Description: PGP signature
Re: Trusted or internal networks not recognized
Am Mittwoch, 29. März 2006 05:12 schrieb Matt Kettler: Stephan, If you want to do an implied mask to cover a whole, you MUST end in a . ie: you must use 10. not 10. If you fail to include a trailing dot, SA will expand with zeros, but it will treat it as a single IP address, not a ranged mask. Hi Matt, thank you so much! It works fine now, including my modifications. Greetings... Stephan pgpe4x9AyV9hw.pgp Description: PGP signature
Re: Trusted or internal networks not recognized
Am Mittwoch, 29. März 2006 09:20 schrieb mouss: This somewhat defeats the minimum surprise principle. In old practice, 10.1=10.0.0.1 (a.b = 256^3 * a + b), and not 10.1.0.0. ping 127.1 still works on (some|most) platforms. (telnet 127.1 works less). Wouldn't it be better to just ignore such IPs (with a warning)? That would really be nice. If you guys weren't as helpful as you are I would probably already be quite disappointed about all this. The way I see it, there is little need for 10 being recognized as 10.0.0.1 when specifying IP ranges. You may offer it but a warning in this case would be very helpful. We had several people here doing that mistake independent from each other. The initial config was done by our IT guys and I did it again since I wanted to be sure it is OK before I start debugging the problem. All versions I've seen contain this 'error' so it can't be this rare. Greetings... Stephan pgp4fQwwM8uMs.pgp Description: PGP signature
Trusted or internal networks not recognized
Hi there, I'm currently about to customize a local (gentoo~) 3.1 installation to our specific needs. One of the first steps there was a special regex to catch our very own Received: headers To check if this works I modified some other SA code parts and enabled debug out. But here I had to realize that the Received line seems to be parsed correctly but the values are never recognized as part of either our trusted or internal network. Both are set like this (I simplyfied the example a bit) /etc/spamassassin/local.cf ---snip--- clear_trusted_networks trusted_networks 127.0.0 192.168 10 ... more networks to come here clear_internal_networks internal_networks 10.1.71.0/24 10.1.3.0/24 10.1.76.29/24 ... here too ---snip--- Then I changed the code in /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Conf.pm to see if the values are actually read in. Which is the case. However, if the lines are parsed I only see stuff like this: [32116] dbg: moep: untrusted relay found 10.1.76.29 [32116] dbg: received-header: relay 10.1.76.29 trusted? no internal? no Now the way I see it, the IP of our internal relay as well as other values inside the Received line are parsed correctly. My own debug output confirmed this. And the SA code later on should only check if the ip shown there is within the trusted or internal network. Which it should be bit SA always says no to both checks no matter what I specify in /etc/spamassassin/local.cf I tried all different mails, all different configurations, I tried using spamd or piping through SA directly, I never saw any 'yes' there. I'm not the perl expert so I'm finally stuck here with my own debugging efforts and don't know what to change or check anymore. But I would really need those internal networks to be recognized. Any suggestions? Greetings... Stephan pgpgj1M8KHkaF.pgp Description: PGP signature
