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

[Kee Hinckley <nazgul@somewhere.com>]

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