With this new addition, the Choicelist system handling bulk or commercial email is unchanged.
You can see the original paper describing the bulk email side of Choicelist at: www.choicelist.com/Choicelist.PDF
This System is expandable to ANY messaging protocol such as Instant messaging, SMS, telephone systems, any system in which one person contacts another person, or contacts many people. Even a many to many situation could be handled by Choicelist.
Here is a brief description of the bulk side of Choicelist.
Bulk E-mailers can create unique identities.
These Identities can be Whitelisted by users, otherwise they are automatically Blacklisted.
Identities are completely separate from any fixed email address, and basically serve as a framework for trust. If I trust company A, company A can send me as much mail as they want. They can also allow company B to send me mail and I will accept it because I trust company A. If company A breaches my trust, I can revoke the trust I extended, and this erases the trust for company B as well.
Allowing users to revoke trust is the only regulation required.
The Identity is not the proof.
The proof is left up to the Identity controller, and can be different for different addresses under the Identity. Many forms of encryption, and keying will be supported for authentication and security purposes.
Choicelist now splits e-mailers into 2 groups:
1. Commercial mailers/bulk mailers
2. Personal mailers
Brief description of Choicelist personal:
Personal Ids can be created at a reduced rate, and these Ids can reach everyone. They are also unstable, and if complaints are received, they will be terminated immediately. The extremely high barrier to mass entry, and narrow ledge to termination makes Choicelist personal authentication unsuitable for anything but person to person mail.
Now: Choicelist Personal in detail.
Personal mail must reach every user, therefore it will be a prime target for abuse by spammers.
This abuse is prevented by creating a system of Identity distribution that is difficult for spammers to take advantage of. Physical mail will be used to distribute a password to be used for use in creating a Personal Id. These personal Ids need not be tied to a physical address in order to be valid.
These personal identities may be traded at will, and need not be traceable to a particular person. All that is required is an effective rate limit (one identity per address, per 3 month time frame should be sufficient), and a strict policy of termination for violation (sending UCE, or UBE, or anything resembling spam from the users standpoint)..
As an added route to distribution, and to speed adoption, ISPs can request Ids for their existing customers, and businesses may make a request for a number of personal Ids for their employee accounts. These unverified Ids must be permanently linked to a static address, and are non-transferable. If these Ids are found to be spamming, and no action is taken, no further Ids will be provided to that source.
Each Id is the same as another from the standpoint of Choicelist verification. When Choicelist gives information that links to an identity 1 extra piece of information about that identity is given: Personal or Commercial.
While this alone would limit the amount of Spam purporting to come from Personal accounts, it is not enough. A system must be in place to make, and handle complaints about improper use.
The Choicelist Personal Identity complaint system:
Personal Identities are subject to complaints for improper use via a “Report Spam” button like the one AOL has. This button will forward the proof of violation to Choicelist. Commercial identities are not subject to complaints, rather the company’s entry in the users Choicelist can be deleted if mail from that source is no longer wanted.
The complaint system would make use of a realtime list of spamming personal Ids(updated on the order of 1 second) to limit the effect of “burst sends”(using personal Ids to send lots of mail before the Identity can be terminated).
All complaints are handled automatically, though a person analyzing complaints can override termination . The proof is checked, and if found to be valid, the complaint is registered. One complaint puts an address on the realtime list as a suspect. Emails from this Id will be flagged as suspect in a users inbox. After 10 verified complaints from different sources the account is a verified spammer, and the Id will be terminated and cannot be used again. Choicelist MUA’s can be set by the user to delete all messages using spamming Ids even if they have already been passed by Choicelist.
Appeals can be made to reinstate spamming Ids, but will not be granted until the problem of continued violation is addressed. Misinterpretation, Hijacked Identities or Zombie virus attacks are the only valid excuses for violation, as verification and content are up to the Identity controller.
This system allows even the worst case situation (in which a virus infects a users computer and begins sending out commercial email using their authentication information) to be limited in scope as well as inconvenience to any party.
Security:
Personal email addresses in the Choicelist database will not be available in a raw format, instead, an encrypted version of the address will be stored. This encrypted version will be the lookup key for personal address verification, so no addresses can be harvested from the databases.
Extras:
Choicelist personal can also let an individual say “Use this public key to encrypt messages to me.”
When a user sends mail, this encryption could be done automatically for them.
Choicelist on the receiving end could automatically decrypt the message.
Parts needed to implement the Entire System:
Identity manipulation tools
Main Choicelist Database
Mirror data distribution
Public Mirror List
Public Mirror Software
Choicelist MUA (various implementations such as a Java interface for webmail, and others)
Choicelist Personal Id request infrastructure (mail and ISP request)
Choicelist Personal Realtime Spammer List
Complaint verification, manual override system, and appeal process.
Choicelist Database Query Protocol
A clarification on Guaranteed delivery mentioned in the original paper:
As long as messages are handled by Choicelist before other filters act on mail, your responsibility is complete, and that is all that you must guarantee. Delivery notification is optional, but recommended.
