Spam-proofing the mail system
Posted Dec 18, 2003 4:48 UTC (Thu) by
freemars (subscriber, #4235)
Parent article:
Spam-proofing the mail system
The systems described concentrate on identifying the source of the email. I think a more direct approach would be an extension to SMTP requiring a micropayent to the recipient.
At some point as two computers are negotiating to set up a SMTP session the recipient computer can request a micropayment. If the originating computer doesn't comply it gets a brush-off message and the connection is closed. If the originating computer sends a micropayment token the receiving computer immediately takes it to the bank. If the bank OKs the payment the email body is accepted. Otherwise the connection closes with a brush-off message.
In the traditional ISP model this will take place at the ISP level. The customer will eventually log in and retrieve mail. It is vitally important the micropayment get passed on to the final recipient; that's the only person who can tell if an email is legetimate or if it's spam.
When you log into your account and get your mail, it will come with dime-sized credits attached. As you read your mail, you get to decide: if a message is spam, you keep the dime. If it is legetimate, you return a micropayment to the sender, and probably add the sender to a whitelist. (Don't want to refund the payment? You run the risk of getting labeled a deadbeat, and never getting email from anyone.)
Whitelists and blacklists for each email address would be kept at the ISP, and are essential to running this system efficiently. If someone is on your whitelist, the request for a payment portion of the SMTP session never takes place, saving the bank overhead for two transactions (the payment and the refund). Whitelists allow good things like mailing lists to continue operating without a major financial hit. If a sender is on your blacklist your ISP will happily accept the micropayment and message, but silently disgard the latter.
This plan needs several things to work:
**** SMTP and user mail software which supports micropayments.
**** A low-overhead micropayment system. The volume of micropayments this plan would generate would allow the kind of automated procedures needed to make a low-overhead system practical.
**** An RFC setting out how the protocols work
**** Antitrust exemption from the US Congress allowing ISPs to work together to install the plan in a unified manner. If the 10 largest US ISPs announced that after a given date no email would be accepted from strangers unless it complies with RFC####, it would become the de-facto world standard on that date.
(
Log in to post comments)