Re:Any filtering is too much (Score:5, Interesting) 
by Frater 219 (1455) on Monday August 25, @09:29PM (#6790174) 
(Last Journal: Wednesday May 07, @11:51AM)  
I'd rather spam filtering be left to myself. Any decent e-mail 
client has the capability for filtering, and by doing that way, 
I have control over what gets thrown out and what doesn't. 

There are substantial disadvantages to a client-side filtering 
only spam defense as opposed to a server-side blocking only defense. 

It is, of course, fully possible to use both; I merely wish to 
point out some factors you may not have considered. 

For the definitions of "filtering" and "blocking", please see 
this Wikipedia article [wikipedia.org]. Roughly, DNSBLs and 
Sendmail's milter feature are blocking tools -- they take effect 
during the SMTP transaction. Client-side tools are filtering tools
 -- they take effect when you check your mail. 

Consider: 

Client-side filtering destroys false positives rather than 
bouncing them. Any spam defense can have false positives, 
in which non-spam email is incorrectly classed as spam. 
When a mail server doing blocking experiences a false positive, 
it returns an SMTP error to the sending system. Ultimately, 
the human sender sees a bounce message, which indicates that 
their message did not make it to the intended recipient. 
The sender can then attempt to get around the block 
(by sending from another site) or can try to contact the 
recipient by other means. However, when a client-side filter 
has a false positive, the mail is either deleted or filed in 
a rarely-seen "spam folder". The sender gets no notification 
that it will not be seen (or not seen promptly). Since false 
positives do happen, it is better that they not happen silently! 

Client-side filtering isolates and hides useful information. 
A mail site, particularly a large one such as AOL, is in a 
position to gather a great deal of information about spam 
sources and patterns. Users complain about receiving spam. 
If a site can cause these complaints to be expressed in a 
useful way (such as sending full headers to an abuse address) 
rather than a useless one (such as cussing out the helpdesk), 
the site can aggregate a huge amount of information about 
spam offenders, which can be used to the whole site's spam 
defenses (or to mount litigation or prosecution of spam 
offenders). In contrast, your client-side filtering is 
informed chiefly by your own experience, and has no access 
to the experience of the other bazillion people on your 
ISP or mail site. 

Client-side filtering doesn't alleviate large mail sites' 
resource problems. A site such as AOL dedicates significant 
amounts of disk space, backup capacity, and network 
bandwidth to email. Since over half of AOL's incoming 
email is spam, if AOL did no blocking then it would 
probably spend over twice as much money on these resources 
than it would on a spamless Internet. In client-side 
filtering, mail must be delivered to the user's mailbox 
on disk, and the user must then check his mail, before 
any spam is removed from disk. If that spam were blocked 
at SMTP time, however, it would never have occupied AOL's 
disk and never consumed those resources. 

However, as I mentioned above, it is possible to combine 
blocking and filtering in useful ways. A mixed strategy 
is what I prefer for my own site: we use a number of blocking 
strategies (such as DNSBLs and regular-expression patterns 
matching common spam elements), but we also use SpamAssassin 
and encourage users to filter with its scores or other criteria. 
 
[ Reply to This | Parent ]