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