I was going to send a piece of mail about the X-LSVOPTS tag but I decided to read all my LSTSRV-L mail before and saw that Jose had already done that. :-) So, when all servers have installed 1.5 the ACK option will be forwarded without any problem. Users can set it themselves with the SET command unless the list is Validate=All commands. The problems are: 1) Should NOACK mean no message at all, or just a single message? As I said I myself think NOACK should mean nothing at all, but some people think other- wise. I'll do what the majority wants. 2) Should "NOACK" be the default? Certainly not. The day I change the default value to NOACK, I'll get tons of letters suggesting a new feature to LIST- SERV allowing you to get a message (or possibly file, but I realize that this would need some time to implement) acknowledgement, because when the links are down, etc, etc. The default should be either ACK or MSGACK, and each user will have to learn how to change it. That's pedagogical and forces them to read the refcard. :-) 3) Should we use the Acknowledge-To: field? Not as it was mentioned; however it could be considered that when your distribution option is still "default", then if there is an Ack-To: field you get ACK effects while if there is no Ack-To:, you get NOACK plus one message from the first server telling you that you're not on the list and NOACK was assumed, or suchlike. This would also serve as a "your mail was received". The Ack-To: just cannot override the ack setting because it is only binary while there are three values for the ack setting. Nothing prevents you from adding a line saying "X-LSVOPTS: NOACK" in the mail header before sending. Good idea, I'll try it on this piece of mail and see what happens :-) LSVPUT: right, and I maimed the FINHUTC list because of that. Needless to say I have fixed it. Curse me. REView: agreed, with the restriction that if the list is confidential, you still get rejected (LIST LONG would not show it then). So if (not authorized to review) and (authorized to LIST) then (force the SHORT option). SET with validate=all: right, it would not really be a security problem provi ded I send mail back informing the sender of the change. However, this will cause complaints that "heck, I sent a command and then it sent me a piece of mail informing me of the command I sent!!! That's stupid!!!". Also this introdu ces an exception in the handling of the validate=all commands keyword, which I don't like too much. Comments? Eric