Replying to list

[John Chambers]

Jerry Feldman wrote:
| We have had this discussion at least for 6 years or more. Listservs can be
| set up either to set the list up with a reply-to back to the list, or the
| reply back to the original sender. In the past, the concensus has favored
| setting the reply-to back to the original message sender. I might also add
| that the Greater New Hampshire Linux User Group list is set up the same way.

| Mark Caron wrote:
| > Why is the BLU discuss list setup up this way?  I can't remember a  list that
| >  I have been on in the past that didn't have the reply-to set to the list by
| > default.
| --

What I've seen is that most technical mailing lists  are  set  up  to
reply  only to the sender, while most other lists are set up to reply
to the list. But there are exceptions to the latter.  I'm on one folk
music list whose admin keeps it set to "reply to sender" because this
causes the fewest headaches for her. With most mailing list software,
"reply  to  list"  often  has  the  effect  of  sending two copies of
messages a lot of the time.  There's nothing that the list admin  can
do about this, because it's done by the end-user's email software and
the list software doesn't see the second copy. But the admin then has
to  deal  with the constant email about a "bug" that causes people to
get two copies of messages.

One of the real problems with "reply to  list"  is  that  it  usually
means  ignoring  the  sender's  explicit  instructions, and you often
can't reply to the sender even if you want to.  I've seen any  number
of  messages  on  such  lists  that  don't contain the sender's email
address anywhere.  I've also been frustrated by  typing  an  explicit
"Reply-to:"  line  directing  replies back to me, and seeing that the
list software not only ignores this, but strips my email address  out
of the headers sent to the list.  If I forget to append my .signature
file and my email package decides to not include it, there is then no
way  that the recipients can reply to me, even though that was what I
explicitly requested.

The email package I'm using now (mh) does the nice thing of  building
headers  that  show  all  the  email  addresses  that it finds in the
headers, as To:  or Cc:  lines, so I can edit them fairly easily.  It
also  invokes  $EDITOR  to  edit  the  message,  so I can see all the
headers, but many GUI mail packages hide the headers from the  users,
and  they  don't  know  what  is boing out or where the mail is being
sent.  But if the list  software  suppresses  the  sender's  address,
there's not a whole lot that even mh can do to fix the problem.

Anyhow, I'll vote (again) to keep the list as it is.


--
Modern GUIs are very well designed, for people with three hands. The
real problem has been how slow customers have been to make necessary
hardware upgrades to meet the requirements of the software.
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).