Paul,
RFC2369 support will be available in 15.0. If you want to test it, I can
send you a pre-alpha for Windows or Linux.
The reason I did not respond previously is that what I was going to write
was wrong, since the customer is always right. But, what the heck. This is a
technical forum after all.
When the proposal that was ultimately released as RFC2369 appeared in 1997,
I was one of the people who felt that it was backwards; at best a band-aid
when we should be working on a solution delivering serious value; unlikely
to gain wide acceptance among mail client vendors and, as such, unlikely to
be widely used. I thought that it would have been a neat idea if it had come
up in the 80s or perhaps in the early 90s, but for 1997 it was behind the
times.
I also found the proposal offensive as a software developer. It can be
trivially implemented in the list manager, but it is a LOT of work for the
mail client. You get these kludgy little tags that contain URLs for a
variety of very basic actions (help, subscribe, unsubscribe, view archives),
and you then have to figure out a way to present the information
meaningfully, insert dialogs that make sense in the context of the arbitrary
mailing list manager that will have sent the message, etc. This is bound to
be confusing in at least some cases, and guess who is going to be blamed
when that happens? You, the mail client developer!
Trying to think like a mail client software developer in 1997, my top
priority would have been to implement full, proper HTML support, my second
priority would have been to improve that HTML support, and my third priority
would have been to revisit the second priority until I was blue in the face.
I did not see where there would be time to implement controls and buttons
for kludgy e-mail list tags that are not even a standard (and, in fact, have
still not progressed to a standard in the 8 years that have elapsed since
then).
But, more importantly, my experience with e-mail lists told me two things:
1. Where e-mail lists are concerned, people will pick solutions that work
everywhere over solutions that work here and there, even if "here and there"
is well over 50%. There are a number of excellent designs out there that are
hardly ever used because they are problematic with at least one major mail
client. MIME digests for instance, or HTML digests for that matter. Of
course, these are per-user options, so in a way it is an apple to orange
comparison.
2. Where corporate users are concerned, control is key. People want to know
what happens when they send the message, and be able to depend on it.
And this meant that RFC2369 was stillborn. Because it is only supported by a
few mail clients (not including Outlook), it cannot be used as THE
unsubscribe method for your list. At best, it can be one of the unsubscribe
methods promoted in the message. Put the tags in for people who have a mail
client that supports them, and for everyone else, there is an alternate
method. But that of course goes against point 2. If you actively promote two
methods for leaving the list, you lose control - and you increase
complexity. People will call your helpdesk complaining that the unsubscribe
link doesn't work, and you will not know which one they mean. You also will
not know what their particular mail client does when it encounters a
'List-Unsubscribe:' tag. For instance, let's say you have a customer loyalty
program called Executive Blue, and you create a newsletter to go with it.
Let's do like most companies and call the newsletter Executive Blue as well,
for simplicity. Jane Doe pushes the unsubscribe button, and a stern dialog
pops up: "Are you sure you want to leave Executive Blue?" Well, but no, of
course not, what do you mean, I have over 100,000 miles! Oh no, I really
hope it did not cancel my account! You can imagine the helpdesk's joy when
they get Jane on the phone and she explains that she received a message from
Blue Wings threatening to terminate her Executive Blue account but, when
they reviewed the message Jane forwarded, they did not find anything like
that, and Jane hung up after stating that nobody likes a liar.
Since you need the alternate method anyway for the majority of people whose
mail client does not support (and probably never will support) RFC2369, you
might as well focus your limited time and energy on making this alternate
method work well enough to be used as the primary method. And this is
exactly what just about everyone in the industry has done since then: we
have put unsubscribe links in messages. Just about every mail client
supports this, and we retain full control over what happens when the user
wants to leave the list.
The goal of RFC2369, if I remember correctly (and it has been 8 years), was
that the administration of every mailing list could be presented the same
way in the user's mail client regardless of what software is used to run the
list. But RFC2369 does not achieve this, since only two basic tasks plus
help are supported (there is also a post feature, but since it normally does
the same thing as pressing the reply button, I am not counting it as an
RFC2369 feature). Not only is functionality very limited in scope, it is
also not extensible, so vendors that want to provide, say, a button for
switching to digest mode or going on vacation, are not able to do so within
the scope of RFC2369. This lack of extensibility alone should in fact be
sufficient to preclude RFC2369 from becoming a standard.
This being said, I accept that RFC2369 is mostly harmless, and that
supporting it in LISTSERV can facilitate migration from other mailing list
managers, especially in intranet environments where you control the mail
client to some extent. But don't ask me to lobby mail client vendors to
support it RFC2369; I would rather they spent their energies elsewhere, for
instance in standardizing vacation messages.
Eric
|
