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