Subject: [Asrg] Are we allowed to extend the SMTP protocol?

From: Jeff Silverman <[email-masked]>
Date: Sun, 09 May 2004 16:12:00 -0700

People,

    I was wandering through the SMTP RFC 
(http://www.faqs.org/rfcs/rfc2821.html and other places), and I got to 
section 4.2 which is the reply codes that the receiving MTA sends back 
to the sending MTA.  I think this is where we ought to focus our thinking.

    Can we modify the SMTP to add an authenticating capability?  I think 
so.  In particular, I notice the following in the RFC:

The list of codes that appears below MUST NOT be construed as
   permanent.  While the addition of new codes should be a rare and
   significant activity, with supplemental information in the textual
   part of the response being preferred, new codes may be added as the
   result of new Standards or Standards-track specifications.
   Consequently, a sender-SMTP MUST be prepared to handle codes not
   specified in this document and MUST do so by interpreting the first
   digit only.

  What if we added a code 320 or 453, I think, which means authenticate 
yourself to me?   Then sending MTA will then queue the message for 
retransmission later.

    The receiving MTA would then send a Turing-difficult test to the 
erstwhile sender of the message, such as a pointer to a graphic that the 
sending MTA has to read (e.g. 
http://www.commercialventvac.com/~jeffs/mail.jpg 
<http://www.commercialventvac.com/%7Ejeffs/mail.jpg>) or it could be all 
text that a human still has to parse for example

   A         H    H     A      RRRR  DDDD     TTTTTTT EEEEEE     SSSSS 
TTTTTTT
  A A        H    H    A A     R   R D   D       T    E         S         T
 A   A       H    H   A   A    R   R D    D      T    E          SSSS     T
AAAAAAA      HHHHHH  AAAAAAA   RRRR  D    D      T    EEEE           S    T
A     A      H    H  A     A   R   R D   D       T    E        S    S     T
A     A      H    H  A     A   R   R DDDD        T    EEEEEEE   SSSS      T

Or it could be a sound clip.
  The sender of the message takes the test, and puts the answer in the 
subject field.  This message is sent to the receiving MTA.  The 
receiving MTA has to go through the message until it gets to the subject 
field so that it knows that this is a test and not a message.

    Once the sender has passed the test, then the receiver can add the 
sender to a white list which is under the control of the user.  I 
realize I am not very structured - this idea is somewhat half baked.  
The user would have three lists of addresses of correspondents: a white 
list, which can be passed without further testing; a blacklist, which 
can be rejected without further testing; and a graylist, which must be 
tested.  Whenever a new correspondent appears, they automatically are 
added to the graylist by the MTA.  If the user decides that this 
correspondent is a spammer, then they can add the user to the blacklist.

    There are a couple of problems with this.  One is that the Turing 
difficult test is language dependent.  I am used to thinking in terms of 
a roman alphabet, but what if the receiver and the correspondent are 
Israeli or Arabic?    Another problem is that if the correspondent were 
to somehow learn that an address was on the receiver's white list, then 
the correspondent could send a message with that address.  The user 
response in that case would be to move that address from the white list 
back to the gray list.

    The big advantage of this scheme is that it requires modification 
only to the receiving MTA and requires no changes to the UTAs.  My 
intuition tells me that there are far fewer MTAs than UTAs and since the 
MTAs are under the control of sysadmins and not users, it will be easier 
to update them.

So, I couple of questions:

1)  Does this sound like a good idea?

2)  If it is a good idea, then what do we do next?

3) If it is a bad idea, then why is it a bad idea, and can it be fixed 
or is it hopeless?

I recognize that this is a variant on challenge/response, but I missed 
most of the discussion of challenge/response and I am not sure I 
understand why it is not a good idea.

Many thanks,

Jeff

---

From: Fearghas McKay <[email-masked]>
Date: Mon, 10 May 2004 11:46:34 +0100

At 4:12 pm -0700 9/5/04, Jeff Silverman wrote:
>understand why it is not a good ide

this sounds like a variation of what happens with camram - see
http://www.camram.org/

Camram is using hashcash tokens that can be generated computationally but
the model allows for payments as well. You can include the hashcash token
with the mail so that there is no need to do the C/R part.

	f

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Bill Cole <[email-masked]>
Date: Mon, 10 May 2004 09:56:42 -0400

At 4:12 PM -0700 5/9/04, Jeff Silverman wrote:
>[...]
>erstwhile sender of the message,

How do you expect to figure out who that is?

