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

I hope you don't mind if we take this back to the list?

Brett Watson wrote:

>On 11/17/06, Joachim Kupke <[email protected]> wrote:
>>However, the "transfer" in that suggests there may be a chain of them.  
>>I take exception to the claim that there is a fundamental need to 
>>chain MTAs.
>
>Mailing lists, for one reason.

These would go away.  To avoid confusion, they would be replaced by 
ordinary mailboxes with read-only IMAP access or RSS or whatever.  The 
mailing list administrator makes the decision who gets to post.  Either 
by whitelisting, or by requiring captchas solved, or by requiring a 
security deposit.  The latter has the benefit that they could seize the 
bond and reimburse subscribers.

>Mail forwarding of any sort, in fact.  In the general case, these 
>result in MTA chaining because they result in address re-writing.

Think web proxying rather than mail forwarding.  Or, more generally, 
nesting one request inside the other.
(In fact, what do you do, as an MX administrator, in a situation like 
this:  For two domains X and Y, all addresses user@X should be rewritten 
to user@Y.  Y's MX is not under your control and won't accept X as an 
rcpthost.  You have a service on X's MX[es] running that services SMTP 
requests and, while processing them, opens another SMTP connection to 
Y's MX, with the envelope address rewritten properly [and 251 reply 
codes output].)

>There are other reasons, but these are the obvious cases.

What are the non-obvious ones?

>> >I meant, greylisting is not related with im2000.
>>
>>But it is.  It is a clunky implementation of it, although mostly 
>>backwards-compatible with SMTP.
>
>Greylisting is an implementation of IM2000 in the same way that a 
>web-forum is an implementation of IM2000 -- i.e. only under a 
>too-liberal interpretation of "is an implementation". In my opinion, to 
>be similar to IM2000 in any significant sense requires that the 
>recipients be in a position to pull the message on demand. Greylisting 
>does not offer that.

How, precisely, is the spam problem mitigated if pulling messages 
happens "on demand" as opposed to "nearly on demand" (i.e., refuse to 
accept a message and say "maybe later" instead)?

[How do people adopt completely new protocols?]
>>Ah, I see.  Get a critical mass to adopt it.  If you can't do that, 
>>you can roll out neither "clean" IM2000 nor captcha-SMTP nor 
>>general-purpose C/R email nor anything.
>
>Not everything requires a critical mass of early adopters. Greylisting 
>can be applied unilaterally, and I'm not sure why you claim that 
>general-purpose C/R requires critical mass, since I've received C/R 
>challenges without myself being an adopter.

The question was how to deal with users' reluctance to switch to a new 
system as illustrated by the de-facto abandonment of IPv6.  If OpenPGP 
were a widely-used message format, in the sense that a critical mass had 
been surpassed, we would be seeing the vast majority of new email users 
create crypto keys before they send their first message.  That's how you 
tell whether a mass is criticial; it's a tautology.  You can still be 
backward-compatible, as in the IPv6 case, and as with C/R applications 
over traditional email.

>CAPTCHA-enabled SMTP seems to me to miss the point of SMTP entirely.  
>SMTP is a machine to machine protocol, and introducing CAPTCHAs into it 
>utterly defeats that design.

It's really captcha-over-mail-injection-on-the-recipient's-side.

>Those who are keen on CAPTCHAs would seem to me to be far better off 
>doing it this way.
[Protecting access to a whitelist rather than the individual message.]

For the record; whether you were to use captchas or financial bonds, 
your comments apply equally:  You would end up protecting your 
whitelist.  Unfortunately, sender addresses are easy to forge (as you 
know); and unfortunately, the occasional email-contact-turned-spammer is 
not unheard of.

>It's better than the CAPTCHA-in-SMTP thing, however, which just Ain't 
>Going to Happen.

It relies on the assumption of a constant reputability of senders.  
C/R-in-SMTP, indeed, means reengineering large parts of how the Internet 
works.


--Joachim