Re: (SPAM: 6.737) Re: CAPTCHA over smtp (yet another spam solution to discuss)

R. Armiento wrote:

>Making senders pay for their messages is exactly what CAPTCHAs do. The 
>payment, however, is in a fixed-length human working time.

The recipient should really be able to configure that.  Whether they 
want to see potential senders solve puzzles for them or whether they 
would prefer them to post bonds.

>Unlike a monetary 'postage' this translates well between different 
>economical realities in the world.

Solving captchas, given that computers cannot do that, is a lot like 
currency.  There may be a barrier of entry, but it'd become commonplace 
to hire cheap labor to let humans solve the captchas for spammers.  They 
could just as well be made to pay money for their business.

>Also, a scheme that charges money has to give that money to someone; 
>leading to a significant risk for fraud schemes being invented.  

The recipient (of the message) would receive the money, should they 
choose to seize the posted bond.  No postage.

>Furthermore, stolen money is 'free', so spam may stil exist --- but 
>being paid by unfortunate people with hacked computers

My personal opinion would be that these folks don't deserve better, but 
the more practical answer is that they would need to get insured through 
their ISP.  Credit card numbers are trivial to steal, but fraud is 
almost negligible precisely because of insurance.

>(but perhaps that was the collateral damage you referred to?)

Nope.  The collateral damage lies in the fact that our new email 
protocol will be pretty hard to debug, people won't like to switch over, 
etc.  Plus, I'd rather live in a world where I could introduce my kids 
to the Internet (ummm, text-based, I'd say), let them exchange emails, 
etc., all without money coming into play.  But that's a tradeoff.

>To reiterate, a postage system with money will have these problems:
>
>1. The value of the "attention span" of someone living in a rich economy 
>may be more than someone in a poor economy is prepared to pay.

The rich guy will have to configure their MTA, by means provided to them 
through their MUA (to get that right this time) accordingly.  If I am 
Bill Gates and wouldn't bother peeking at email unless senders post 
bonds worth $10,000, that's one thing.

The other thing is, money is the one widely-agreed-upon resource that 
would be versatile enough to let users customize email behavior in the 
first place.  Charities might have a legitimate cause to send thousands 
of emails (without being whitelisted on the recipients' side).  Should 
they solve thousands of puzzles?  It's more likely they'll have a budget 
(greater than $0; otherwise, they couldn't pay their Internet bill, 
anyway), and that should be able to pay only so many unsolicited 
messages.

>2. Owners of hacked computers would have to pay for the activity of 
>spammers.

See above.  The more paranoid user would refrain from entering their 
financial data into a system that is potentially owned.  (For example, 
they might accept the burden to enter one-time transaction numbers from 
paper every time they send out messages to recipients where they aren't 
whitelisted.)

>3. Scammers would immediately start posting all kinds of fraudulent 
>attractive "mail offers" on web pages etc, to try to get as many emails 
>as possible for which they could release the bonds. Flamebaiting would 
>become a profession!

Well; I can probably access quite a few phony services on the web if I 
were to give my credit card number away.  How is this different?

>These problems seem avoidable by using CAPTCHAs.

But make sure you let users (i.e., recipients) decide how hard these 
puzzles should be.  Now, if the puzzles become completely customizable, 
I might just as well ask potential senders to give me just enough 
information that I could use to be remunerated---if I wish to.

Remember, it should be up to the recipient to completely configure their 
"agent" to present sufficient challenges to the sender.

>Suggestion 1, use HTTP:
>Good part: HTTP is built for single-hop communication, with proxies 
>being available etc.
>Bad part: Current MUAs speak SMTP, so one has to extend them to also 
>speak HTTP (i.e. implement a full 'email-over-HTTP' protocol) (and also 
>HTTPS for encrypted emails).

HTTPS is actually kind-of an added benefit.  It may have its 
shortcomings, but is wider-spread than OpenPGP or S/MIME.  Extending an 
MUA to speak `email-over-HTTP' sounds like remarkably less hard than 
extending it to give the user feedback about the delivery status in the 
first place.

>Or
>
>Suggestion 2, use SMTP but in single-hop mode:
>Good part: MUAs already speak SMTP, so less implementation needed.
>Good part 2: SMTP already provides a well defined protocol suited for 
>email transfer; e.g. error codes, extensions, acceptable delay times, 
>etc. are defined by accepted standards.
>Bad part: Single-hop SMTP is currently being blocked in many current 
>networks. Such setups would need to install an SMTP proxy.
>
>I don't get why you think '1' is obviously a superior solution.

Because it's not "single-hop SMTP."  It's "single-hop SMTP, extended for 
captchas-or-whatever."  It's bound to be as hard to implement as "C/R 
email-over-HTTP."  Plus, it's easy to confuse an SMTP "message queued 
for delivery" response with a an "email-over-HTTP" "message accepted, 
all C/R phases passed" receipt.

The real trouble begins if/when crappy software (on the recipient's 
side; this is no instance of "spammers will just adust") accepts 
messages but /still/ sends auto-generated stuff around (like 
out-of-office replies, etc.).  Requiring a bond to be posted would be a 
real impediment for any such nonsense. ;-)

>>Ah, mailing lists.  Nope, the mailing list would prompt you to solve the 
>>puzzle.  Or pay the money or whatever.
>
>Or, you rely on some semi-automatic scheme for white lists for your 
>friends / work groups.

The important thing is, the challenge is received in reaction to an 
attempt to send something.  It must be the mailing list manager that 
states the challenge to be responded to by the casual poster to the 
list.

If I subscribe to a mailing list but don't give the mailing list manager 
the means to bypass my spam filter (or equivalent thereof), my bad.

>This leads back to the discussion about how to authenticate senders. 
>However, for a CAPTCHA system I really think normal public key 
>signatures are good enough. To create a new key is not "fatal", it just 
>means you has to solve CAPTCHAs again until your new key gets added to 
>your friends white lists.

You may want to familiarize yourself with identity-based encryption.  
But in any event, the real trouble about OpenPGP signatures is that they 
are not repudiable.  Non-repudiability is a showstopper for any email 
authentication system.


--Joachim