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

David Sanchez wrote:

>> >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?
>
>Yep, not too many times, but this happens.
>
>Mail lost within my MTA ? Nope, not a single one in 5 years using qmail.

qmail is hard to misconfigure, but it happens.

>Mail lost in another MTA? yep, certainly, but is something you could 
>not control

Bottom line:  email is not as reliable as you claim it is.

>On the other hand MUA option of Read confirmation works fine.

I bet you can't tell at what time I read your message.

>Repudiable signatures? seems interesting. But I think this is not what 
>the original mail talked about.

Yes, it was about captchas exclusively.  Which is why I said that a 
general-purpose C/R framework would be preferrable.

>> >How many times you are required to pay to see a webpage,
[...]
>>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.
>
>Sorry, i get lost... a security deposit?

Sending email means drawing attention on the recipient's side.  Spammers 
abuse this in that they get their recipients' attention for free.  This 
should be penalized.  Legitimate senders should, of course, pay nothing.  
Unfortunately, legitimate senders can only be told apart from 
illegitimate ones after the fact.

I bet your phone company (or any other utility provider) requires a 
security deposit for the event that you don't pay your bill.  They may, 
however, make you believe it's not required as they should be able to 
adversely affect your credit, which is just as good.

>>You would never throw a party and invite more than two people?
>
>They really want to receive my e-mails.
>
>My parties are great.

I guess your invitations are unsolicited.  If bulk is ">= 3," you are 
spamming your prospective guests.

>> >>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?
>
>When i send you an e-mail, you can be off-line :-)

But an agent of mine will happily accept your email on my behalf.

>> >E-Mail must be extremely reliable, not necesarily instantaneous.
[...]
>>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.
>
>The recipient?, IMHO is the sender who is responsible of its own piece 
>of mail.

I wrote, "responsibility for /delivery/."
That's the success response you get in SMTP after the single-dot line.

>> >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?
>
>I look to the bounce mail and it's fairly easy to me to know from 
>Subject and first lines.

"Reliably," right?

[Greylisting]
>This has little to do with being the sender who stores the mail.

Greylisted senders have got to store greylisted messages in their output 
queues.

>An open question: How could you avoid "ipv6 effect" in all this stuff?
>
>(being "ipv6 effect" the transition problem it is suffering)

Send mail by completing, behind the scenes, a web form.  The web will 
transition to ipv6 smoothly, provided it ever will, won't it?


--Joachim