Subject: [Asrg] Reducing the amount of bogus challenges in Michael Kaplan's ISACS to (almost) zero

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 9 Jan 2005 20:43:56 +0100

This is a small change to Michael Kaplan's ISACS proposal which
addresses its (in my opinion) biggest flaw:

Michael proposes to send out a CAPTCHA via mail. Since the ISACS system
has no way to verify the sender address, it will often (even with the
addition of a heuristic spam filter) send a challenge to an uninvolved
user, thereby significantly increasing the amount of unsolicited mail
for people who aren't using the system.

I suggest that instead of accepting a mail and then sending out a
bounce message with a CAPTCHA, the message is rejected with an URL in
the SMTP reply:

MAIL FROM:<[email-masked]>
250 Ok
RCPT TO:<[email-masked]>
550 Address blocked. Please see http://domain.com/isacs/joe

If the client was a worm or spambot, it will probably ignore the reply
or at worst it will have harvested an URL. No bounce message
will be generated.

If the client was a normal MTA, it will generate a DSN and return it to
the sender of the original message (who should have authenticated
himself to the MTA in an ideal world, but in any case has a rather high
probability of being correct, as Spammers usually don't use normal
MTAs (419-Scammers are an exception, but they also use valid return
addresses since they expect a reply)). The User can then cut and paste the URL to the browser (or maybe
just click on the URL depending on his mailer's features), get a unique
mail address using the CAPTCHA and resend his message to the new unique
address. Or he can decide that the message wasn't that important after
all and ignore it.

I believe that this would restrict the extra traffic and inconvenience to
people who actually want to send mail to people using ISACS.

It doesn't address the other problems of the proposal, though. In
particular, instead of a graphics capable MUA you now need a graphics
capable browser and you need to be online. However, some problems may be
ameliorated by the use of a web server and a browser instead of a static
mail message: The user can choose the language and there may be
different kinds of CAPTCHAs (e.g., an audio-based one for blind users).

There is however one big problem with this change: Not all MTAs
generate standard-conforming DSNs, and some don't even include the
actual error message in it. Users of such an MTA may only receive a
bounce message like "There was some problem sending to the address you
specified. Please check the address and send again", which isn't any use
or even a completely bogus one like "User unknown".

Another problem is that an SMTP reply is restricted to (one line of)
ASCII text and users often find DSNs confusing and cannot find the
relevant information. Even an English speaking user may not realize that
he is expected to click or paste the URL, much less a user who doesn't
understand English.

	hp

-- 
   _  | Peter J. Holzer    | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR       | überhaupt gesprochen, also auch kein Dialekt.
| |   | [email-masked]         | Hallig Gröde ist fast gänzlich dialektfrei.
__/   | http://www.hjp.at/ |   -- Hannes Petersen in desd
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Sun, 9 Jan 2005 16:02:21 -0500 (EST)

"Peter J. Holzer" <[email-masked]> wrote:

> ASCII text

No, it isn't.  I got one (from somebody demoing a similar system) that
was over a dozen lines long.

Seth

---

From: Laird Breyer <[email-masked]>
Date: Mon, 10 Jan 2005 09:48:09 +1000

> was over a dozen lines long.

From the RFC, a multiline reply would look something like this:

250-first line
250-second line
250 last line

-- 
Laird Breyer.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 10 Jan 2005 10:38:13 +0100

On 2005-01-09 16:02:21 -0500, Seth Breidbart wrote:
> No, it isn't.

I should have expanded on that.

I am aware of multi-line replies. I am not sure how well they are
supported, though. I have seen DSNs which contained only the last line
of a multiline reply, so according to the principle "be conservative in
what you send" I would probably restrict myself to single line
responses.

	hp