>  such as a pointer to a graphic that the sending MTA has to read 
>(e.g. 
><http://www.commercialventvac.com/%7Ejeffs/mail.jpg>http://www.commercialventvac.com/~jeffs/mail.jpg) 
>or it could be all text that a human still has to parse for example
>
>    A         H    H     A      RRRR  DDDD     TTTTTTT EEEEEE     SSSSS TTTTTTT

You are quite completely wrong in assuming that a human is needed to 
parse that.

As for the images that are used by some operations now (like Yahoo) 
to determine humanity, the spammers have already figured out how to 
harness humans to solve them unwittingly. Some people will do 
practically anything for pornography.

Of course, you also run right in to issues of what blind people would 
do. If you think there are no blind people using email, you are again 
quite completely wrong.

>Or it could be a sound clip.

An even more naive idea. To the point of qualifying for words like 'stupid.'

Anyone who can see and display a JPEG image can type back in a 
character string as long as it sticks to a limited character set like 
the mailsafe 64, but identifying a sound is impossible to people with 
bad hearing and probably to anyone who does not share a specific 
dialect with the test administrator.

>   The sender of the message takes the test, and puts the answer in 
>the subject field.  This message is sent to the receiving MTA.  The 
>receiving MTA has to go through the message until it gets to the 
>subject field so that it knows that this is a test and not a message.
>
>     Once the sender has passed the test, then the receiver can add 
>the sender to a white list which is under the control of the user. 
>I realize I am not very structured - this idea is somewhat half 
>baked.  The user would have three lists of addresses of 
>correspondents: a white list, which can be passed without further 
>testing; a blacklist, which can be rejected without further testing; 
>and a graylist, which must be tested.  Whenever a new correspondent 
>appears, they automatically are added to the graylist by the MTA. 
>If the user decides that this correspondent is a spammer, then they 
>can add the user to the blacklist.
>
>
>     There are a couple of problems with this.  One is that the 
>Turing difficult test is language dependent.  I am used to thinking 
>in terms of a roman alphabet, but what if the receiver and the 
>correspondent are Israeli or Arabic?    Another problem is that if 
>the correspondent were to somehow learn that an address was on the 
>receiver's white list, then the correspondent could send a message 
>with that address.  The user response in that case would be to move 
>that address from the white list back to the gray list.
>
>     The big advantage of this scheme is that it requires 
>modification only to the receiving MTA and requires no changes to 
>the UTAs.  My intuition tells me that there are far fewer MTAs than 
>UTAs and since the MTAs are under the control of sysadmins and not 
>users, it will be easier to update them.
>
>
>

It's an OLD idea which has proven in practice to be garbage.

What you are talking about is generally referred to as a 
'challenge/response authentication protocol' and the acronym is 
fitting. I have received dozens of those challenges in the past year 
for mail I never sent along with hundreds of normal bounces from mail 
systems which accepted mail with my address in the envelope

ONE such challenge to any mail hitting my private domain is adequate 
for me to never accept a second piece of mail from that system again. 
If such a mechanism became anything like a standard practice, I'd 
abandon email.

>2)  If it is a good idea, then what do we do next?

Drive a stake through its heart so it stops rising from the dead 
every time someone new starts thinking shallowly about how to stop 
spam.

>3) If it is a bad idea, then why is it a bad idea, and can it be 
>fixed or is it hopeless?

Hopeless.

>I recognize that this is a variant on challenge/response, but I 
>missed most of the discussion of challenge/response and I am not 
>sure I understand why it is not a good idea.

The archives are open. Years of discussion in comp.mail.* and 
news.admin.net-abuse.email are open through Google. Read them. If 
reading the prior discussions of challenge/response ideas and 
implementations fails to convince you that it is an unsalvageably bad 
idea, come back and explain how it can be implemented so as to NOT 
generate robotic, bulk, unsolicited email in my mailbox.

There are language dependencies, technology dependencies, and human 
ability dependencies. Each is fatal in itself. The recent past of 
people adopting these sorts of measures for other media like websites 
(where those flaws are  subject to some mitigation) has led to an 
attack which is intrinsically impossible to overcome: the entity 
seeking to automate the test merely hooks the tests up to a proxy 
system fronted by something that he can draw a lot of human eyes to, 
such as a free porn site. There's no clear way around this.

-- 
Bill Cole                                  
[email-masked]

---

From: der Mouse <[email-masked]>
Date: Mon, 10 May 2004 21:31:59 -0400 (EDT)

I received two copies of the list message, differing most notably in
their From: headers:

> From: Bill Cole <[email-masked]>
> From: Bill Cole <[email-masked]>

Perhaps someone is looping list mail back, mangling the From:?

> do.  If you think there are no blind people using email, you are
> again quite completely wrong.

I even know two of them.  One I know better as a mud user, but he also
does email; he uses a speech synth.  The other one has a Braille
"display".

>> Or it could be a sound clip.

Deaf people.  Or people with a visual, but not auditory, comprehension
of the language in question (such as me, if the language were French).
Or, as someone pointed out upthread, people with _no_ comprehension of
the language you challenge in.

> the mailsafe 64,

...but even that is severely limiting.  It assumes that the human is
still online when the message delivery is attempted (no more queueing
at and retrying by the sender's smarthost) and it assumes that the
person is using equipment capable of graphics.  For example, if I'm on
the road with my laptop, it would cut me out entirely.

It also assumes the human is willing to jump through your silly hoops,
something which runs counter to experience.

> but identifying a sound is impossible to people with bad hearing and
> probably to anyone who does not share a specific dialect with the
> test administrator.

English is my mother tongue and I had someone forward me a soundclip (a
recording of the Powerpuff Girls intro - "Blossom, commander and the
leader, ..." - and I couldn't tell what Bubbles was being called until
I googled for the parts I could make out.

It took me years of listening to Manic Monday (Bangles) until I managed
to convert the sounds making up the line "kissin' Valentino by a
crystal-blue Italian stream" into a coherent sequence of words.

And I'm even less capable of playing sound clips than I am of
displaying images.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Bill Cole <[email-masked]>
Date: Mon, 10 May 2004 22:25:01 -0400

>Perhaps someone is looping list mail back, mangling the From:?

No, I mangled the From myself early today, and have no idea how the 
one with the errant 'v' ever made it to the list at all, much less 
with that wild additional domain added. My only guess is some 
resolver/nameserver combo somewhere that tacks on a cnri.reston.va.us 
to every query and has a wildcard in that zone.

-- 
Bill Cole
[email-masked]