Stephan Menzel wrote:
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.
Why is the output from "spamassassin -Dreceived-header" not sufficient
for this?
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---
Reading the documentation we see that your configuration doesn't match
what you want to do. "127.0.0", "192.168" and "10" are taken as the IPs
"127.0.0", "192.168", and "10". Which are some of the funkiest IPs that
I've ever seen. Most IPs have 32 or 128 bits.
[EMAIL PROTECTED] ~]$ perldoc Mail::SpamAssassin::Conf | grep "trusted_networks
ip" -A31
trusted_networks ip.add.re.ss[/mask] ... (default: none)
What networks or hosts are âtrustedâ in your setup. Trusted in
this case means that relay hosts on these networks are considered
to not be potentially operated by spammers, open relays, or open
proxies. A trusted host could conceivably relay spam, but will not
originate it, and will not forge header data. DNS blacklist checks
will never query for hosts on these networks.
MXes for your domain(s) and internal relays should also be speci-
fied using the "internal_networks" setting. When there are
âtrustedâ hosts that are not MXes or internal relays for your
domain(s) they should only be specified in "trusted_networks".
If a "/mask" is specified, itâs considered a CIDR-style ânetmaskâ,
specified in bits. If it is not specified, but less than 4 octets
are specified with a trailing dot, thatâs considered a mask to
allow all addresses in the remaining octets. If a mask is not
specified, and there is not trailing dot, then just the single IP
address specified is used, as if the mask was "/32".
If a network or host address is prefaced by a "!" the network or
host will be excluded (or included) in a first listed match fash-
ion.
Examples:
trusted_networks 192.168/16 127/8 # all in
192.168.*.* and 127.*.*.*
trusted_networks 212.17.35.15 # just that host
trusted_networks 127. # all in 127.*.*.*
trusted_networks !10.0.1.5 10.0.1/24 # all in 10.0.1.*
but not 10.0.1.5
trusted_networks 10.0.1/24 !10.0.1.5 # all in 10.0.1.*
including 10.0.1.5
[EMAIL PROTECTED] ~]$
To configure 127.0.0/24, 192.168/16 and 10/8 in non-CIDR notation, you'd
need to use trailing dots, like with Sendmail, or like the documentation
for SpamAssassin says. :)
As far as I can see, (($ip & $net->{mask}) == $net->{ip}) never gives true,
even when $ip == $net->{ip}
It does if the $ip in question with the mask of the configured network
applied to it, matches the network address configured. That is if the
$ip in question is in the configured subnet it will be true.
I debugged through it with many different IPs and subnet settings and it
didn't give true even once.
Like this?
[EMAIL PROTECTED] ~]$ perl -e '$ip = 0b01111111000000000000000000000001;
$net = 0b01111111000000000000000000000001;
$mask = 0b11111111111111111111111111111111;
if (($ip & $mask) == $net) { print "matches\n"; } else { print "no
match\n"; }'
matches
[EMAIL PROTECTED] ~]$
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.
Workaround what?
Daryl
