At 08:54 AM 8/26/94 -0700, Jerry Peek, O'Reilly & Associates Inc. wrote:
Jerry - I'm glad to learn that you are writing this book. Here are some
comments based on ListProc 6.0b. I've never taken the time to upgrade to
6.0c. I've been running ListProc since 5.0a. I'd like to know how much
trouble I'll have in updating to 6.0c, and what the benefits are, given that
the original port was dead-easy, and now my 10 lists are running fine.
>Here are some of the things I'm looking for:
>- Do you do something that other list owners/admins would find helpful?
I have a PERL script which generates posting statistics for a list for a month.
I have a PERL script which does my notion of a month-end cleanup for a given
list, and for the top-level ListProc logs.
I have a PERL script which I use as an "answering machine" for the
listname-request address.
I'll send these to you if you're interested.
>- Have you customized your list software to do something useful?
- I diddled the signup code to remove mention of ILP and clarify the language.
- I changed list.c and listproc.c to ALWAYS include hostname in the HELO
string for the system mail text generation. This seems to be absolutely
required by about 5% of my subscribers' sites.
Otherwise, my system is mainly stock.
>- What do you wish you'd known when you started being a list owner/admin --
> that you had to learn "the hard way" instead?
- ListProc does not clean up any of its own messes. It's necessary to write
your own scripts and use cron or manual processing to run them. I tend to
run cleanup monthly.
- Don't ever "cheat" and edit the .subscribers file with ListProc running.
You'll probably drop somebody's subscription which got added by listproc
while you were editing.
- Do NOT make "listname-request" an alias for "listproc"! The messages
people get back from this are almost always "error, you screwed up", and
this either annoys or confuses people. Send listname-request either to an
answering-machine script or to a human list-manager.
- Learn to use the SYSTEM request, even if only for
subscribe/unsubscribe/set list mail mode. It will help a lot if you're
travelling with a laptop, and even if you're not - it's damned handy.
- Write a FAQ or similar, and put it in the .info and .welcome files. I
make them identical' it's easier. Explaint your list's policies, and
explain in friendly language how to subscribe, unsubscribe, change into (AND
OUT OF!) "digest" mode, etc. Most people won't read it - repost it to the
list monthly; it may save you a few minutes.
- The list owner should not care about people who attempt to subscribe or
unsubscribe and fail. There are MULTIPLE ways they can learn what's wrong
if they'll just read. If they won't read, you don't want them - you'll end
up babysitting them every time they need anything administrative.
Conversely, if they ASK you for help - be as helpful as possible without
doing it for them.
- Use at least CCERRORS in the owners file. If somebody's mail starts
bouncing, POSTPONE them or UNSUBSCRIBE them right away. If you have other
subscribers at the same site, ask them to tell the bouncer to get in touch
with you. Then forget it. As above - if they won't work to fix it, you
don't need them. If EVERYBODY at a given site starts bouncing, the problem
is obvious - and don't UNSUBSCRIBE the right away.
>- What have been your toughest problems? If you've solved them, how?
- DNS lookup for SMTP via system mailmethod caused a LOT of excess network
traffic and CPU usage on my list machine. Solved by running a caching named
on the list machine itself.
- ListProc uses the "From " line, not the "From:" line, to determine return
addresses. Our site uses smail3, and the "From " line always contains a
bang-path. This causes MUCH confusion among the list operator, users, etc.
The alias schemes I've seen to deal with this will only work for 95% of the
addresses - and 95% of the addresses don't give me a problem. I've "solved"
this by telling people not to worry about it, and dealing case-by-case with
the few actual technical problems that do come up.
>- What topics should this book cover -- and why?
- I wish there had been a startup checklist. There's a lot of configuration
to be done, and no central documentation which describes it comprehensively.
- I wish there were fewer options, and that the defaults and examples were
consistent. This is related to the configuration stuff - I don't want to
choose between "you might want to do this THIS way, and you MIGHT want to do
it THAT way" when the subject under discussion is new/foreign to me. I
wanted a default which should work for most circumstances, and learn the
details later.
- A guide to the most-frequently-used commands and options, separated for
listproc managers and for list-owners.
- A section on remote-listowner duties, the commands and tasks they're
likely to need to perform, etc.
- A discussion of e-mail ettiquite, suitable for posting to all mailing
lists. I get a lot of PeeCee mail users who are wont to put 2 new lines at
the TOP of 200 lines of uselessly-quoted material, which annoys me and many
other users.
>P.S. I understand how people feel about "commercial" messages to lists;
I have no problem with messages of this sort.
Let me know how it's going - I'm happy to discuss my ideas or others, and to
expand on anything I didn't make clear above. Thanks.
--
Carl Paukstis, RRR&RSG DoD#0432 1KQSPI=8.80 carlp@mail.spk.olivetti.com
Olivetti North America carlp@mom.isc-br.com
(Oli North): will deny responsibility voice: (509) 927-5439 0700-1600 M-F
Spokane, Washington, USA FAX: (509) 927-2499 24 hrs.
Follow-Ups:
|
|
