>maybe I'm missing something here. Is making subscriber lists unavailable to
>the public such a hard thing in the automated packages?
I think Michael is missing one of the more convenient reasons for leaving
the subscriber list public. If someone subscribes from a machine like
apple.fruit.com but their simple email address is user @
their From: address will be user @
com and the automated packages
will sign them up at that address. If fruit.com is the inbound MX and is
configured properly, the list mail will still make it to this person. When
they go to unsubscribe, perhaps they are using orange.fruit.com that day.
An automated package isn't going to know that user @
com, and the unsubscribe will fail. The user might even
try unsubbing user @
com, but of course, that will fail too. What
recourse for the user? Grab the user list, figure out which address they
got subscribed as, and try again.
Majordomo can be set to be a bit fuzzy so that the above example is
actually handled. However, you can construct any several more complicated
situations involving forwarding files, etc, where it would be convenient
for the user to figure out what address they had subscribed under by using
the subscriber list.
I used to run with open lists. Got burned by spammers. Now I have to deal
with tracking down these unsubscribe (and address change) cases myself.
That's why you'll find list managers bitter over crap caused by these email
spammers. You go out of your way to do a service for the net to pay back
the institution that has given you so much, and some johnny-come-lately
appears and screws it all up for you - making you into the computer
security nazi you always loathed as an undergraduate.
[Warning, strong opinions ahead]
Re: Signature Line Policies??
>There is a byte of Netiquette of long standing that no .sig shall be more
>than four lines.
Personally, I've always considered .sigs to be the appendix of the
electronic letter body - perhaps useful early in its evolution, but
completely useless today (possibly poisonous :-) I mean, if I want your
address or phone number, I'll just email you for it. Or, hey, I don't
think I've ever seen *that* clever quote from (insert science fiction film
or book or tv series) in all my ten years of reading USENET! Hell, one of
my workmates still uses that "To err is human... to really screw things up
requires a computer" quote in his .sig. Even the cheez gift industry
stopped using that one - the last coffee mug I saw with that quote actually
used greenbar paper with the font found at the bottom of checks!
On the list that I run that I really care about, I hand edit each digest.
All .sigs are trimmed down to just the writer's name. If they include an
email address that is drastically different from the one in the From: line,
I'll let that by as well. Sounds drastic? I've gotten only *ONE*
complaint, and that was from a vendor who wanted to include an eight line
monster with two pager numbers, two fax numbers three regional support
numbers, a full street address, and a quote from Pulp Fiction. Most of the
submitters to my digest don't even bother with a .sig anymore - they have
seen the light. :-)
As a reader, it is tough to keep up with a 40k digest per day, so I try to
make it as easy as possible for my readers to get through. I also remove
excessive quoting (which seems to be a big problem on this list). Huge
amounts of quoting makes digests *incredibly* difficult to read and follow.
(hint hint! :-)
Of course, this signature policy isn't for everyone. It requires a bit of
work (I edit with vi, and have it down to "dd.." (three lines of a four
line .sig gone with that keystroke sequence)). And it probably wouldn't
work on a more social (as in soc.*) type list (I run an automobile list).
But my subscribers seem to be happy with this policy. I do run a web site
that goes with the list that allows subscribers to enter all the info that
would normally go into a .sig file, and people can do lookups and searches
on that info.