Whitelisting e-mail is the process of examining each message looking for features which identify it as a message that you do want, with the expectation that at the end of the process, those messages which have not been recognized are probably unwanted.
E-mail whitelisting systems can provide relief from "spam" mail in a way which does not depend on the content of any of the messages. It is my belief that such measures are or will soon be entirely necessary for any individual to be able to make use of e-mail. Users will require at least a small amount more computer "intelligence" at the user end, whether on the user's own machine or on that of their service provider, incoming messages will need to be compared to *individual* preferences for delivery.
Whitelisting alone is an excellent answer for a few uses, such as adult monitoring of a child's e-mail account. Traditional "blacklisting" filtering alone was a reasonable answer for blocking specific types of content, or when the majority of unwanted e-mail had obvious recognizable features. Previous whitelisting efforts have principally been employed when a recipient wanted to allow "trusted" users to send "suspicious" content, such as copies of the unwanted messages frequently shared by those of us who've been writing filters for years.
But a combination of all filtering types is an obviously more powerful solution. Making additions to a blacklisting filter is an easy response when unwanted messages arrive and are not caught by the previous rules. But managing a whitelisting system is more difficult, since unknown senders must get your attention somehow, to get added to the list before their messages can get through.
Some minor whitelisting features are already available from several major providers, such as AOL and Hotmail, but fully employing these currently leaves the user closed off from e-mail contact by anyone they don't add to their lists. This requires that any new correspondent make "out of band" contact with the recipient first, such as by telephone, personal contact, or postal mail. It is as if a homeowner were to give door keys to their friends, but then have no doorbell which others could possibly ring, and not listen for knocking, either. Anyone not already known to the homeowner is unable to visit without first making arrangements by some other method, such as a telephone.
Initial steps toward allowing in-band first-contact have included "challenge/response" systems, such as TMDA, and several others which use website-based "humanity tests" in an effort to prevent senders from creating systems to automate passing the tests.
This way only "humans" can successfully ring the bell to attract the homeowner's attention to the door. But some humans will consider the "jumping through hoops" necessary to pass such tests to be an onerous task.
From over six years of studying the spam problem, it is my considered opinion that such tests are themselves a problem. And that creating a facility expressly for automatically taking those tests is a much better answer.
While it is certainly true that any system which permits abuse is likely to be abused, sooner or later, an abuser cannot pass through an all e-mail confirmation system without exposing their own e-mail address and confirming receipt of a message there. It then becomes trivial for the recipient to block that address, as well as easy to report the abuse to an appropriate provider.
So I concluded that the element which can complete the whitelisting solution is an in-band method for "knocking", and this need can be satisfied by a confirmation method designed specifically to *permit* automation - a protocol.
Any number of whitelisting, closed-loop confirmation, and/or challenge-response systems can interoperate freely if a protocol standard is designed for them to follow.
Of course, the simplest form of whitelisting system is extremely vulnerable to the simplest form of forgery, i.e., forging the spam to appear to have been sent by a correspondent of the victim, or even from the victim's own address. Legislative "solutions" to such forgery might work, but clearly could be too slow to enact. The Receptionist protocol provides facilities, right from the start, to render such forgery ineffective.
Most Receptionist-enabled transmissions include two "token" strings, one for the recipient's future use in return mail, and one as a key, asserting that the recipient previously sent that key (as a token) to the sender. A trivial configuration change in a client program determines whether to insist on the presence of a valid key or not. Such tokens may be vulnerable to various forms of eavesdropping, but little else, are far simpler than alternatives like public-key encryption, and also don't rely on any central "authority" to issue keys - each user is the sole authority for keys used to gain access to that user's in-box.