On Jun 07, Don Armstrong <don@donarmstrong.com> wrote: > Is there any particular reason why people who want this level of > draconian spam protection on their own configure their MTAs and/or > MUAs to incorporate this level of spam termination? Yes. The problem with client-side filtering is that people cannot bounce anymore the messages which trigger their filters, because their replies would almost always annoy the innocent third parties whose addresses have been forged by the spammers. In this situation, the only options are receiving the spam and then either discard or review all filtered messages. I suppose you can understand why silently discarding mail is not an option for most people. Even if I am priviliged enough to live in a part of the world where unmetered DSL access is available, checking all the spam I get for false positives requires a much more scarce resource, my time. Another reason to use a DNSBL server-side is that it would greatly reduce the load on our mail servers, which have been overloaded for a long time. Instead we will waste money on new hardware because our mail administrators appear to be prejudicially opposed to DNSBLs. Being able to disable my @debian.org address would help, as I have never used it and cannot see any reason to use it in the future. Sadly the secretary stated that his voting software sends mail to it and has no plan to fix this, so I'm forced to keep it active. BTW, the DNSBL being considered (XBL) is all but draconian as it only lists addresses which are a source of spam sent by trojans and do not have a mail server running on them, and removals can be requested with a web form, are immediate and not subject to any requirement. (The occasional false positives are the result of people sending mail from dynamically assigned addresses, and I'd say that in today's internet XBL is the least of their problems.) I hope this answered your question. -- ciao, | Marco | [6669 sc9lS67M4hihQ]
Attachment:
signature.asc
Description: Digital signature