https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6105
--- Comment #2 from Matt Kettler <mkettler...@verizon.net> 2009-04-29 19:43:22 PST --- Ok, after some off-list discussions (done offlist mostly because I was too tired to decide if posting abusable information was a bad idea or not.. but I've had time to think about it.. ) The existing algorithm tries to find the public IP closest to the originating mail client, looking for the "source IP". I propose this algorithm is fundamentally flawed when compared to the trust boundary, and the arguments I've seen supporting it so far are readily show to have complimentary problems that are worse, and are readily worked around. I propose a few basic points of comparison between using the current algorithm, and one based on the trust-border. (numbered for referencing) 1) Using the current algorithm "fixes" ISPs with multiple smarthosts in different /16's, but it also breaks road warriors who get their internet connectivity from hotels, internet cafe's, etc. 2) An ISP, even google, only has a finite number of different /16's they control. Thus, there is a finite number if different IP sets a gmail user will be categorized as, and eventually they will repeat. This may expand over time, but the expansion is slow. Repeating yourself is quite likely. 3) Road warriors expand their IP space rapidly, and the odds of repeating a /16 are pretty close to 1 in 2^16. ie: a close to random distribution across all the /16s possible, minus a few that aren't used, reserved, etc. Repeating is very unlikely. 4) admittedly there are more gmail users than road warriors, however, the gmail problem can be readily fixed. (see below) 5) using the "source" is using data that is easily forged, as it appears in untrusted headers. Arguing that the implications of forgery are small does not change the fact that it's foolhardy to rely on readily spoofed information. We may as well use from address only. Besides, there is a reason whitelist_from_rcvd uses the trust boundary. Shouldn't the AWL follow suit? 6) situations like gmail are readily resolved by changing the AWL to not be strictly IP based. If we change to the trust border, we can start using the domain part of the reverse-dns where one exists (and fall back to IP where no RDNS exists). This feature should reuse the registrar boundaries, 2tld, etc from the URIBL code. (ie: attempt to work like whitelist_from_rcvd where possible) 7) Situations like gmail can also be improved when SPF or DKIM is enabled. If results are available the "source" part can be collapsed to a simple "spf_pass", "spf_fail" etc. Now, admittedly, this is more-or-less a heavy revamp of the AWL, possibly suited to being a separate plugin designed to replace the AWL with a new "AWL+". (would also be a good opportunity to introduce working expiry) I'm willing to start learning perl to code this, but does anyone see holes in any of my postulates above? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
