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