Greetings:

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:

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").

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):

Date: Fri Aug 9 22:12:16 GMT 2002
From: "They Saw" <[EMAIL PROTECTED]>
   To: [EMAIL PROTECTED]
Subj: investigate anyone online made easy
Actn: CONFIRM action_incoming

Date: Fri Aug 9 22:12:16 GMT 2002
From: "They Saw" <[EMAIL PROTECTED]>
   To: [EMAIL PROTECTED]
Subj: investigate anyone online made easy
Actn: CONFIRM pending 1028931136.20025.msg

Date: Fri Aug 9 22:12:38 GMT 2002
From: "They Saw" <[EMAIL PROTECTED]>
   To: [EMAIL PROTECTED]
Subj: investigate anyone online made easy
Actn: OK good_confirm_done_cookie

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.

My apologies if I've overlooked something obvious, but it seems to me 
this option might be a Good Thing.
-- 
All the best (Ad�u-siau),
Lou Hevly
[EMAIL PROTECTED]
http://www.visca.com

_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to