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

Joachim Kupke <[email protected]> Tue, 14 Nov 2006 18:48:34 -0800
Newsgroups gmane.mail.im2000
Message-ID <[email protected]>
David Sanchez wrote:

[i18n of challenges in C/R-enabled email protocol]
>At least is something to take account.

Yes.  However:  How many properly-internationalized bounces of 
traditional messages have you ever received?

[Output queues as an essential feature of email]
>Reliability is something I love in e-mail.
>
>I'm very happy with how it is working now.

You never ever had an email lost?  Or (maybe worse) people calling you 
up immediately after sending you something, and they go, "did you get my 
mail?"  And you have never had a hammy message identified as spam?

>On the other hand, queues is not the trickiest part of the whole e-mail 
>system for a user.
>
>BTW, the common user tend to be realy ashtonished in how easy is to 
>forge e-mail adresses.

Which brings us back to the need for repudiable signatures.  Which 
brings us back to the need for a C/R system underneath the user-visible 
exchange of messages.  (And as an aside, it also brings us back to how 
email is different from snail mail and shouldn't be designed to work 
like it.)

>Your definition of spam is as valid as mine, just because is by 
>definition a subjetive matter.

So, there is an objective definition that says it's subjective?  Which 
is the objective definition?

>What is unsolicited and what is bulk (3 unsolicited mails in spanish 
>law is bulk and BTW and a crime).
>
>>Oh, your definition (from mw) involves "bulk."  You said your example
>>was spam by definition.  Notwithstanding whether it's criminal or not,
>>how is it "bulk"?
>
>3 :-P

What, you can blackmail me twice, and the third message makes it bulk 
and therefore spam?

>>>>>Moreover the idea of paying for sending is against current Internet 
>>>>>philosophy.
[...]
>This is an obvious claim.
>
>How many times you are required to pay to see a webpage,

Often times.  Think subscriptions to academic journals.

>send a e-mail or send an IM to a pal?

The proposal does not at all go as far as that.  Pledging money is 
different from spending money.  Think of it as a security deposit.  If 
you do screw things up, you can be held accountable.  If you don't, you 
just move on.

>>>>>I will just quit using, developing or maintaining a service in that 
>>>>>paying is a MUST. Simple as that.
[That decreases your chances of approaching new acquantainces via 
email.]
>Nope, i'll pay a reasonable amount for what i consider is worth it.
>
>I love the good things of current e-mail, I just don't want to lose the 
>good things.

Amongst which is the possibility for advertisers to pay an ISP to let 
them bypass their anti-spam filters.  I would much prefer to see the 
individual recipient, the victim, to cash in on spam.

>>Define "unsolicited."  Quantify "bulk."
>
>Unsolicited is, more or less, unwanted.

Without going into the nuances of the differences between soliciting and 
wanting...  spam is avoidable, then.  You make your attention's price 
tag such that you would actually want to receive messages you would 
otherwise not want to receive.  To be fair, this assumes that mail 
recipients are "homines economici."

But the technical challenges are far more interesting to discuss than 
the economic theory.

>Bulk is 3.
>
>This is what the law says in spain :-D

Irrespective of what makes the law of the land particularly reasonable:  
You would never throw a party and invite more than two people?

>> >e-mail was designed pretty much like snail-mail
>>
>>And that's a shortcoming.  With snail mail, you need letterboxes, and 
>>a mailperson must come, either to you or to the letterbox, and they 
>>must pick stuff up, etc.
>
>This is what an MTA do :-)

The fact that the design was implemented doesn't make the design any 
better.

>>On the Internet, unless we're talking yesteryear's UUCP connections, you
>>can approach anyone instantly.
>
>This is, from my point of view, not necesarily true.

Example?

>E-Mail must be extremely reliable, not necesarily instantaneous.

How is email reliable if everybody doesn't use advanced MTA software?  
Regarding the instantaneousity, there is a fine line.  Messages need not 
appear on the recipient's screen instantaneously.  But the recipient (or 
an agent on their behalf) should assume responsibility for delivery of 
messages fast.

[Bounces]
>I want to receive notification of an e-mail bounce. Not the whole e-mail.

How do you (reliably, right?) identify the original message?  Would you 
also like to receive delivery notification messages?

The original email design, BTW, did have the scenario in mind that you 
would send something out and /not/ archive this message; say, you would 
pipe stuff into sendmail on the command line.

In such a case, full-fledged bounces are warranted.

[IM2000 prevents zombies from spamming]
>>Greylisting already achieves that.
>
>Nope, if the "spam worm" is intelligent enought to resend the mail 
>(just like an MTA do) (hey, they can implement a queue :-P ).

If the spam worm is intelligent enough, they can send both the 
notification and the actual spam message from the zombie machine.  
Conceptually, greylisting /is/ IM2000, with two disadvantages:  Senders 
wait busily, and usually, recipients (users) have little control over 
the time window during which their inboxes are opened for messages from 
new addresses.

>Change "Spam is unavoidable" with "Unsolicited bulk mail, with current 
>email infraestructure and behaviour is unavoidable"

That's the point of changing the infrastructure, right?


--Joachim