J C Lawrence <[EMAIL PROTECTED]> writes: > On 10 Aug 2002 14:17:16 -0500 > Tim Legant <[EMAIL PROTECTED]> wrote: > > That are other reasons to not use TMDA's confirm behaviour: > > a) Testing TMDA filters and configs
-M > b) Dry running for an extended period to manually collect valid > addresses before enabling confirm. 1) Run collectaddys on all your existing mail before enabling TMDA. 2) Set ACTION_INCOMING = "accept" while you collect addresses. > 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). Poor fellow <wink>, but I can see some value here. This is the same idea as using SpamAssassin or similar. > d) Employing background heuristics on the TMDA pending queue outside > of TMDA without having to involve senders. Afraid I don't understand this one. Involving senders is how TMDA stops spam. Running heuristics can proceed whether you're requiring confirmations or not. These seem unrelated to me. > > 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. Huh? Isn't the main reason you care about authority to post because you want to keep unsolicited nonsense off the list? Kinda like the Internet before 1994... <sigh> Seems like it's exactly a SPAM question, in the sense of unsolicited mail, though not necessarily dorky commercial marketing mail. > > 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? Yes, as above (poor fellow). But I see other options here, which is what I was trying to get to with my original message. What about the possibility of adding the capability to /deliver/ mail that doesn't match the whitelist. Say to the inbox of said poor fellow. This idea would take summary reports and tmda-pending and releasing out of the picture. The person could simply delete the garbage and forward the real stuff as appropriate. The idea is off the top of my head, but wouldn't it simplify what you're trying to accomplish in this case? TMDA can't do this right now, of course, but I've been thinking about multiple rule matches for a while. It seems worth pondering, anyhow. > > 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). As Jason noted in a later response and your experience affirms, the hubbub among new adopters of TMDA about the possible confusion created by confirmation request messages is largely unnecessary worry. As far as scanning the output of tmda-pending goes, I do that once a day. I've had two or three mails I've had to rescue in 8+ months. One was from an AOL account that didn't seem to be able to reply to extension addresses, so the confirm response (which the person, who spent the first 15 years of his life in Vietnam, had no trouble understanding and replying to) got stuck in pending/. So I continue to scan once a day, but anything more would be onerous. > > 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. No. TMDA isn't good enough, either. Like security, I regard spam prevention as a multi-layered approach. The SpamAssassin suggestion I made certainly wouldn't be perfect, but might be good enough, especially in a company situation such as you outlined above, where someone gets the junk and wades through it. The advantage is for situations where you don't know your customers and therefore they are not on a whitelist. For situations where you do know your customers, say a service organization, you can easily whitelist your customers's entire domains and TMDA might be the better choice. > > 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". This might be a bit of miscommunication. I meant that only in reference to Lou's second point, about autoresponders. In that case, if the TMDA solution is to stop using confirm requests and begin using something like the Hold action and tmda-pending reports, I will cease using and developing TMDA. It will have lost all value for me. > 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. If they have a person to devote to hourly reports, then this would probably work. postmaster is not protected by TMDA on my domains because I feel it's important to get postmaster mail through immediately rather than discovering it in the tmda-pending report at the end of the day. Yes, I get almost entirely spam at the postmaster address, but it's easy enough to delete on that one account. Actually, hostmaster is also unprotected but I have yet to receive a single spam to that address. If everyone had a unique domain and used the address of hostmaster, spam would disappear overnight! <grin> Anyhow, I'm anxious to solve these issues, but I feel the solutions must work, not only for companies who can afford to put a person to scanning reports, but for users like me and many others who look to TMDA to help them save time. Thanks for your thoughtful response. Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
