Subject: RE: [Asrg] Turing Test ...

From: Art Pollard <[email-masked]>
Date: Wed, 02 Apr 2003 22:35:17 -0700

><SNIP>
>If someone sends an email they should accept a reply from the same person
>without this type of performance. Equally nobody should ever be asked to
>respond to a challenge the second or third time they send a message to the
>same person.

I agree.  In fact, I believe that the problem here rests less with the 
challenge / response system and more with the way the whitelist is managed.

A properly designed system would have IMHO added you to the whitelist the 
moment that the student you mentioned sent you a message.  If you are good 
enough to communicate with (i.e., you can infer that you are not a spammer 
because he sent you a message) then you should be automatically whitelisted.

Some of the difficulties to the challenge / response system is that it is 
not standardized and currently requires a separate e-mail from you with 
something that identifies you as a person rather than a machine.  I believe 
that it would be much easier if there were a standard for this sort of 
thing and then the challenge / response could be built directly into the 
e-mail client.  In fact, I do not believe it would need be harder for the 
end user than filling out any of the other header lines such as the e-mail 
address, subject, BCC, etc.

If there were a standard way to do this sort of thing, even while you were 
composing the message, your e-mail client could download the challenge 
graphic and display it in your message composer.  Then you would simply 
fill out the response to the challenge graphic in a text window -- just the 
same way as you would with the e-mail address or other fields.  It doesn't 
have to be hard the way that some of these challenge / response systems 
are.  They are difficult partly because they aren't built into everybody's 
mail clients and so a lot of the shortcuts that can be managed through the 
client aren't able to be taken advantage of.

One of the things I am noticing on this list is that there are a number of 
ways that we can solve this problem.  However, there seems to be resistance 
to solving the problem simply because it makes e-mail more complicated in 
some way.   However, it is this very ease that has gotten us in to the 
problem that we are in.  The current system worked best when the people who 
were on the net were reasonably trustworthy as they worked for the 
Department of Defense, schools, or large companies -- all of which 
typically were able to get rid of the loonies.  Now, we have the opposite 
situation where the loonies are trying to run the show.

I have to wonder, what is easier filling out a challenge / response dialog 
in your e-mail client for the several messages that you send per-day to 
people who you have never e-mailed before (all the other people you have 
communicated with have whitelisted you automatically) or throwing out 70+ 
spam messages a day.

No matter what solution we end up choosing, it is going to be more 
inconvenient than is currently the case.

-Art

-- 
Art Pollard
http://www.lextek.com/
Suppliers of High Performance Text Retrieval Engines.

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

---

From: J C Lawrence <[email-masked]>
Date: Wed, 02 Apr 2003 22:18:20 -0800

On Wed, 02 Apr 2003 22:35:17 -0700 
Art Pollard <[email-masked]> wrote:

> A properly designed system would have IMHO added you to the whitelist
> the moment that the student you mentioned sent you a message.  If you
> are good enough to communicate with (i.e., you can infer that you are
> not a spammer because he sent you a message) then you should be
> automatically whitelisted.

Careful, this is fragile.  My envelope frequently doesn't match my
From:, and in the case of role addresses, the initial To: won't match my
From: or envelope.

> Some of the difficulties to the challenge / response system is that it
> is not standardized and currently requires a separate e-mail from you
> with something that identifies you as a person rather than a machine.
> I believe that it would be much easier if there were a standard for
> this sort of thing and then the challenge / response could be built
> directly into the e-mail client.  

Modulo turing tests, and even there where the Turin test form becomes
standardised...and into spammer software that manage to run an MX for a
while.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 2 Apr 2003 23:43:27 -0800

> From:, and in the case of role addresses, the initial To: won't match 

If a whitelist were implemented by your mail client, it could access 
your address book and automatically adjust your whitelist based on 
what's in there. You could, in fact, automatically implement a 
greylist, too:

1) permanent entry in an address book: whitelisted.

2) cached entry in address book: accepted without challenge, flagged.

3) not in address book: challenge/response, held on to by client until 
the response is seen or it times out.

address book can then be used to implement the blacklist, stuff 
automatically thrown out, similar to how OS X's mail.app implements a 
junk mail filter.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 10:15:05 -0800

