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
Valdis Kletnieks <[log in to unmask]>
Wed, 31 May 1995 12:17:52 -0400
text/plain (85 lines)
-----BEGIN PGP SIGNED MESSAGE-----
 
content-type: text/plain; charset=us-ascii
 
On Wed, 31 May 1995 09:53:27, you said:
> I thought there was a rule in RFC822 that says:
>
> if there is a reply-to field, reply should go to this address
> if there is no reply-to field, reply should go to the sender address
> if there is neither a reply-to or a sender field, reply should go to
>   the from address
>
> So why shouldn't this scheme be followed for mails to the listserv machine ?
 
Umm.. because RFC822 botched the semantics of Sender: - note that it's
overloaded with two different meanings.  Section 4.4.2 (appended) says
to list the address of who sent the message *even if it is a system or
process*.  It also is unclear whether for a Listserv-type scenario,
the Sender: should be set to 'listserv' as per the first paragraph
(who actually sent the message as an agent of the author) or if it
should list the author (as per the third paragraph).  Of course, this
would be a non-issued, except Section 4.4.4 says to send errors to
that address *with the assumption that the Sender: is liveware*.
 
The *fix* is of course to use the MAIL FROM:<address> from the RFC821
envelope - however, this field is usually not available to the Mail User
Agent software such as Listserv or what-have-you.
 
/Valdis
 
     4.4.2.  SENDER / RESENT-SENDER
 
        This field contains the authenticated identity  of  the  AGENT
        (person,  system  or  process)  that sends the message.  It is
        intended for use when the sender is not the author of the mes-
        sage,  or  to  indicate  who among a group of authors actually
        sent the message.  If the contents of the "Sender" field would
        be  completely  redundant  with  the  "From"  field,  then the
        "Sender" field need not be present and its use is  discouraged
        (though  still legal).  In particular, the "Sender" field MUST
        be present if it is NOT the same as the "From" Field.
 
        The Sender mailbox  specification  includes  a  word  sequence
        which  must correspond to a specific agent (i.e., a human user
        or a computer program) rather than a standard  address.   This
        indicates  the  expectation  that  the field will identify the
        single AGENT (person,  system,  or  process)  responsible  for
        sending  the mail and not simply include the name of a mailbox
        from which the mail was sent.  For example in the  case  of  a
        shared login name, the name, by itself, would not be adequate.
        The local-part address unit, which refers to  this  agent,  is
        expected to be a computer system term, and not (for example) a
        generalized person reference which can  be  used  outside  the
        network text message context.
 
        Since the critical function served by the  "Sender"  field  is
        identification  of  the agent responsible for sending mail and
        since computer programs cannot be held accountable  for  their
        behavior, it is strongly recommended that when a computer pro-
        gram generates a message, the HUMAN  who  is  responsible  for
        that program be referenced as part of the "Sender" field mail-
        box specification.
 
     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
 
        For systems which automatically  generate  address  lists  for
        replies to messages, the following recommendations are made:
 
            o   The "Sender" field mailbox should be sent  notices  of
                any  problems in transport or delivery of the original
                messages.  If there is no  "Sender"  field,  then  the
                "From" field mailbox should be used.
 
 
 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
 
iQCVAwUBL8yWrdQBOOoptg9JAQF5aAP7B6BGsFdkyx/lPDoQpTFr2MdefQjKgovN
cudk17K7cBBrPAUf92pOL+BIxtN0xFglm+iz+ZS776ZoKVu5Wnp246mFTVF6mfSz
B8kVqnhawMXQ2yFF7ph3Et8TUVbG7ePjRF4l8osVXxwVXW69EzflnnprCzJ3l4ED
Ft863ZC9+XU=
=CKHt
-----END PGP SIGNATURE-----

ATOM RSS1 RSS2