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

Seth Goodman wrote:

>Joachim wrote on  29 Nov 2006 7:28 P.M. -0600:
>
>> I agree:  Messages flow more easily than money.
>> Which does nothing to alter the fact that PayPal may be just too 
>> expensive. Nor to alter the fact that hash-cash, e.g., doesn't model 
>> a spammer's (or legitimate email sender's) economical reality nearly 
>> as well as money.
>
>PayPal and credit card processors are too expensive for the frequent 
>small payments that are necessary in hash-cash and similar schemes.

hash-cash == use CPU cycles rather than money
That's got nothing to do with PayPal.  What's more, it tries to /avoid/ 
the issues people have with money.  A non-captcha if you will:  In this 
case your computer does some useless work, a captcha prompts you as a 
person to do so.

>These processors are also unsuitable since they are often based on 
>credit, not cash.  They must therefore support chargebacks to the 
>recipient if the card number is later reported as stolen.

Insurance... see below.

>That being said, there _may_ be a way for a PayPal or similar payment 
>processors to participate in a system like this, even with their high 
>fees.  Legitimate senders need to post bonds, but they seldom, if ever, 
>have their bonds claimed.  To make an escrow scheme possible when there 
>are significant transfer costs, escrow accounts would need to have an 
>actual cash balance and recipients would need to reserve their escrow 
>from a sender account until they received the incoming message and 
>agreed it was not spam.  Money deposited must clear the payment process 
>before it appears as a usable escrow balance.  A recipient (or a system 
>operating on behalf of a recipient) must be able to verify that the 
>escrow balance is adequate and then reserve their required escrow 
>amount.  The escrow balance will then decrease until the new recipient 
>either releases the escrow (message is not spam), claims the escrow 
>(message is spam) or a specified time period elapses with no action 
>(recipient fails to decide).
>
>The payment processor takes a fee only when there is a transfer.  The 
>depositor pays a fee when they move funds into the escrow account.  The 
>recipient pays a fee when they claim an escrow amount they have 
>reserved, so they need to set their escrow requirement accordingly.  No 
>fees are assessed for reservation and subsequent release of part of an 
>escrow balance.  The cash balance in the escrow account would generates 
>revenue to pay for the cost of the reservation/release system.  
>Alternatively, there could be a very small fee for reservation/release.

Awesome.

Now, for some technical details.  Might remittance of money need C/R for 
something?  (We don't want PayPal [or whomever] to track our email 
habits, do we?)

>Another interesting possibility is to use sender reputation instead of 
>money.

You just raised two red flags:  Identifiability of senders (that we can 
do without in money schemes) and...

>That is, the recipient could see the sender's statistics for messages 
>they offered new recipients.  To vote on a sender, you'd have to give 
>the system a copy of a message they recently sent you and the system 
>would need the ability to verify that message.  I haven't thought this 
>through at all, so it may not make any sense when there is no money 
>involved.

... the impossibility of "freeBay."  eBay reputation works (often 
enough) because of the cost associated with a transaction, which 
disincentivizes people from generating "feedback spam."

Then, of course, there is the decentralized nature of email that we may 
want to preserve.

[By subverting the security of electronic payments, spammers could
happily continue their business.]
>> The difference being, the spammer's victims aren't compensated 
>> (today). Which has to do with the fact that credit cards are 
>> inherently insecure, which results in high transaction costs.
>
>The cost of credit card fraud is born largely by the merchants who 
>receive chargebacks, neither by the credit card processors and nor by 
>the people who's cards are stolen.  Fees in the credit card business 
>don't have a lot to do with actual costs.

The cost of credit card fraud is borne by insurance.  Maybe by the 
self-insured merchant.  Whether it's an insurance premium or the 
expected loss in credit card fraud per $1 of turnover, merchants will 
put it on the price.

And yes, major credit card companies do offer to "protect" (i.e., 
insure) you as a merchant.

>> Yep, it only works with negligible transaction costs.  Until everyone 
>> figures out what kind of transaction is the least expensive, the 
>> Internet's email protocol should come with a customizable C/R 
>> mechanism.
>
>You can do C/R today,

No, you can't.  Precisely because you are supposed to expect mail 
injection and delivery times to vary wildly.  (You know, because people 
need to inject important messages on a Friday at 7pm and expect their 
delivery some time on the weekend.)

What you can do, ...

>and I have even seen it on free email accounts.

... is captchas to sign up;

>Despite this, C/R has very little acceptance among end users.  I 
>suggest that it is the discouraging aspect of the challenge that 
>bothers people.

... is sending a message back; and ...

>Even greylisting, which is a minimally intrusive form of C/R, has only 
>gained a minor following.

