Having been involved in spam fighting for years, I can tell you that as soon as you release this system, the larger spam outfits will build their own autoresponder for it. All you will accomplish is to tell the spammer that a warm body exists behind that email address. Spam traffic to your networks will increase tenfold.
If you take Danny's senario of the email that you just don't want to miss, then you need to allow the user to "choose" to do this authentication type interaction. Since the user has then already decided that the email is spam, it is really fairly redundant. I can however see how an "allowed-senders to account" function might be very useful. For instance, say a mail admin has created a mail account that is designed to facilitate a orm of logging. Perhaps remote sites are tailing syslogs into mail and forwarding them to an admin. That account is really only intended to recieve mail from senders that can be specicifed. In situations like that, a facility to specify domains etc that are allowed to mail that account, and a choice of what to do with mail that is not allowed. This would be especially good with accounts that recieve mail by form (on website) only too. Cheers, Craig -----Original Message----- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 7:07 AM To: James Developers List Subject: RE: Suggestions/Recommendations "Anti-Spam" Frank, I'd suggest that you write a matcher and a mailet the matcher should check each mail for two conditions, first that the sender is in your known senders list, you could use (or rip off code from) the list server user repositories for this. second, if that check fails you check for acceptable return ID, you might munge the subject line, or use an X header, but beware that you have to ensure that the ID will be sent back to you. If both tests fail a match is made which means you don't want to accept the mail so it goes to your mailet. The mailet processes all mail it receives, adds your ID and sends it back to the sender, you'll need to decide whether or not this situation should use the reply-to header or the from header. The three concerns I have are; 1/ rather than reducing the load on your server this scheme turns one incoming spam into another outgoing message, increasing network traffic and server load. 2/ The vagiaries of mail client software,and the range of ways in which people use it are such that communicating the ID number invisibly is probably not practical. 3/ Suppose you tendered for a Big Contract, and the Big Boss of the Corporation wanted to drop you a line, perhaps to ask for additional information. He is not going to be impressed with your outfit if his mail is bounced. (IMHO) The thing I like is the way in which your server can learn who to accept mail from, with the burden being on the sender. (see earlier posts to this list regarding spam and SMTP) Focus on the learning idea and see where it takes you. d. > -----Original Message----- > From: Frank Herrmann [mailto:[EMAIL PROTECTED]] > Sent: 23 April 2002 14:31 > To: [EMAIL PROTECTED] > Subject: Suggestions/Recommendations "Anti-Spam" > > > Hello, > > I am working on a project to develop a platform-independent anti-spam > solution. I would like to implement an additional feature for > James and use > it as a mail proxy on localhost. > > The basic idea is: > > All messages from senders that are unknown will be automatically > returned to > the senders address with a unique ID and the message: "please send this > message again to the same address". > If this message arrives us, the senders address is permanently allowed. > (i.e. added to "allowed senders") > > This will block all of those non replyable mail spammers. Those, > who have the > ability to respond (and even do so with the unique ID) can be > blocked easily > by changing the format of the message. > > What is the best way to contribute this idea into James ? Where to start ? > > Frank Herrmann > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
