Monique Herman <[EMAIL PROTECTED]> writes: > 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.
Exactly. The so called "Unix Philosophy" encourages this. > 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. Indeed, most people don't realize that TMDA can be used for many other things besides the challenge/response aspect. For example, the local delivery agent properties can be used as a procmail substitute. tmda-sendmail/ofmipd makes a nice interface between the MUA and MTA for those who desire more control over the headers and envelope of their outgoing messages. > 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. Currently TMDA does use C/R by default, and you have to configure it to deliver by default instead. This is a throwback to the early days when TMDA did little more than C/R. I'd not be oppose to reversing this though. The idea would be that a new TMDA install would deliver all uncaught mail, and you'd have to set ACTION_INCOMING = 'confirm' in /etc/tmdarc or ~/.tmda/config to make C/R the last resort action. Regardless of this thread, I think this would make a new installation less painful as well. Any opinions on this idea? _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