Right, greylisting.  Without having any numbers, my guess is that 
greylisting has become pretty pervasive.  Sending a message (an email) 
back to "implement" C/R completely misses the point.  You blindly trust 
the envelope sender, and you emburden the sender with things that could 
be automated.  (qsecretary, anyone?)

Captchas to sign up, BTW, seem to be a result of people thinking that 
it's too easy to receive many accounts.  However, that doesn't address 
the incentive that spammers have to obtain numerous accounts:  There is 
a bias on most recipients' side to trust fresher accounts.  They cannot 
be blacklisted, complained about, etc.  Ideally, free email accounts 
would no longer lure spammers into signing up for so many of them 
because their predominant cost would be the money their innocent victims 
claim.

>You can challenge From:, Sender:, Resent-From:, Resent-Sender: or the 
>envelope return-path, but none of them are validated so you are likely 
>to abuse innocent third parties.  This is the same problem as an MTA 
>accepting all messages and later bouncing the ones that can't be 
>delivered: without a validated return-path address, you generally abuse 
>others.
>
>The cases that I can think of where it is either safe or somewhat safe 
>to send a challenge are:
[1-5]

Interesting to read, indeed.  But ...

>The spam vector I had in mind, though, was the messages

This all tries to answer the question, how can we be sure to not spam an 
innocent victim by sending a challenge as a fresh email?

Maybe most importantly, I think there may be good reasons to send email 
anonymously.  Not that this necessarily worked today, but one 
fundamental flaw in "sending email challenges over email" is that this 
can only work if the recipient finds a good email address in the 
incoming message to send the challenge to.  In other words:  No email 
must ever be anonymized.  Ouch.

(One caveat:  Depending on some countries' legislation, it may be 
difficult to pay money [or put it at risk] anonmously unless legal 
tender [i.e., cash] is used.)

Then, there is the technical issue of consistently marking the challenge 
as such and as belonging to the original message.  These things all seem 
to be geared towards 100% backward compatibility.  ("MUAs that don't 
know my C/R scheme [i.e., each and every MUA] will just forward the 
challenge to the user as an email.")

In contrast, a "real" C/R email system would be much more like a phone 
call to someone with a secretary.  The secretary won't tire of accepting 
/many/ phone calls, even simultaneously.  The caller will be asked to 
jump through hoops (the nature of which is yet to be defined), depending 
on what kinds of hurdles the callee instructed the secretary to put 
before them.

[Electronic signatures]
>Electronic signatures are useful in exactly the same places as 
>handwritten signatures:  where you need a strong identity assertion 
>that is non-repudiable.

And then, there's personal meetings.  Whatever you tell me in a personal 
meeting, feel free to later deny having said it.  Still, I would be 
confident that it was actually you who spoke when you said whatever you 
said.

Repudiably signing statements in a chat room is to offline signatures 
what a personal meeting is to handwritten signatures.

>That is a small minority of documents, normally ones that must survive 
>legal challenge.  Besides, I'm not asserting that "repudiability of 
>authorship is a good thing".  If you intend to repudiate authorship of 
>something, better to not write it down in the first place.

People tend not to intend to repudiate their authorship.  It's just a 
property of a message exchange system that, when satisfied, implies that 
the intended recipient of a message can verify the sender's authorship, 
but nobody else can.

If I need to sign messages to you (either in OpenPGP or in S/MIME 
format) just so you can deem yourself allowed to send a challenge over 
email to me, anyone can verify my signature.

[Fake stories will be all the rage in the news.]
>> I take exception, but do go ahead and prove me wrong.  Forward a 
>> forged email to your local newspaper, with, say, $CELEBRITY 
>> confessing to $FELONY.
>
>Why would I want to libel someone?

To prove it's possible.  Maybe you feel that's morally wrong.  Many 
people won't.

>Now if I sent a newspaper a legitimate message I received from someone 
>that although unsigned, still admitted to serious wrongdoing, it would 
>get a lot of attention.  As it should.

Well, replace "$FELONY" by "$OBSCENITY" (which may be lawful).
Either way, what if someone sent the paper an illegitimate message, 
though?

>> [If a mailing list maintainer asserts Seth Goodman sent a message, 
>> that's at least as good as an electronic signature.  If not better.]
>
>This is a straw man.  A mailing list distribution will generally be 
>believed to be from the claimed author, as long as there is no reason to 
>distrust the mailing list itself.  There may be no proof, but that isn't 
>needed most of the time.

Sure, /most/ of the time my snail mail arrives in evelopes that have 
probably not been steamed open before.  Should we all use postcards, 
hence?


--Joachim