I am not so adamant about the need for a manual. The design of the
utility lacks logic. At least the logic needed by a user to set up
a mailing list.
My "bitch" list (so far):
1. Too much reliance of "aliases" to "sendmail". This practice
causes distortions of linear logic. The magic involved in
passing control from program to program is something which David
Copperfield would envy.
2. Implementation of "features" which are contrary to existing docs.
The instructions state that subscribers should send requests to
<list>-request with the specific request on a single line with the
action requested at the beginning of the line.
In practice, if the words "subscribe" or "unsubscribe" are
anywhere in the first 15 lines of a message, that message will
bounce. How can you disable this "feature"? By defining the
boolean "administrivia" as false. What logic connects the word
"administrivia" with performing a word search in subscriber posted
messages.
This is "feature" is obscure to an administrator and a complete
blank to users. Why should they have misspell "subscribe"?
3. What logic dictates that a "digest" should be a separate list?
Here again is an abusive use of the mailer's "aliases" file. How
do subscribers to a digest respond to a topic in the digest?
The desirability of a digest is to avoid so many individual
postings. However, a subscriber to a the digest, must resubscribe
to the list to post a response to a message in the digest.
Perhaps I have not been able to follow the pretzelized logic of
setting up a digest.
This suite of programs seriously lack design parameters and appears to
a series of fantasies glued together. This lack of logical design
precludes the ability of anyone from generating a coherent manual.
vern
--
Vernon C. Hoxie vern@zebra.alphacdc.com
3975 W. 29th Ave. uucp: 303-455-2670
Denver, Colo., 80212 voice: 303-477-1780
Whatever you want to do, do it now.
There are only so many tomorrows.
Follow-Ups:
|
|
