Lou Hevly <[EMAIL PROTECTED]> writes:
> I would like to see a new option for TMDA, a simple
> NO_CONFIRM_MESSAGE=1, which would mean that TMDA would not send
> confirmation messages to unknown senders, though it would put their
> messages in the pending queue. It would then be the responsibility of
> the user to check the pending queue (using tmda-pending) on a regular
> basis to release potentially legitimate messages. I have two reasons
> for this request:
Please don't take the following as any sort of policy decision about
what TMDA will or won't do in the future. It's more of an opening up
a discussion about what we're really trying to solve here. I don't
quite understand this request and I'm going to try to explain why
below. Maybe we can come up with an answer that solves this problem
and addresses the issue I have with the proposed solution.
> 1) I have a client who wants TMDA protection, but who receives mail
> from unknown users requesting information about his services. I
> proposed setting up tmda-pending so that he'd get hourly resumes of
> incoming email, which he thought was perfect: he can double-click and
> auto-whitelist those messages he's interested in and ignore the
> others; he can thus respond to legitimate messages within an hour or
> so. However, he doesn't want these potential clients to get the
> bounce message because it might confuse them ("Something is wrong with
> your email address: when I sent you a message it came back").
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. I think most people who use TMDA would
agree -- they use it because it significantly reduces the annoyance of
dealing with a mailbox full of garbage. 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.
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.
In other words, having to scan a report and release the valid messages
seems to me to completely defeat the one thing TMDA does -- reduce
time-wasting annoyance.
If you have to do that work, why not simply remove TMDA protection
from that address? 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.
A possible solution, if TMDA is not used on those type of addresses,
is to use something like SpamAssassin or the Distributed Checksum
Clearinghouse software, which tags mail as to the likelihood of it
being spam. Likely spam can be dumped in a separate mailbox that gets
checked when you have time, but good mail gets through immediately.
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.
> 2) Lately I've been getting spam from spammers who have responded to
> my confirm message; here's an example (note that the response came in
> 22 seconds, a sure sign that it was from a bot):
Well, I think this is rare right now, but if spammers, en masse, begin
providing valid return addresses, it's going to happen more and more.
I agree we need to address this but, for the same reasons I listed
above, I don't believe that the solution is to go back to wasting time
scanning through loads of unwanted email. Again, it seems to me that,
if you want to scan email, just uninstall TMDA!
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.
> qmail users may know that Charles Cazabon has written a program that
> automatically responds to qsecretary's confirm message. It's simply a
> matter of time before spammers will set up similar programs to
> automatically respond to tmda's request for confirmation. A
> NO_CONFIRM_MESSAGE option would be a foolproof way to stop this.
Unfortunately, it's also a foolproof way to completely obviate the
value of TMDA :(
Tim
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
