The message I received from "F. Scott Ophof"  said:
...
>
> But if Internet mail contains addresses like <...-request@...> or
> <owner-...@...> in the "Sender:" header to indicate the item comes
> from an MLM, that to me doesn't ensure that those addresses will
> consistently reflect the relevant mailing list.  In other words, if
> the "Sender:"-addr is:
>    <OWNER-listname@somewhere>  or  <listname-REQUEST@somewhere>
> will the following ALWAYS be true?
>    <listname@somewhere>
> or could it also be:
>    <[log in to unmask]>
> or worse yet:
>    <[log in to unmask]>
>
> And besides <OWNER-..@..> and <..-REQUEST@..>, are there any other
> such words that have the same ("guaranteed") behaviour?
 
I see a number of people have responded to your question, and most
seem to be on the mark.  However (and you probably know this already)
the use of prefixes "owner-" or suffix "-request" are really
implementation-dependant.  I know that the mail software I run
(sendmail) looks for and "carbon-copies" to an "owner-" address when
bouncing list-related mail.
 
Our older machine which ran MMDF looked for a "-request" address
instead.
 
I would imagine that list maintainers would use a combination of
"From:", "Reply-To:" and "Errors-To:" headers to ensure that postings
to the list are replyable in a consistent manner.  That way the burden
of reliability rests with the maintainer rather than a list user.
 
>
> Recently I've seen items from some "Revised LISTSERV"s which have
> "X-List:" headers, and that header-line has up to now consistently
> displayed the relevant and correct list-address itself.
> Do I sense an intention to use (and advertise using) that header for
> that SINGLE purpose?  If so, how does one ensure that that header
> will only be used for THAT purpose?
 
I've paraphrased a relevant portion of RFC 822 which explains the
use of "X-" prefixed fields.
 
 .  4.7.4.  EXTENSION-FIELD
 .
 .           A limited number of common fields have  been  defined  in
 .      this  document.   As  network mail requirements dictate, addi-
 .      tional fields may be standardized.   To  provide  user-defined
 .      fields  with  a  measure  of  safety,  in name selection, such
 .      extension-fields will never have names  that  begin  with  the
 .      string "X-".
 .
 .           Names of Extension-fields are registered with the Network
 .      Information Center, SRI International, Menlo Park, California.
 .
 .
 .  4.7.5.  USER-DEFINED-FIELD
 .
 .           Individual users of network mail are free to  define  and
 .      use  additional  header  fields.   Such fields must have names
 .      which are not already used in the current specification or  in
 .      any definitions of extension-fields, and the overall syntax of
 .      these user-defined-fields must conform to this specification's
 .      rules   for   delimiting  and  folding  fields.   Due  to  the
 .      extension-field  publishing  process,  the  name  of  a  user-
 .      defined-field may be pre-empted
 .
 .      Note:  The prefatory string "X-" will never  be  used  in  the
 .             names  of Extension-fields.  This provides user-defined
 .             fields with a protected set of names.
 
 
I've seen various forms of "X-" addresses, none of which are really
"standard" (like X-List and X-Mailing-List).  They may be in (very)
common use, but they don't appear to be guaranteed to exist in the
future.
 
>
> Regards.
> $$\
 
-Ravin
__________________________________________________________________
   Ravin Asar                     |  National Science Foundation
                                  |  1800 G St. NW #440
                                  |  Washington, DC 20550
   Official: [log in to unmask]   |  Phone: (202) 357-5934
   Personal: [log in to unmask]        |    Fax: (202) 357-7663
__________________________________|_______________________________
IMHO