Let me try to give some constructive suggestions:
> At 8:23 AM -0800 2/4/97, Tom Limoncelli wrote:
>
> >I would be interested in seeing the text of Chuq's message that went
> >out to all these users.
>
> Here you go. Suggestions welcome. Note that the mailer program puts a
> short paragraph ahead of
> this with the subscribed address in it and noting that this address is
> on ony of my mailing lists.
Three principles of business writing:
1. Brevity.
2. Nobody reads beyond the first paragraph.
(well, really that should be "The first paragraph
should tell the reader if they need to read more
than the first paragraph)
3. A well-labeled table is better than a paragraph.
That's why my first paragraph was very specific: You are on mailing
list FOO as BAR and if this is OK, stop reading.
Your goal of sending one message per person is a good one. Since
you are condensing "list1, name1", "list2, name2" and name1 == name2,
you could say:
$ This is a subscription check. Automatically generated by ListCheck.
$
$ DO NOT REPLY UNLESS SOME OF THE INFORMATION BELOW IS INCORRECT.
$
$ You are subscribed by the name: name@place
# On the mailing list called: list1
$ and on the mailing list called: list2
$ and on the mailing list called: list3
> ---
> This message is a test of the address you've used to subscribe to one
> or more of the mailing lists on solutions.apple.com. You do not need
> to take any action to remain subscribed to the list.
>
> DO NOT REPLY TO THIS MESSAGE. If you receive it, you should do nothing
> except delete it.
I think this line wouldn't be on the first screen-full on a Mac,
xterm, AOL screen, etc.
> There are mail systems attached to the Internet that do not return
> information that allows us to properly maintain the mailing list
> subscriptions when accounts on those sites are deleted. Because of
> this, every so often, we have to send out a test message like this that
> has been specially encoded to allow us to look for bounced/returned
> mail and find the address that it was sent to. If all mail systems
> followed the rules, this wouldn't be necessary. Unfortunately, though,
> it is.
The above is technical detail that the average person doesn't
understand. Could this be moved to a web page and replace
this paragraph with "For technical details, check http://....";
> If your mail is working normally, this mail is delivered to you, you
> delete it, and everything is fine. The only mail we care about is the
> mail that is returned to us, since that flags the accounts that are no
> longer functional. These messages are coded to identify the address
> we've sent to, so we can find those on our subscription lists and
> delete them.
My eyes glazed over after this paragraph and I understood it :-)
> We apologize for the junk mail. If there we could use a different system
> that didn't intrude into your mail box, we'd use it. Because of the
> loads these malfunctioning addresses cause on our servers, every few
> months we need to track them down and remove them, and this is the most
> reliable way of doing so.
>
> If you have any questions about this, please contact
> postmaster@solutions.apple.com. Please do NOT reply to this message or
> send other e-mail to this address, or you risk it being taken as a
> bounce message by our processing software and having your subscription
> terminated by accident.
>
> Sincerely,
>
> Chuq Von Rospach (postmaster@solutions.apple.com)
> Apple IS&T Network Servers
> Mail List Gnome
> --
>
> >I recently did the same kind of thing and got next to no inappropriate
> >responses. The number was low enough that I don't recall whether they
> >were AOL or not. The message was very carefully worded. I'm sure Chuq
> >was careful too, but I betatested my message so, dare I say, I think my
> >message may have been clearer.
>
> I wouldn't be surprised. Also realize that this is the first time I've
> done an address probe since I started solutions, so there's up to two
> years of accumulated "stuff" I'm cleaning up.
I had 4 years of accumulation, but I don't have mailing lists
as astoundingly huge as yours.
> >My message also put the name of the mailing list AND the user's
> >subscription address in the body AND the Subject: line.
>
> I put the subscribed address in three places: subject, first paragraph
> of the body, and in an X- header. So far, I've only run into a couple
> of sites that strip all three of them (and yes, there are a couple that
> do, but fortunately, I could backtrack to find the addresses anyway.
> sheesh)
The guy that wrote qmail (Dan) he included an RFC for making the
envelope error's to be something like list-owner=user.foo@listhost.com
so that if you bounced it to "list-owner=user.foo@listhost.com" it
would go to the "list-owner" mailbox (if you configured your system
right), but then you could tell what address was really bounced.
> I didn't have list information in there because of the sheer number of
> lists and the complexity of trying to build a unique set of addresses
> for the site and tying list names to them. More programming hassle than
> I wanted to do this round.
If your input file looked like:
user@host list1 list2 list3
user@host list1 list2 list3
user@host list1 list2 list3
(which can be generated by simple awk scripts) you can use the format
I suggested above.
> >This meant
> >that extremely misformed bounces had 2 changes of telling me the
> >mailing list/user that was bouncing. Something I later noticed was the
> >few users that replied with, "Yeah, remove me" but no context usually
> >didn't zap their subject line so I was able to guess what they wanted.
> >
> >Basically, I didn't LET the users fuck up.
>
> Yup. I'm handling both sets, but it's interesting to see who follows
> directions and who don't. Right now, it's about 55% following
> directions, but if you split that up, people who want their address
> CHANGED have a high rate of following the directions, and people who
> just want their subscriptions dumped have a very high rate of ignoring
> the instructions. Which kinda figures, because since I mail
> instructions twice a month, the ones most likely to ignore instructions
> would teh be ones in this situation...
I got a very different ratio. I hightly recommend beta testing.
We engineers are horrible writers. I had to design a series of
tests to figure out what works best. In hindsight, I should have
asked a person from our tech-pubs group.
--tal
--
Tom Limoncelli -- tal@dnrc.bell-labs.com (work) -- tal@plts.org (play)
"A bend in the road is not the end of the road
unless you fail to make the turn."
Follow-Ups:
References:
|
|
