We're getting further off-topic for the Declude list I think. Apologies again.
| The personal messages are the most difficult and becoming | worse. They are random and infrequent. They are often among | the most important messages. Individuals have an | unbelievable number of private e-mail accounts that they | seemingly use with little organized thought. And some of the | messages are SPAM except for the fact that the user intends | to send them and the recipient wants them. A very, very | difficult problem. Thanks for all that... I think you're right on all counts. This last one is a real bugger - however we have some dynamic systems coming that should help this somewhat. I believe Scott is thinking of putting some similar things in place for Declude, or at least that they are on the wish-list. Two methodologies - (1) Legitimate messages contain some "pass code" that can be white-coded by Message Sniffer, thus allowing them past no matter where they are sent from. This could be some standard part of the other parties signature (their name, or phone number for example), or something special that you gave them. (If you're a Ham Radio fan, this is like a PL tone for email.) (2) The system may presume that if you have sent a message to a particular address that this address is allowed to send messages to you - with some intervening metrics to avoid abuse - such as recording also the source and destination networks. This one is probably ok unless the message comes from a completely random source. In any case, businesses using spam filtering should have a method for handling "unwanted lockouts" such as maintaining an unfiltered contact address that has very limited filtering so that customers/contacts always have an address they can go to... or a contact form that allows the contact to send their first query to the company and registers the sender's email address with the filtering system so that they can be sure to always get through. If these are links on the company web site, they can be randomized aliases that are generated daily and then thrown away. The alias would point to an underlying account that is never publicly posted. Anyone clicking on the "Contact Us" link will get through with the "address of the day"... any spammer harvesting that address has polluted their database with a bad address that, after a while, can be used to detect spammers (no legitimate contact would use the address after some reasonable period of time). Another mechanism like this would be an address on the system where internal users can BCC or forward a message to/from a new contact such that the system collects their addresses and gates their email from then on - allowing them into the "circle of trust". Mechanisms like this can be easily implemented with only minor procedural changes and can have a profound impact on spam reduction by allowing for very strict (or even closed) filtering. For example, in a sales organization it is likely that notification of a new customer or lead would be forwarded to some sales manager. If that manager's address were an alias the copied the message to the "gating address" on the system then white listing the new lead would be transparent and automatic in nearly all cases. We plan to offer features with our online database to automate some of these mechanisms. Many could be implemented now with Declude and a little bit of programming work to manage white & black lists... within limits, of course. _M PS: Note that the model for (1) is also applicable to a customized NO-SPAM system which uses computer generated headers (convolution codes) to authenticate senders and receivers. Sniffer would then gate messages with legitimate pass-codes while diverting all other traffic. Clients and MTAs that have been allowed into the "circle of trust" for a particular organization would produce recognizable one-time codes in their message headers so that other participating systems in the circle would not filter them out. Systems outside this circle would take their chances with the filters or simply not be allowed to send their messages. Convolution codes are used once and thrown away so that nobody can catch one and use it to gate their spam or other malware into the system. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.