https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6203
--- Comment #5 from Giampaolo Tomassoni <[email protected]> 2009-09-17 11:50:11 PDT --- (In reply to comment #4) > > the only issue is backwards compatibility -- a way to deal with existing > > /16-using dbs is necessary.... > That might be hard to achieve without doing another query when a tighter > one fails to find any record. Is it worth it? The AWL database in my view > is mostly throw-away in a sense that: it rebuilds fast enough on common > correspondents, and throwing away seldom-used entries does more good > than harm. That is true, but the SA user should be in charge of choosing when its AWL db may be thrown away. If you impose a new netmask, you basically decide for him/her... > (In reply to comment #3) > > I personally like the /16 and don't see a reason to restrict it to /24. > > Please > > note that a lot of spam is originating from wide dynamic address spaces of > > big > > ISPs: with a /24 address in AWL a spammer could get a "virgin" ip address > > simply by reconnecting... > > > > However, I do understand this is close to a matter of flavours. > > > > So why not add a configuration directive for this? By they way, keeping a > > default of /16 there should be no risk of breaking things. > No matter on which mask we decide, I don't think it should be configurable. > Network topology of senders and their ISPs is not a matter of recipient's > preference. Right, but why /16 or /24, then? Why not /8? Or even, since it can be done, why not /20?. There is no evident reason and most depends by enviromental factors like, in example, how much disk space devote to AWL. Or generally how /24 vs. /16 works fine to the user. The best solution would probably be to record the ISP's network address, which is blatantly unfeasible. Other solutions (like the one AWL actually implements) are, of course, a compromise and, as such, may be "compromised" the way one likes... Also I would stress the fact a configurable netmask for AWL with a conservative default would save a headache to most SA users. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
