http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4760
------- Additional Comments From [EMAIL PROTECTED] 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.
