On 10 Aug 2002 14:17:16 -0500 Tim Legant <[EMAIL PROTECTED]> wrote:
> Lou Hevly <[EMAIL PROTECTED]> writes: > I am fully capable of deleting spam from my inbox. So why do I use > TMDA when I could just delete the junk? Because deleting spam by hand > is a time-wasting annoyance. That are other reasons to not use TMDA's confirm behaviour: a) Testing TMDA filters and configs b) Dry running for an extended period to manually collect valid addresses before enabling confirm. c) Installing a layering system on your inbound mail path (eg in a corporate setting having a hired hand handle the TMDA-pending queue while you handle what actually arrives). d) Employing background heuristics on the TMDA pending queue outside of TMDA without having to involve senders. e) etc. > The important point here is that TMDA doesn't stop spam. Just check > your logs. What TMDA does is stop you having to deal with spam. TMDA has uses outside of controlling SPAM. For example I'm fronting my lists with TMDA (in a somewhat similar manner to what is done at tmda.net) such that posting authority is abstracted from subscription. Very nice. Not a SPAM question. > I don't see much difference between scanning a report for valid > messages and scanning a mailbox for valid messages. The amount of > time-waste and annoyance don't appear significantly different to me. Unless I have someone else, or another automated system do it for me and I use TMDA to auto-pass known-good email to lessen that person's or system's load? > I've felt for a while that info and support type addresses should > probably not be protected by TMDA, precisely because customers should > be able to get through. I initially became interested in TMDA to control mail to my lists' -owner and -admin addresses which have a worse than 100:1 SPAM/virus/valid_mail ratio. Its been noticeably effective there. I monitor the pending queues for those addresses and: a) good mail is getting thru, and b) nobody who has had to do a confirm has had anything but glowing statements for the system (mostly because they have an over-developed sense of their responsibility to reduce my bandwidth, but that's another matter). > Likely spam can be dumped in a separate mailbox that gets checked when > you have time, but good mail gets through immediately. I did that, both of them and others all in sequence. For me it wasn't good enough. > In other words, I don't think there's one solution that fits every > situation and company-access addresses perhaps call for a different > solution than TMDA provides. Exactly, except that with minor edits TMDA can offer support in many of those other fields. > JC's Hold patch seems a reasonable stop-gap measure until we solve > this, but I'd rather find a technical solution to this that preserves > the time-saving properties of TMDA. <bow> I'm a little chary of your evaluation as "stop gap". I've found it quite useful in some of the above ways. I'm aware of one large commercial site which is looking to install TMDA on their postmaster@ address for instance. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
