On Thu, 7 Mar 91 09:32:13 CST Satish Movva said:
>> Could someone explain how the TAG information is placed on
>> mail from listserv lists?
>
>The reason for my query is that our Netnews is subscribed to the lists
>WP50-L and CENTAM-L hosted at node UBVM and it is having problems ...
>
>Mail from the above two lists at UBVM comes with a Sender: tag of
><listmgr@ubvm>, and therefore the fourth and fifth fields of the TAG
>info return UBVM and LISTMGR.  The dilemma now is how can Netnews
>diffrentiate mail from these two different lists?
>
>I have written to the listserv admin at UBVM, who explained that it being done
>this way so that mail delivery errors etc won't bounce back to the list,
>but would instead go harmlessly to <listmgr@ubvm>.  He has further
>stated that other lists at his site will also be converted to this
>format sooner or later.  He has further reiterated that this
>method conforms to RFC822; I checked pages 20-21, sections 4.4.4
>and far as I can tell, he is correct.  Would someone more aware of
>the connotations of 822 please comment?
 
While listmgr@ubvm has a lot of supporters in his reading of RFC822,
there are still pragmatic problems such as the one you mention.
(Another example comes from mail systems like RiceMAIL which need
some indication of the list name to know where to file messages.)
Read on.
 
>My question now is, does 822 or any other standard provide for a tag
>in the mail to explicitly identify the list?  If not, is there any
>way to differentiate between these lists?  Please note that this
>is being crossposted to NETNWS-L and LSTSRV-L.
 
The problem is that RFC822 makes no provision for an automated mail
exploder like LISTSERV.  In most Internet lists, this is handled by
leaving the To: address pointing to the list, but this is not possible
in all cases for LISTSERV (since part of its intended audience uses
mail delivery systems which rely on the RFC822 To: header field rather
than the RFC821 ([B]SMTP) "RCPT TO:" envelope field).
 
Since the Internet mail community is largely indifferent to the needs
of LISTSERV-type exploders, a few of those who seem to understand our
desire for an explicit identification of the list have suggested that
the LISTSERV community should define its own extension to RFC822, such
as a "X-LISTSERV-List: WP50-L@UBVM" header field.  This would have
value only after systems like RiceMAIL and NETNEWS start using it, of
course, but it would be RFC822-compliant.  The principal trouble is
that as an extension field it would not in general be recognized by
other software and networks.  In particular, gateways to other networks
would not be prepared to adjust it to be usable for return mail.  The
long term solution would be to register an official extension to RFC822,
but without Internet support that could be difficult.
 
Another line of argument which has fallen on deaf ears in the Internet
community is that there should be a standard way within RFC822 headers
to identify mail delivery error messages (rather than relying on Eric's
generally reliable but not infallible heuristics).  Suggestions have
been like "Message-Type: Delivery error".  The Internet doesn't need
this, since they use "MAIL FROM: <>" (null address) in the SMTP envelope
to indicate a delivery error message.  Internet purists have pointed
out that if BITNET mailers followed the RFC821/822 interaction rules,
LISTSERV could pick up the envelope MAIL FROM address in Return-Path:,
adding a very powerful (but still not infallible, given the variety of
non-conforming mailers in the world) heuristic.  This might even make
it robust enough to satisfy the requirement that Sender: be somebody
(something) smart enough to recognize error message and suppress loops.
 
If listmgr@ubvm is planning to set Sender: to a human address to conform
to a strict reading of RFC822, I would _strongly_ suggest that he use a
different human address for every list (e.g., WP50-E for Error handler,
WP50-O for Owner, CENTAM-M for manager, or the like).  That would be
more work for everybody, but it would allow automatic identification of
the list involved.
 
Mark R. Williamson, Rice University, Houston, TX; [log in to unmask]
-------------------------                         MARK@RICEVM1 on BITNET
Any opinions above are my own and not necessarily those of Rice University.