Re: [Asrg] C/R Thoughts: Take 1

Kee Hinckley <nazgul@somewhere.com> Sat, 17 May 2003 00:32 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15375 for <asrg-archive@odin.ietf.org>; Fri, 16 May 2003 20:32:43 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4H00Rd24012 for asrg-archive@odin.ietf.org; Fri, 16 May 2003 20:00:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4H00RB24009 for <asrg-web-archive@optimus.ietf.org>; Fri, 16 May 2003 20:00:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15366; Fri, 16 May 2003 20:32:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GpeI-0003lH-00; Fri, 16 May 2003 20:34:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GpeH-0003lE-00; Fri, 16 May 2003 20:34:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GNx7B23895; Fri, 16 May 2003 19:59:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GNw8B23802 for <asrg@optimus.ietf.org>; Fri, 16 May 2003 19:58:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15313 for <asrg@ietf.org>; Fri, 16 May 2003 20:29:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gpc3-0003kj-00 for asrg@ietf.org; Fri, 16 May 2003 20:31:47 -0400
Received: from www.somewhere.com ([66.92.72.194] helo=somewhere.com) by ietf-mx with esmtp (Exim 4.12) id 19Gpc2-0003kg-00 for asrg@ietf.org; Fri, 16 May 2003 20:31:46 -0400
Received: from [66.92.72.194] (account nazgul HELO [192.168.1.104]) by somewhere.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 2356949; Fri, 16 May 2003 19:32:57 -0500
Mime-Version: 1.0
X-Sender: nazgul@somewhere.com@pop.messagefire.com
Message-Id: <p06001255baeb2b933a1a@[192.168.1.104]>
In-Reply-To: <MBEKIIAKLDHKMLNFJODBKEDIFCAA.eric@purespeed.com>
References: <MBEKIIAKLDHKMLNFJODBKEDIFCAA.eric@purespeed.com>
To: Eric Dean <eric@purespeed.com>
From: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: [Asrg] C/R Thoughts: Take 1
Cc: asrg@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Fri, 16 May 2003 20:07:10 -0400

At 7:02 PM -0400 5/11/03, Eric Dean wrote:
>-Subject header: Should the original subject header be preserved or a new
>subject header be sent.  C/R systems might avoid C/R loops using a
>convention.

Having recently tried to communicate with a customer who is using 
SpamArrest, I have a strong opinion there.  You *must* preserve the 
subject.  SpamArrest almost gets it right.

1. Customer sends mail to our support staff.
2. Our support system replies, with a ticket in the subject.
3. SpamArrest replies with the ticket in the subject.
4. The SpamArrest message gets properly placed in the correct support queue.
5. Support person clicks on link.
6. Customer gets our auto-reply.
[Here's where they blow it]
7. SpamArrest sends a confirmation message telling us that the 
message got through.  It doesn't have the same subject.  It doesn't 
even have any information in the body telling us *which* message go 
through.  (Frankly, this "confirmation" message looks a lot more like 
an Ad to me than anything else.  There was no need for it--I got the 
same information when I clicked on their web site.)
8. We create a new ticket and send an auto-reply.  *This* one goes to 
SpamArrest's support, since that was the from address.
9. SpamArrest support sends us a challenge.
10. The challenge goes into the new queue.
11. Our support person clicks on the link to validate the message.
12. SpamArrest support gets our message.
13. Our support person sends them a nasty-gram :-).

Needless to say, this increases the cost of our customer support.

 From it, I get the following feelings.

1. C/R systems should preserve subjects through the process.  They 
can add to them if they want, but the original should be there.
2. C/R systems need to have a standard way of identifying themselves 
as such.  This avoids loops, and it let's us shunt them into an 
appropriate handling queue.
3. As I've said before--any system that requires you to do something 
other than just reply (e.g. read a graphic) needs to meet 
accessibility standards.
4. If you have a web based confirmation system, you should also have 
an email-based one.  The fact that I can send you email does not mean 
that I can access your web site.  (Think China, think road-warrier, 
think third world.)
-- 
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
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg