You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2006/01/10 21:04:49 UTC
[Bug 4760] New: possible to be in internal_networks without being in trusted_networks
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
Summary: possible to be in internal_networks without being in
trusted_networks
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: minor
Priority: P5
Component: Libraries
AssignedTo: dev@spamassassin.apache.org
ReportedBy: jm@jmason.org
user_prefs:
trusted_networks 212.17.35.15 212.17.35.167 64.81.84.115 209.204.159.4
trusted_networks 213.228.0/24
internal_networks 10.19.72/24 127/8
test message: (attached)
[10661] dbg: received-header: parsed as [ ip=127.0.0.1 rdns=localhost
helo=localhost by=radish.jmason.org ident= envfrom= intl=0 id=55E8F590021 auth= ]
[10661] dbg: received-header: relay 127.0.0.1 trusted? no internal? yes
[10661] dbg: received-header: found fetchmail marker outside trusted area, ignored
[10661] dbg: received-header: parsed as [ ip=212.69.37.57
rdns=node3.firecluster.net helo=node3.firecluster.net by=amgod.boxhost.net
ident= envfrom= intl=0 id=986B93103FD auth= ]
[10661] dbg: received-header: relay 212.69.37.57 trusted? no internal? no
[10661] dbg: received-header: parsed as [ ip=81.86.144.56
rdns=81-86-144-56.dsl.pipex.com helo=langesund.timj.co.uk
by=node3.firecluster.net ident= envfrom= intl=0 id=1DTjD3-0004of-Bp auth=esmtpa ]
[10661] dbg: received-header: relay 81.86.144.56 trusted? no internal? no
[10661] dbg: metadata: X-Spam-Relays-Trusted:
[10661] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=127.0.0.1 rdns=localhost
helo=localhost by=radish.jmason.org ident= envfrom= intl=1 id=55E8F590021 auth=
] [ ip=212.69.37.57 rdns=node3.firecluster.net helo=node3.firecluster.net
by=amgod.boxhost.net ident= envfrom= intl=0 id=986B93103FD auth= ] [
ip=81.86.144.56 rdns=81-86-144-56.dsl.pipex.com helo=langesund.timj.co.uk
by=node3.firecluster.net ident= envfrom= intl=0 id=1DTjD3-0004of-Bp auth=esmtpa ]
it makes no sense for an IP to be internal, but not trusted. fix to follow.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-01-20 03:17 -------
You can't put your MSA in internal_networks, you'll end up doing DNSBL lookups
on your own users.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
sidney@sidney.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 1 vote |ready for commit
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 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.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3391 is|0 |1
obsolete| |
------- Additional Comments From spamassassin@dostech.ca 2006-02-28 23:51 -------
Created an attachment (id=3392)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3392&action=view)
fix 6
bah! I forgot to add t/trust_path.t
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3387 is|0 |1
obsolete| |
------- Additional Comments From jm@jmason.org 2006-02-23 23:15 -------
Created an attachment (id=3388)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3388&action=view)
fix 3
oops, forgot some changes to Conf.pm
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From quinlan@pathname.com 2006-02-28 08:42 -------
I don't understand. Why don't we just always add internal_networks to
trusted networks? If something appears twice, no big deal.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-02-24 02:44 -------
You'll need this from trunk (which I wouldn't mind seeing go into 3.1 either):
http://svn.apache.org/viewcvs/spamassassin/trunk/lib/Mail/SpamAssassin/NetSet.pm?rev=370724&r1=370723&r2=370724&view=diff
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|possible to be in |[review] possible to be in
|internal_networks without |internal_networks without
|being in trusted_networks |being in trusted_networks
Status Whiteboard| |needs 2 votes
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-02-03 16:52 -------
BTW, the docs for Mail::SpamAssassin::Conf read as follows:
internal_networks ip.add.re.ss[/mask] ... (default: none)
What networks or hosts are �internal� in your setup. Internal
means that relay hosts on these networks are considered to be MXes
for your domain(s), or internal relays. This uses the same format
as "trusted_networks", above.
This value is used when checking �dial-up� or dynamic IP address
blocklists, in order to detect direct-to-MX spamming. Trusted
relays that accept mail directly from dial-up connections should
not be listed in "internal_networks". List them only in
"trusted_networks".
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From sidney@sidney.com 2006-02-24 02:37 -------
Patch 3388 does not apply cleanly to the 3.1 branch.
[sidney@sidona b3.1]$ patch -p0 < ../bug4760.patch
patching file MANIFEST
Hunk #1 FAILED at 457.
1 out of 1 hunk FAILED -- saving rejects to file MANIFEST.rej
patching file lib/Mail/SpamAssassin/NetSet.pm
Hunk #1 succeeded at 77 (offset -3 lines).
Hunk #2 FAILED at 93.
Hunk #3 succeeded at 90 with fuzz 1 (offset -32 lines).
Hunk #4 succeeded at 143 (offset -3 lines).
1 out of 4 hunks FAILED -- saving rejects to file
lib/Mail/SpamAssassin/NetSet.pm.rej
patching file lib/Mail/SpamAssassin/Conf/Parser.pm
Hunk #1 succeeded at 750 (offset 11 lines).
patching file lib/Mail/SpamAssassin/Conf.pm
Hunk #1 succeeded at 962 (offset -35 lines).
patching file t/trust_path.t
patching file t/spf.t
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-02-28 12:28 -------
'I can go either way, really, but at this stage I'd be happier going for option
#2 since we're already 90% of the way there and we'd have to redo a patch for
option #1 again.'
er, oops! s/2/1/ and s/1/2/ in that paragraph, I got confused. ;)
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-02-11 04:04 -------
The line "set 'internal_networks' to include the hosts that act as MX for your
domains, or that may deliver mail internally in your organisation" from
http://wiki.apache.org/spamassassin/TrustPath is a little vauge, but still
correct. It should probably be clearer that it's referring to hosts between
your MX and the host running SpamAssassin. Obviously an MSA is NOT between an
MX and the host running SpamAssassin.
Also note the documentation from Mail::SpamAssassin::Conf I quoted above.
The semantics haven't changed. It wouldn't work if they changed.
The MSA can't be included in internal_networks, SpamAssassin has to know that
everyone relayed through their own MX. Since SA doesn't know who your local
users are, both local and external users have to relay through an MSA that SA
doesn't consider to be internal.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-01-12 03:39 -------
Created an attachment (id=3329)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3329&action=view)
Alternative Patch
I think that if we're going to assume an internal relay is in trusted_networks,
and not a configuration error, the assumption should be made in the
configuration code.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3388 is|0 |1
obsolete| |
------- Additional Comments From jm@jmason.org 2006-02-24 11:43 -------
Created an attachment (id=3389)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3389&action=view)
fix 4
yes, that's definitely a good idea. this patch includes it.
FWIW, I found another couple of issues when applied to b3_1_0; lint_warn() is
not available, so uses "warn" instead; and "t/trust_path.t" requires a fix that
was applied to 3.2.0 but not 3.1.x, namely JGM's patch allowing the Mail::SA
object to be recreated multiple times in the same process, so I've set it to be
skipped.
It's still there so it can be manually edited and run if required though -- it
does work but is noisy.
damn, 3.1.0 is *really* far away from 3.2.0 at this stage.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-02-20 23:10 -------
I have thought through this, and the stuff about the MSA makes sense now; I can
see the usefulness of it not being in the internal_networks list, but still
trusted, and I now see that it's safe, backwards-compatibilty-wise, too.
Thanks for your patience Daryl ;)
However, even given that, it *still* appears that if a host is in the internal
list, but not in the trusted list, that state is inconsistent and illogical.
The host either needs to be made trusted, or made non-internal.
In other words, these are the possible cases:
trusted internal should-be-trusted? should-be-internal?
y y y y
y n y n
n n n n
n y ? ?
"n y" is the one we're arguing about. Now, here's a response to the mail you
sent:
> 1) Mail from random zombie comes in. That zombie IP is checked in
> DNSBLs because it's the first non-internal host (MX is trusted and
> internal). We get a DUL hit, we're happy.
That is the "n n" case. Everything's good here.
> 2) Mail from our own dynamic IP customer comes in. It's submitted to
> our MSA. If our MSA is trusted and internal, the same as #1 happens.
> This time we're not happy, we got a DUL hit on mail relayed through our
> own MSA.
That is the "y y" case. Agreed, we want to avoid this.
> If the MSA is NOT internal, but still trusted, we don't bother with the
> DNSBL tests on the customer's dynamic IP since it's not the first
> non-internal IP. All is well.
That is the "y n" case. Still in agreement.
So, I am not seeing where the problem is with the proposed patches for bug
4760, and where it breaks this case, since bug 4760 deals with the "n y" case,
not any of those 3.
It does indeed propose fixing the "n y" by turning it into a "y y", but that
should not effect an MSA -- since the correct setup for SA when an MSA is
involved is to ensure it falls into the "y n" set *in the first place*, instead
of letting it be in the logically inconsistent "n y" set.
IOW, I'm not seeing anything that requires that we allow "n y" be a valid
state -- I think we can just insist that internal_networks are always a subset
of trusted_networks (which is simpler to comprehend imo).
Would it be more useful to just make this a configuration error, and
warn about it if it crops up, instead of silently fixing it? Do you
agree it's an error?
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-02-28 21:55 -------
Just adding the internal_networks to trusted_networks (like I did in attachment
3329) makes it really easy to screw up your config if you use any exclusions
(!net) in your config.
I was for Justin's #1 over #2 since it goes a long way in preventing people from
configuring something that they don't understand. Since correctly setting
trusted and internal networks is one of the major problems faced by our user's,
I think making it harder to configure in conflict of what the documentation says
to do is a good idea.
Due to some physical internal networks (like your MTAs) not being included in
SpamAssassin's logical internal_networks, I don't think changing the
documentation is a good idea.
Overall, a lot of the users@ traffic is about bad config settings that could
have been caught by the parser. We've fixed a lot of them. I think trusted and
internal networks should throw warnings at the user if there's even a hint that
the user isn't sure of what they are doing.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-02-28 23:45 -------
fix 4 overlooks dealing with excluded networks
[dos@latitude trunk]$ svn ci -m "bug 4760: don't check to see if excluded intern
al_networks are included in trusted_networks && don't match included internal_ne
tworks in excluded trusted_networks"
Sending lib/Mail/SpamAssassin/Conf/Parser.pm
Sending lib/Mail/SpamAssassin/NetSet.pm
Sending t/trust_path.t
Transmitting file data ...
Committed revision 381804.
[dos@latitude trunk]$
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3325 is|0 |1
obsolete| |
------- Additional Comments From jm@jmason.org 2006-02-23 18:58 -------
Created an attachment (id=3386)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3386&action=view)
fix
and here's the patch. It adds code to Conf::Parser to post-process the
internal_networks list, checking for this error condition. if it's found, it
issues a lint warning, and removes the offending network from
internal_networks. a little refactoring was required in NetSet to allow the new
"is net inside another net" query. Also included: 1 "t" script to test this
condition (and other trust-path cases).
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-02-23 23:20 -------
committed to trunk btw:
: jm 394...; svn commit -m "bug 4760: hosts in internal_networks should always
be in trusted_networks; one is a subset of the other. enforce this and make the
error condition an explicit error"
Sending MANIFEST
Sending lib/Mail/SpamAssassin/Conf/Parser.pm
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/NetSet.pm
Sending t/spf.t
Adding t/trust_path.t
Transmitting file data ......
Committed revision 380241.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-02-11 03:46 -------
Initially, it was possible to extend "trusted_networks" out onto the internet;
e.g. you could list the MTAs for groups.google.com or something if you knew they
were trustworthy, or even list the MTAs and MSAs for all your correspondents so
they'd get ALL_TRUSTED goodness. "internal_networks" would remain just your own
organization's internal, MXes, MTAs, and MSAs. See
http://wiki.apache.org/spamassassin/TrustedRelays , the 'How can I optimize the
trusted_networks setting?' part of http://wiki.apache.org/spamassassin/TrustPath .
Is the traditional meaning of "trust path outside the organisation" compatible
with "internal_networks don't include MSAs"?
I just want to make sure the existing semantics have been preserved.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From sidney@sidney.com 2006-02-24 04:00 -------
The only thing that diff adds to the functionality of the patch is one line that
calls is_net_declared. The rest of the diff defines the sub is_net_declared
which patch 3388 here ends up redefining.
Justin, since this is your patch, could you decide if you want to include the
call to is_net_declared in the 3.1 branch patch for this bug, and if so put
together a patch against 3.1 that adds in that line?
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From spamassassin@dostech.ca 2006-03-09 20:39 -------
Sending MANIFEST
Sending lib/Mail/SpamAssassin/Conf/Parser.pm
Sending lib/Mail/SpamAssassin/NetSet.pm
Sending t/spf.t
Adding t/trust_path.t
Transmitting file data .....
Committed revision 384612.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3386 is|0 |1
obsolete| |
------- Additional Comments From jm@jmason.org 2006-02-23 23:10 -------
Created an attachment (id=3387)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3387&action=view)
fix 2
actually, I missed something; that patch didn't take care of one of the edge
conditions, namely when trusted_networks is unset, internal_networks is
documented to be used instead. This version now does. It also fixes spf.t to
disable the two failing tests, since they are now obsoleted by this patch
(since that test case is now in error).
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[review] possible to be in |possible to be in
|internal_networks without |internal_networks without
|being in trusted_networks |being in trusted_networks
Status Whiteboard|needs 2 votes |
------- Additional Comments From jm@jmason.org 2006-02-23 14:06 -------
'Making "n y" a configuration error would force the user to read the
documentation and hopefully get it right.'
OK, we agree! excellent! I'll work on a patch later.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-01-24 20:52 -------
I'm still not entirely convinced on this, btw; I have a feeling that my idea of
what internal_networks/trusted_networks means, is slightly different from yours
(and it's entirely possible that I'm wrong ;). I need to spend time working
out what's what.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3392 is|0 |1
obsolete| |
------- Additional Comments From spamassassin@dostech.ca 2006-03-09 01:31 -------
Created an attachment (id=3402)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3402&action=view)
fix 7
cosmetic change to lint warning -- I'm going to assume Justin's +1 stands
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-01-12 21:52 -------
Hrm... apparently email replies aren't working yet.
My previous to last reply:
Aw crap. I forgot that add_cidr didn't do anything to check for dups first,
which it shouldn't. I mis-remembered how I did the POPAuth plugin.
In any case, I still think the assumption should be made in the config, even
given the penalty of having to do something like contains_ip does first.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-03-09 11:28 -------
listen to Daryl. he's been right on this issue every time ;)
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From spamassassin@dostech.ca 2006-02-21 02:18 -------
> However, even given that, it *still* appears that if a host is in the internal
> list, but not in the trusted list, that state is inconsistent and illogical.
> The host either needs to be made trusted, or made non-internal.
Yup.
> So, I am not seeing where the problem is with the proposed patches for bug
> 4760, and where it breaks this case, since bug 4760 deals with the "n y" case,
> not any of those 3.
It doesn't break anything. I just think that specifying internal_networks that
aren't also (manually config'd) in trusted_networks should be a configuration
error (see below).
> IOW, I'm not seeing anything that requires that we allow "n y" be a valid
> state -- I think we can just insist that internal_networks are always a subset
> of trusted_networks (which is simpler to comprehend imo).
Yes, definitely. Though I think the user should be forced to configure their
trusted_networks and internal_networks that way.
I think, based on past user problems posted to users@, that anyone who doesn't
already include their internal_networks in their trusted_networks doesn't
actually understand what they are doing.
I think that the current patch will mask this lack of understanding (likely
leading to MSAs along with other internal machines being declared as internal).
Making "n y" a configuration error would force the user to read the
documentation and hopefully get it right.
> Would it be more useful to just make this a configuration error, and warn
> about it if it crops up, instead of silently fixing it? Do you
> agree it's an error?
Yeah, "n y" is definitely an invalid state and a configuration that permits it
is in error. I think it should be a configuration error.
Silently fixing it would further complicate something that causes confusion with
a large portion of the users posting to users@ list (I think Matt and I could
save time by setting up auto-responders telling people how to configure this
correctly).
My proposed solution is as follows:
- At a minimum, a host is external if it isn't declared as trusted and internal.
- Additionally either documentation stating the above line, or actual testing of
this when the configuration is processed.
Testing the configuration (after all internal_networks and trusted_networks have
been parsed) is the optimal solution but requires a bit of work.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 2 votes |needs 1 vote
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3329 is|0 |1
obsolete| |
------- Additional Comments From spamassassin@dostech.ca 2006-01-12 21:51 -------
(From update of attachment 3329)
I don't think having auto-detection of trusted_networks run in conjunction with
a manual internal_networks settings (which will also act as a trusted_networks
setting) is a good idea either.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|dev@spamassassin.apache.org |jm@jmason.org
Status|NEW |ASSIGNED
------- Additional Comments From jm@jmason.org 2006-01-10 21:06 -------
Created an attachment (id=3324)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3324&action=view)
demo message
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-02-28 12:27 -------
Dan -- we had two choices:
1. mark that case as an error, or
2. fix it quietly and automatically.
Initially I was suggesting #2, but Daryl preferred #1, so I've gone with that.
you're now backing #1, as well. where were you earlier? ;)
I can go either way, really, but at this stage I'd be happier going for option
#2 since we're already 90% of the way there and we'd have to redo a patch for
option #1 again.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-01-12 20:14 -------
what happens if the user *does* already use e.g.
trusted_networks 1.2.3.4
internal_networks 1.2.3.4
?? duplicate entries in the trusted_networks array.
I think I prefer my patch ;)
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From felicity@apache.org 2006-03-08 20:57 -------
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?
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.
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)
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.
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.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |spamassassin@dostech.ca
------- Additional Comments From spamassassin@dostech.ca 2006-01-16 05:28 -------
I think my issue was the weird config. Everyone's been told that
trusted_networks should contain "all the trusted hosts" and internal_networks
should contain "all the trusted hosts except for your MSAs". To keep with that,
something like this would make more sense:
if ($in_internal && !$in_trusted) {
$in_internal = 0;
}
I'm concerned that allowing the example config (above) will lead to people
thinking that ALL of their internal hosts, including their MSAs, belong in
internal_networks and everyone else they trust belong in trusted_networks.
I no longer think, as I did before, that this should be done in config, but
instead that hosts matching internal_networks outside of the defined
trusted_networks should not be treated as internal (as the one line change to
the patch would do).
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dev@spamassassin.apache.org
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From sidney@sidney.com 2006-03-09 20:28 -------
+1
Check this in, Daryl, and let's get 3.1.1 on the road!
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-03-01 10:56 -------
+1
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From jm@jmason.org 2006-01-20 03:03 -------
'Everyone's been told that
trusted_networks should contain "all the trusted hosts" and internal_networks
should contain "all the trusted hosts except for your MSAs".'
um. I'm not sure I get you.
'ALL of their internal hosts, including their MSAs, belong in
internal_networks and everyone else they trust belong in trusted_networks.'
This is exactly what I was thinking was the case ;)
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
[Bug 4760] [review] possible to be in internal_networks without being in trusted_networks
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3389 is|0 |1
obsolete| |
------- Additional Comments From spamassassin@dostech.ca 2006-02-28 23:46 -------
Created an attachment (id=3391)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3391&action=view)
fix 5
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.