LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"F. Scott Ophof" <[log in to unmask]>
Wed, 21 Jul 1993 20:15:12 -0400
text/plain (75 lines)
On 19 Jul 1993 22:03:20 GMT Eric Thomas said:
>On Mon,  19 Jul 1993  10:47:20 EDT "Michael H.  Morse" <[log in to unmask]>
>said:
>>2. subscribe [log in to unmask]
>...
>when posting. I guess  it is obvious to a programmer  that you don't need
>to retype  the hostname since  you're mailing to that  particular server,
>while it is obvious to a user that it is "safer" to retype it since there
>is then  no possible ambiguity,  "the computer" would surely  rather have
>redundant information than not enough :-)
 
It's this kind of thing I mean; thinking like a user.  A user who
doesn't necessarily (need to) realise that "the computer" has other
sources of info.
On the other hand, what may be obvious to a user (inferred or
assumed), may not be so to "the computer".
 
Take a user (unlikely to know of RFC-822 etc.) reading a LISTSERV
item and wanting to post a reply.  Heesh sees the following hdrs:
   From:       <poster-addr>
*  Reply-To:   listname <submit-posting-addr>
   Sender:     listname <submit-posting-addr>
*  To:         Multiple recipients of listname <submit-posting-addr>
OK, the hdrs with an "*" might not contain the above addr or text.
Still, it's clear to heesh that telling the MUA to reply-to-SENDER
is a valid assumption, especially after having seen a couple of
items with the same type of display.  When the "To:" field contains
the above text, heesh gets the message even more clearly, and might
use a reply-to-TO function (if available).
All this without knowing of RFC-822 etc.
 
It's even more obvious to heesh when "Sender:" and "Reply-To:" are
displayed right under each other, with the values starting in the
same column.  In the Internet world this doesn't seem possible to
achieve, since at least some MTAs there will under *ALL* conditions
rewrite header fields containing addresses, reducing the whitespace
between header-name and -value to one character.
But that's a side note.
 
The header-setup of ListProcessor resembles Revised LISTSERV, except
that only in the "To:" field is the list-name mentioned.
Here's an example:
   Errors-To: <submit-posting-addr>
*  Reply-To: <submit-posting-addr>
   Sender: <submit-posting-addr>
   From: <poster-addr>
*  To: Multiple recipients of list <submit-posting-addr>
If "Errors-To" (the header-NAME) had been one character longer, the
optical pointer cwould have been even more pronounced, even though
slanted.  OK, so "Errors-To:" wouldn't really interest heesh as
casual reader/poster, the pointer is clearer by its repetition.
But omission of the list-name in "Reply-To:" and "Sender:" lines
makes it less easy for a USER to see what's going on, especially
since the list-name IS mentioned in "To:"...
 
As to items distributed by for example Majordomo and TULP, the
contents of the above-mentioned headers seem to depend on the whim
of the poster without a consistent pointer to the list in question
or <submit-posting-addr>.
Exception:  Majordomo puts "listname-request" in the "Sender:" line,
which after some time might trigger heesh to sort of "block off" the
"-request" part in order to determine the <submit-posting-addr>.
 
Due the above, I'd like to suggest as a start the inclusion of the
list-name in the relevant headers of ListProcessor postings.
Could the authors of Majordomo, TULP, and other MLMs specify what
they see as hard indicator for the casual user of what list the item
was posted to and its <submit-posting-addr>?  In other words, if
heesh's MUA has a "reply-to-xxx" function, which header-name should
replace the "xxx" in order to get that reply to the list?
 
 
Regards.
$$\

ATOM RSS1 RSS2