I'm sending this through LSTSRV-L@CLVM since the DEARN server is down and I want the US to get this this weekend. Regarding the STANFORD mail problem, this has been fixed in my test version as I said (you probably didn't get the mail until a long time had elapsed due to the links being down). The links have been down a long time here in France, and I found with delight that some of my PUT PEERS NAMES commands had been held at FRHEC11. I had thought I had individually updated those servers which needed individual update before sending the global PUT, but obviously this was not the case. Considering the number of problems that have been solved in 1.5g, I am going to distribute my 1.5g version as is, without the corresponding docs. I would have preferred to wait until the docs were ready but it seems that we need to synch out our versions ASAP. The DISTRIBUTE problem was due to the following facts: 1) There was an entry in the old PEERS NAMES file saying that BITNIC's server was NEWLIST not LISTSERV. If there had been no entry, this would not have been a problem, but there was an entry with a different userid and the servers thought that LISTSERV was Ricky's version. 2) Ibid. some sites have NOTIFY OFF in effect for [log in to unmask] *** PLEASE PLEASE PLEASE *** remove this thing ASAP, a lot of error mail is being suppressed (ie sent to /dev/null) because of that. 3) I had stupidly decided to protect 'old' servers (< 1.5d) of a security problem with DISTRIBUTE. A side effect of the corresponding code is that no entry in PEERS NAMES --> DISTRIBUTE disabled. A corollary is that no :version tag --> same effect. Another side effect is that server not found in PEERS NAMES --> invalid file origin, with the same corollary about the missing :version tag. To the best of my knowledge there are still 3 sites with an old version of LISTSERV. I am going to remove all this BS from the 1.5g code and if the aforesaid sites don't update their server, it's too bad, they may allow Joe users to add people to their lists. I don't think it's normal that 95% of people get in so much trouble because of 5% of people who don't update their code. Besides I can't keep maintaining a server which replies "Unknown command" when I tell it "RELEASE" to know its release number :-) Sorry if I sound so negative but it's really becoming a pain. 4) The CUNYVM entry was full of errors. It's partly the fault of the person who prepared it, and partly mine for not checking the entry before placing it online. There was no :version tag, there were a few typos, and the hardware machine was said to be a 3090-4 -- as I said earlier, this one did not cause any problem but confirms the fact that the entry was prepared in a hurry and was messed up. In 1.5g the processing will be slightly altered: - No entry in PEERS NAMES file: the server is assumed to be a 1.5f server instead of 1.4-. DISTRIBUTE jobs are never routed to this server of course (since it's not listed in PEERS NAMES), unless it's a PUT command. This may cause security problems for people running a release < 1.5b but as I said, I can't jeopardize the DISTRIBUTE command just because of 2-3 servers. However, DISTRIBUTE jobs from such a server are accepted PROVIDED that the userid of the server is LISTSERV. If it's not LISTSERV, jobs will be rejected until the entry appears in PEERS NAMES, for obvious security reasons. - Missing :version tag: same as above, except that since the server does appear in PEERS NAMES it will receive DISTRIBUTE jobs as if it had a ":version.1.5f" tag. That's the same fix as "no entry" above in fact. - :version tag indicating a release < 1.5: this means that the DISTRIBUTE feature is disabled at this node. Other servers won't send any job to such a server, and if one is received it will be rejected. However, jobs from this server will still be accepted (in case the local staff re-enable DISTRIBUTE) - I will make sure to check all entries before including them in the official PEERS NAMES file. I will also make sure to change my password to something else. I don't want to suppress the password display from the console log because (1) the command is displayed by higher-level routines BEFORE it is scanned, and (2) the password can be useful to diagnose problems. Now everybody knows that I like Rigoletto :-( ---> About this problem: I would like to ask ALL postmasters to send only those tags they have updated when they send me an updated PEERS NAMES entry for their sites. If you want to delete a tag, just send it back with no value, eg ":remark1.". This will make it much easier for me to check the thing. The PEERS NAMES should now be synched, except the SUVM one (they installed 1.5f and the NAMES file from the shipment overrode theirs). I had sent individual updates to those servers which needed it, except one which got held at FRHEC11, and then a global update "from the other side" (sent to LISTSERV@TAMVM1). This seems to have updated all the servers without problem, but I'd suggest waiting until 1.5g is installed to use DISTRIBUTE again. With the changes in the code it will probably become MUCH more stable. Eric