Closed Bug 215875 Opened 19 years ago Closed 19 years ago
When email is filtered as junk send an automatic reply asking the sender for a confirmation email
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Once an email is filtered as junk (which means that e.g. the bayes-filter statistically assumes it as junk) the sender should get an automatic email asking him for confirmation of his original email. There are server-side programs that do this e.g. : http://tmda.net/ (Of course some of the things TMDA can do can't be implemented on the client side. However the most important thing about it: making an automatic reply and waiting for confirmation should work.) This would help to cut down the number of false positives (in a second turn). IMO not the number of false negatives but the number of false positives is the problem of most spam filters. Mozilla's actually is very good -- but not perfect (maybe it's impossible to archieve this). So here's sketch of the "algorithm": 1. Do normal spam filtering 2. see if there are any new emails marked as junk 3. send an automatic reply to the sender/reply-to " Your Email XY seems to be junk. Please reply to this message to confirm that your email is not spam ..." ... 4. a) If a confirmation is received bring back the old message (put it where it had been if it wasn't detected as junk in the first place e.g. INBOX). Train the old email as "not junk". b) If no confirmation arrives in a certain amount of time this message is to be treated as 100% spam. I've heard a lot things against such an auto-reply. Here's what I think about it: O: Letting other people deal with your spam-problems is no solution I: Most people won't ever get an automatic-reply. If they do they are 99% spammers (assuming only 1% false positives) and spending my time for spammers is really no solution. And if it really happens to "a good guy" it won't hurt him to much pressing the "reply-button" (maybe realizing that writing emails in such a style is not clever) O: The statistic approach is better/good enough, there's no need in this. I: As long as it's not 0% false positives it's not good enough. I don't want to loose (non-spam )emails! This is not meant to be a replacement of the promising statistics approches but an add-on. O: You won't loose emails just check your spam-folder regularly. I: Checking the spam-folder doesn't help. It's a waste of time. When I have to check every email manualy then I don't need a spam-filter at all. It is not much faster checking the spam-folder separately and in most cases I won't detect the one message that was not spam out the the 99 that were. Simply because prejustice against these messages ("well it's spam ...") and because this one message looks very much like spam (otherwise the filter won't have thought so). Reproducible: Always Steps to Reproduce:
Here's more reasons not to: With a 50% junkmail rate, this would increase local email traffic by 50%. If a spammer uses a real (innocent victim's) email addresses as the spoofed from: or reply-to: address, this address would suddenly be auto-emailed by every client that receives that junk message. If a spammer uses a nonexistent address, you'll get a delivery failure notification message. If a spammer uses a valid business email, it can set up an autoreply confirmation to the client autoreply challenge, thus putting the spam right back in your inbox. If the spammer uses a harvester mailbox, it can pull your from: address and place it in a list of known valid active addresses for sale to other spammers, who will then send more junk mail than you received before. The only sure effect of implementing this is to drastically increase message traffic, while probably also increasing junk mail for you or someone else. Suggest WONTFIX.
I have used TMDA for some time. So I have some facts what happens when you use such an auto-reply (at least for my account and some others on the server -- of course you can't do statistics with only a low number of samples): 1. Spam income (before filtering) decreases! 2. Spam income increases when not using TMDA later (I now tried some statistic appraches) 3. Nearly all spam-addresses were not working (Sendmail couldn't deliver) If a victims address is used there are already enough people angrily answering to such a spam to make the email account useless/high trafficed. I contacted such a victim and he told me that there were a lot of handwritten "spam-answer" -- not easy to reply/filter. An auto-reply-confirmation message would be much easier to deal with. Where's the problem in getting a delivery error? When this happens it's surely spam. I never had a spammer sending a confirmation. Having an email-address that they use to get information about the spammed users (a valid reply) will damage their cloaking. So they won't do this (anymore). Email-Provider where you get a free, anonymus mailbox are rare nowadays, provider with anonymous mailboxes big enough for such spam-analysing I think never existed. (Note that the maximum traffic per mailbox seems to be limited, too. Checking emails often isn't a good idea, because the spammer will then be tracked) Receiving more junk just did not happend for me. The increased (outgoing) email-traffic is no problem except you have a very slow internet-connection or quotas on the maximum number of emails delivered by your smtp-server. In this case you won't have to use this feature. (it should be an option like al the other spam sontrols) However the traffic won't increase so much: The auto-reply should be a plain-text message and the traffic for sending a bunch of plain-text-emails is really low (visiting an ordinary website probably will cause more traffic). And I'd love to deal much less with spam in exchange to some kb of traffic. Have you other solutions to ensure that you don't loose emails?
*** This bug has been marked as a duplicate of 156744 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.