https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6048
--- Comment #6 from AXB <[email protected]> 2009-01-22 02:21:00 PST --- (In reply to comment #4) > I strongly disagree with AXB assessment. > > 1. No longer possible to rely on WHOIS info. to contact host operators given > privacy issues. Some legit sites may choose to use anonyminisers or use a 3rd > party contact like lawyers, the host's ISP or data centre provider. Therefore > the chain by which uribl.com notifications might be made is too easily broken > such that the host operator may not get sufficient warning or none at all due > to a break in communication. > > 2. An inexperienced SA user could initially start out as low volume, but > increase over time to high volume. They may still remain ignorant or > inexperienced WRT SA and as already noted, they might not receive the notice > of > being blocked, maybe because the notice itself was filtered or rejected. > > 3. Using some other NS assumes that the system builder is the same as the > system operator and is aware that the host being blocked. Often data centres > and other 3rd parties with build machines made to order, without knowledge of > the previous history of the host and its operators. > > 4. If the system is high volume, then detecting and determining what is wrong > may not be within the system operator's abilities (eg. inexperienced > operator). > The system may have been built by 3rd party and tested with different domains, > IPs, and DNS servers only to be changed on delivery to their customer. > > Therefore one cannot assume that system operator will have received the > uribl.com warning, know what to do to correct the problem if they receive such > a notice. > > If uribl.com can identify a host as high volume so as to change the results > based on that host's IP address, then they could as easily just blacklist or > drop the request and NOT return a result that would do the mail server harm. Uribl.com has uses these options and uses regularly. When the abuser never stops or hits skyhigh levels, then the positive reply is applied. Its not the generic/default case. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
