https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7087
--- Comment #10 from Kevin A. McGrail <[email protected]> --- (In reply to Rafal Ramocki from comment #9) > Thank You for reply. > > I've been using 3.3.2 for long time and got no complains about false > positives caused by URIBL (and almost no complains at all) and after > migration to 3.4 rate of false negatives increased. Unfortunately for me in > fact You are right that it is possible to have false-positive by this rule. > But on the other hand it is possible to have false positive on most(?) of > them and I wouldn't been debugging this case if it wasn't be a problem for > me. > > Reimplementing this as an option (disabled by default?) and with > documentation will be OK for me. Maybe should be another option to harvest > uris from other headers to (ex. from decoded Subject:). > > As I now see the bug #6700 bas probably reported by false positive from > domain mx.aol.com. According to uribl.com this domain was already white > listed so it shouldn't be added to black list no more. > > Hope my arguments will be reasonable from Your point of view. Any other > votes? Or maybe some changes? :) If it will be so I'll prepare a patch. But > for now it is unclear for me if it have chance to be included or not and I > have no idea what should be name for this option. > > best regards We are a meritocracy and so if you prepare a well written patch with documentation that adds a config option to pull the domain out of the DKIM header for URIBL (effectively adding an on/off switch and documentation for the bug 6700), I will personally look it over. Regards, KAM -- You are receiving this mail because: You are the assignee for the bug.
