Karsten M. Self wrote: <snip>
> >I would find C-R systems such as TMDA far less objectionable if they >mandated C-R only as a last recourse: > > - Mail that isn't viral in origin. > - Mail that isn't clearly spam. > - Mail that isn't otherwise accounted for (whitelist, passkey, or > other system). > >What I fail to understand, though, is why you'd need a C-R system to >handle the very small handful of messages what do come through such >filtering. I use a well-known, well-publicized email address I've had >for seven years. I use a whitelist (locally maintained), Spamassassin, >and some local filtering rules. The results are highly satisfactory.
Why should C-R systems "mandate" anything? C-R systems, or TMDA, anyway, have the capability of incorporating other spam fighting techniques quite powerfully. I'd much rather have multiple components, each doing what they do best, that can interact in whichever way I find best.
I installed tmda two days ago, after a friend recommended it to me (and promised to help me wade through the install). Almost as soon as I got it installed, I decided that I didn't want my tmda-pending queue to be quite so full, so I eventually created some rules to drop anything with suspicious attachments. One day ago, I decided that I didn't want to have to deal with spam in tmda-pending either, so I installed spam assassin, had it run before tmda in procmail, and have tmda deliver anything with sa-generated spam headers to a spam box, where I can admire the pretty headers that sa generates and generally not have to deal with it.
So I have tmda using spamassassin, and spamassassin using razor. tmda also uses whitelists, and I've already whitelisted every address in my alias file and in my mailboxes. tmda allows you to simply drop emails that you really don't want to deal with, and I use that too. The number of addresses that actually get challenged should be fairly small.
Actually, tmda syntax is so much cleaner than, say, procmail, that I can imagine that for certain uses (certainly everything I've done so far), even if one didn't want c/r functionality, one could install tmda, set up various filters, and then have a final filter to send everything else to the inbox.
I *do* choose to use C/R as a last resort, and I believe that user choice is the right way to run these things.
Now, sure, email providers that allow users to use C/R and other spamfighting techniques should encourage their users to whitelist their friends first, and they should give the users powerful tools to do so through their web interfaces. So far, the "powerful tools" part is what has been lacking, but I think that will catch up. My mailsnare account allows me to filter spam and use challenge/response ... the problem is that it was kind of a pain to set up and certain options just weren't acceptable -- you can "drop" stuff tagged as spam and unconfirmed sources, but you cannot put them in a spam folder for later perusal -- at least, I couldn't figure out a way to do so. That's one of the reasons I decided to run this stuff on my own -- lack of flexibility through a provider.
I agree with you that people who use c/r should use it as a last resort, after spam-flagging, whitelists, and other rules -- but tmda supports that, and it does so quite well.
I completely disagree that tmda and other c/r systems should *mandate* such behavior. Educate the user, provide the user with tools and options, and then let the user decide.
-- monique
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