On Wed, 2 Apr 2003 23:43:27 -0800 
Chuq Von Rospach <[email-masked]> wrote:
>> On Wed, 02 Apr 2003 22:35:17 -0700 Art Pollard <[email-masked]>
>> wrote:
 
>>> A properly designed system would have IMHO added you to the
>>> whitelist the moment that the student you mentioned sent you a
>>> message.  If you are good enough to communicate with (i.e., you can
>>> infer that you are not a spammer because he sent you a message) then
>>> you should be automatically whitelisted.

>> From:, and in the case of role addresses, the initial To: won't match
>> my From: or envelope.

> what's in there. You could, in fact, automatically implement a

True, but the limitations should be admitted.  For example that doesn't
typically handle role addresses worth a damn.  You mail me at
<list>-owner@ and will get a reply back from claw@.  Then there are the
.forwarding cases we all know and love as list owners.

And that's not mentioning the can of worms on white listing by From:, by
envelope, or by both, and which and when.  FWLIW TMDA takes the approach
of whitelisting by From: and envelope, sending the confirmation request
to the Return-Path -- arguably the safest route, but one I've found a
holes in with misconfigured ISPs who, well, let's just say they're
misconfigured.

  Oh yeah, and as regards the utter lack of complaints on whitelisting
  systems being caused by those complaining not getting thru the
  whitelisting system: It may be a excessively convenient logic.  It
  doesn't support itself here.  My role addresses and lists are under
  TMDA, my personal addresses aren't.  For my list populations almost
  nobody ever uses my role addresses as my personal address of
  [email-masked] is too well known and prominent.  Total valid use of
  role addresses related to the lists in on the order of 5 - 8 messages
  per year.  In that line, the commentaries I did receive after applying
  TMDA were all positive, and all sent to my personal
  non-whitelist-protected address.

> the response is seen or it times out.

There can also be hinting structures, such as mail to
listowner/*-admin/-owner/postmaster/root/etc automagically opens up a
wildcard temp allowance for any address at that domain.  I could also
see header extensions which encode a token in the outbound mail, which
an MUA replying to also quotes in its own headers (along side
In-Reply-To), thus providing more hinting to the return whitelist.

> automatically thrown out, similar to how OS X's mail.app implements a

There are many things which can be done here to improve, but the tend to
bandaides over a hole, and that should be admitted as a cost, especially
by those of us with an excess of role addresses.

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 3 Apr 2003 10:21:14 -0800

On Thursday, April 3, 2003, at 10:15  AM, J C Lawrence wrote:
> typically handle role addresses worth a damn.

not designed to. Role addresses, sort of by definition, don't belong to 
a mail client (even if those role addresses are all handled by one 
person), but to a server and/or organization. So I see handling role 
addresses as a server-based solution. Never intended the mail client to 
handle all whitelisting possibilities, any more than client-based spam 
tools (like mail.app has on OS X) solves the server-based issues of 
spam.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 12:07:58 -0800

On Thu, 3 Apr 2003 10:21:14 -0800 

>> True, but the limitations should be admitted.  For example that
>> doesn't typically handle role addresses worth a damn.

> not designed to. 

Fair dinkum, but beer-swilling humans tend to have different ideas about
such technical distinctions.  

> So I see handling role addresses as a server-based solution. 

So consent/whitelisting structures built into the MTA or server
processes...

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 3 Apr 2003 15:13:43 -0500

At 10:35 PM -0700 4/2/03, Art Pollard wrote:
>If there were a standard way to do this sort of thing, even while 
>you were composing the message, your e-mail client could download 
>the challenge graphic

I can see it now.  When you try and reply to a porn spammer who 
somehow got through, I bet that challenge graphic is going to be real 
interesting.  :-)

You need a new protocol for getting the challenge in advance.
You need to deal with people who send email without web access.
You need to deal with blind people.
And you need to deal with legitimate automated mail senders that will 
either ignore a challenge, or treat it as a bounce and unsubscribe 
you. This means that the first thing you need to solve is the 
whitelisting problem.

When I see a proposal that has plans for all those, I think it's 
worth discussing.  It's definitely my favorite solution for false 
positives, after all other filters have been applied.

-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg