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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg