Actually I don't know any user agent that makes use of the TAG to
generate replies. This would be completely stupid since it would botch up
all internet replies and send an invalid file to the gateway. But there
are a lot (well probably 99%) of user interfaces that make use of either
the TAG, filename/distcode or 'Sender:' ('From:' if the latter was
omitted) to identify the *origin* of the mailfile, which is displayed in
the "list of things in your mailbox" menu. I don't know how you process
you mail, but I usually process all "junk" first (anything that comes
from a local server or suchlike), then distribution list mail, and then
mail from other people which usually require longer replies (ie more
time). If I'm busy and have little time, I only read personal mail and a
few ("important") distribution lists, keeping the rest for later. I can
do this because I know, by looking at the list of files in my mailbox,
what comes from what list and what is personal mail.
Thus if we change the 'Sender:' field, it must point to something that
uniquely identifies the list, and not to its owner or postmaster or
whatever. Another requirement is that this mailbox should be valid, and
that the list ownerS (note the plural) be able to read what falls into
it. Please keep in mind that the owner(s) are very, very seldom the local
LISTSERV postmaster. Your average postmaster is a systems programmer, a
busy man who sets up lists on his (backbone) site for other people to
maintain. He is NOT interested in delivery notices from the list, and has
NO time to check 50 local sender mailboxes. Your average list owner lives
on a different CPU than the postmaster, and can't therefore logon into
the dummy sender mailbox (to which the postmaster probably didn't want to
give any disk space or CPU credit).
The list owner must therefore be able to request that a copy of those
delivery notices be sent back to him, automatically. This means LISTSERV
must do it. It has all the required authorizations, but there are
security aspects: the list owner shouldn't be allowed to put just
anything into the 'Sender:' field, then ask LISTSERV for a copy of
everything in this mailbox "since it's the list's bit-bucket". Since the
list owner SHOULD be free to put anything into the 'Sender:' field (even
his boss's address if he's crazy enough), it means that he shouldn't be
allowed to ask LISTSERV for a copy of the contents of this mailbox unless
he has been properly authorized to do so.
The only sensible solution is this: create a MAIL-L list with a 'Sender:'
field pointing to 'MAIL-R'. Then, create a 'MAIL-R' list with a 'Sender:'
field pointing to, er, either the postmaster or the bit-bucket, and the
list owners as recipients (or more exactly, whatever is presently in the
"Errors-To=" list header keyword). Thus delivery notices get to the
owners automatically, and delivery**2 get to the bit-bucket (if any). Now
you have twice as many lists to create and maintain, and twice as much
overhead for LISTSERV (some commands are o(n), and the basic wakeup
process, which gets invoked for each command and reader files, is o(n)
too since it has to scan all the mailboxes for new stuff to process).
Well this is up to the postmaster in fact, after all HE creates the lists
and "pays" the CPU cycles. So the only problem is to find a name for the
sender list, a postmaster willing to create 2 lists for each distribution
list, and someone willing to process the user questions that will hail
down on his mailbox the very day the 'Sender:' field is updated :-)
By the way, it seems that the feature allowing the list owner to change
the sender field is not in the last version of LISTSERV I released. It's
one of the first changes I made to the code, and I forgot it hasn't yet
been released. Just c/are able to/will soon be able/ and you have it. I
could ship the updated modules to whatever site might be willing to try
this.
Eric
|
