Remaining open to the world brings opportunity. An old friend reaches out, an unknown colleague with a legitimate inquiry, a business proposal
However, the mechanisms that allow openness are easily corrupted by commercial interests that have neither personal knowledge of nor any interest in the recipient but seek only to broadcast generic messages for minimal profit -- a process known as spamming
Spam has ruined electronic mail, inundating our inboxes with offers for erectile dysfunction drugs, phishing scams, product advertisements and other nonsense, but the problem can be solved by means of authentication and staking, as proposed in this paper
Electronic posts are transmitted with very little knowledge of the sender, the architecture of the SMTP (simple mail-transport protocol) being such that peers on the network can relay messages for each other with only the destination of the message being known
This means that from a filtering perspective most of the header information in a post is worthless. Spam must thus largely be identified by the nature of its content and though significant thought has been given to the problem, resulting in sophisticated technology like Bayesian filters, the process becomes a game of cat-and-mouse, with spammers taking measures to avoid detection
The fundamental problem is that sending messages is free, but transmission should remain free
However, to eliminate spam, a cost structure -- a tax -- must be erected, which begs the question: how shall we determine which messages to tax?
The only party in a position to determine whether a message is spam is the recipient, and there are no hard rules about it. Users who raise the bar too high hurt their availability, those who do not raise it high enough waste their time sifting through rubbish
However, owing to the disposition of spammers vis-à-vis authentic senders, it is possible to segregate the two, namely that faced with the burden of cost, and due to the volume of messages spammers originate, most will simply avoid sending to recipients who impose a tax
The basic solution (the "System") to the problem relies on the following components:
Before a message is delivered to the user, it must be captured for inspection. This can be accomplished via the interposition of the System between sender and recipient which may happen in a number of ways:
- Control the destination - Users create an e-mail address on the System, which they share with friends and the world at large. The system then cleans the message stream, forwarding messages to the user's private address
- Control the source - Users may specify that they will only receive messages from a System-federated mail server. This approach would require that participating mail servers use cryptographic signatures verifiable against a registry to determine whether their mail will be accepted
- Control existing infrastructure - The credentials to existing mail accounts may be shared with the System such that incoming mail can be systematically parsed and managed. In this case the message itself, rather than the source, needs to be curated
- Control flow - Mail forwarding mechanisms may be used to relay incoming messages to the System for inspection before the clean stream may be delivered back to the user. Users then must exempt the System from redirection
Message in hand, the System is now capable of examining the headers of incoming mail. The System will look for the X-SID-SPAMSHIELD header, which should contain the SingleID identifier for the sender. The message must be cryptographically signed, with the public key being stored in the System, as specied by the SingleID Authentication Protocol. The message can then be accurately identified as belonging to a specific sender
Having established the identitty of the sender, the System checks a token balance to be used as a retainer. When the balance has run out, the sender is notified and no further messages are relayed. Messages are delivered with two buttons the recipient may use to classify the message:
- Legitimate - The sender's retainer remains intact and his identity whitelisted, or
- SPAM - The sender's retainer is charged an amount set by the recipient
In the latter case above, sender remains free to attempt again but the System may increase the penalty for rejection
Below are the specific steps for message flow:
- Sender delivers a message to Recipient
- System intercepts message and examines it for authentication headers
- If none are found, System:
- holds the message
- replies to Sender that all messages delivered to Recipient must comply with authentication requirements
- provides a link to System instructions for compliance
- When such headers are found:
- the SingleID identifier is used to retrieve the sender's public key
- the key is used to verify the signature on the message
- the Sender's balance is checked against the Recipient's penalty requirements
- with an insufficient balance Sender is notified of this fact
- otherwise, message is delivered to Recipient
- If none are found, System:
To qualify Senders must:
- Register with System, which includes:
- Installing a SingleID authenticator app
- Integrating the authenticator into their message composition workflow
- Maintain a balance in System token as a retainer against which Recipients can draw
- The System is designed to empower Recipients to determine whether an incoming message is friendly or unfriendly, in the latter case compensating them for the trouble of reviewing the message
- The ease of integration is paramount. Legitimate Senders (like friends and family) need to be able to send a message with a minimal one-time effort, whilst illegitimate Senders face escalating costs
- Perhaps to alleviate the burden of onboarding with token, Recipient can send token to Senders that it knows, as a form of whitelisting
- Some thought must be given to whether the penalty charged should be system-wide or bespoke to the Recipient
- An escalation algorithm for repeat offenders needs to be thought through, optimising for revenue