https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6508
--- Comment #5 from Daryl C. W. O'Shea <[email protected]> 2010-11-04 20:25:33 UTC --- (In reply to comment #3) > > In my experience this has been an important feature. > > I know of a number of people that have setups like this: > > trusted_networks 10.20.30.0/24 > > internal_networks 10.20.30.0/24 !10.20.30.2/31 > > Where the /24 covers their MXes and the /31 covers their MSAs. > The above produces a lint warning: > $ spamassassin --lint > warn: netset: cannot exclude 10.20.30.2/31 as it has already been included Crap, I forgot that smaller "conflicting" networks had to be declared first. I now remember arguing about why I wanted to do that too (so you didn't try to exclude something you already included or vice-versa). So, I think this may make it a non-issue, no? I think the smaller network will always be the accurate "answer". > Similarly, of the six failing test cases in trust_path.t all but one > produce a lint warning (if I counted correctly). The remaining one > is perhaps questionable or maybe a lint test can be added. It's quite possible that the tests are wrong. > We have been telling people they cannot expect flawless operation > in presence of lint errors or warnings. Following a principle of > 'garbage-in, garbage-out', maintaining backwards compatibility with > invalid setups is not always necessary or possible, especially > when warnings _are_ being issued. I just forgot about the ordering rule... if you get the warn from lint it won't actually add that part of the config (like it says). And with the smaller networks always listed first I think with Net::Patricia it'll DTRT. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
