Channel email

Channel email^[1], unlike filters, lists, and challenges, doesn’t target spammers but treats everyone the same. Its design enables polite conversation, which naturally combats spam.

Conversational requirements

On a technical level e-mail is asynchronous messaging, but on a human level it’s a conversation, with all that implies.

A sociotechnical design would share communication rights by ensuring that:

• e-mail conversations require mutual consent;
• users have the right to be left alone and can refuse to converse;
• anyone can request to converse, given brief requests that identify sender and purpose;
• users converse in a turn-taking fashion, without further introductions; and
• any party can leave the conversation at any time.

Conversation protocol

Channel e-mail supports these requirements by creating a channel entity above any messages sent. Instead of managing messages users manage channels, each a conversation of many messages. A channel created by mutual consent grants parties the right to freely exchange messages, as in current e-mail. If no channel is open, users must negotiate one by channel request “pings”—small messages containing permissions. Opening a channel is a separate step from sending a message, like the handshaking before face-to-face conversations, or that of synchronous communication. This handshaking can be automated, so users just send messages while underneath the computer manages the permissions. Instead of the current “send and forget” one-step protocol, channel e-mail is multistep:

1. . Channel request/permission: a conversation request (A to B).
2. . Channel permission: a permission reply (B to A).
3. . Message transmissions: mutual conversational messages.
4. . Channel closure: either party closes the channel.

Step 3 messages use the permissions of steps 1 and 2 to avoid further channel requests. Channels are defined by participants, not message topic, content, or attachments. Channel control isn’t just the right to tediously reject emails one by one, but the right to close a channel entirely, including any future messages from that source.

Channel e-mail classifies channels into

• channel open: always accept;
• channel closed: always reject; and
• unclassified: ask me each time.

The default would be “Accept all,” as it’s closest to the current state. While most list approaches are centralized, channel e-mail devolves communication control to users. As well as being protected by ISP blacklists, channel e-mail gives users their own accept/reject lists.

List maintenance, a problem for centralized lists, occurs automatically by normal use in channel e-mail—any sent message opens a channel, and any rejected message closes the channel. Also, while ISPs need consensus to change their lists, individual users can open or close channels directly.

Notes

1. ^ Brian Whitworth, Tong Liu, "Channel E-mail: A Sociotechnical Response to Spam," Computer, vol. 42, no. 7, pp. 63-72, July 2009