http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From [EMAIL PROTECTED] 2006-03-09 01:54 -------
(In reply to comment #33)
> is trust_path.t necessary because of this:
>
> # TODO: 3.1.x does not support redefining the ruleset, which this
> # test requires; therefore disable it.
> #
> #use Test; BEGIN { plan tests => 24 };
> use Test; BEGIN { plan tests => 0 }; exit;
>
> why bother including it if it's always going to exit?
It's useful for development surrounding trust path code. The tests actually
work, they're just really noisy unless you redirect STDERR somewhere out of
sight. For the whole ~1K it adds to the tarball, I don't think including it
hurts. There are lots of tests that ship disabled, or disabled by default.
> also, the warn that the lint check puts out should be ended with a newline, or
else you get:
>
> [2700] warn: trusted_networks doesn't contain internal_networks entry
'65.214.43.12' at /home/
> felicity/SA/spamassassin-3.1/lib/Mail/SpamAssassin/Conf/Parser.pm line 786.
Fixed in attachment 3402.
> otherwise, everytime I try thinking about internal vs trusted_networks
settings, my brain starts to hurt.
> why can't we make this simpler? something like:
>
> internal_networks == all of your IPs, assumed to never send you spam (but
could relay)
> trusted_networks == IPs who you trust to not send you spam (but could relay)
Internal networks IS NOT all of your IPs though. It cannot include your MSA if
you don't also include all of your user's IPs. Since some MTAs still don't
include auth tokens in their headers, we can't always extend the trust path to
roaming users who we don't know the IP of. So, for some MTAs, even if you know
all of your local dial-pool addresses, and your users use SMTP auth, you still
can't include your MSA in internal networks.
> therefore, trusted_networks should always include internal_networks, and I
don't see why an entry in
> internal_networks could just directly be put into trusted_networks. I'm not
opposed to the proposed
> "flag an error when both are specified and trusted doesn't include internal"
idea, though it seems like
> extra effort to have to list things twice.
The way things are now (pre-patching) makes it easy for a user who doesn't
understand or hasn't read the docs to screw up their trust path. I'm hoping
that the linting this patch adds will prevent some of these errors. Comment 28
outlines this.
Additonally, and more concretely, if there are an exclusions involved in the
config (something I've found exteremely useful in large setups, BTW), definition
order matters and is nearly impossible to get right when internal_networks
starts getting copied to trusted_networks silently and automatically.
> Honestly, I'm still not sure the internal/external difference is useful --
either the mail is delivered from/
> through only trusted sources, or at some point an untrusted source delivers
the mail directly or to a
> trusted relay. The first is ALL_TRUSTED and we don't need to look anything
up, and the second gives
> you a demarkation point... Do we ever want to lookup if a host we consider
trusted is on a RBL? If so,
> why? Shouldn't we always use nothing (which seems to be a num_check_received
limited version of -
> untrusted), -firsttrusted or -untrusted ? Right now we use nothing,
-firsttrusted, and -lastexternal.
I think trusting a received header, or all of the received headers, WITHOUT
having to provide them with all of "the ALL_TRUSTED goodness" has some use.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
