I've found and fixed two bugs in LSVBITFD since yesterday -- I knew I had better be careful about it... :-) I have improved LSVXMAIL to implement the type (1) headers we had discussed (--> SET listname FULLhdr/SHORThdr) and the "Mail-Via= DISTRIBUTE" keyword. I have completely rewritten the mail-sending routines and implemented an internal 'mail type' structure with presently three types: short header, full header, peer-format header. This makes it very easy to implement other types of headers in the future, eg type (2) headers (--> SET listname TRANSPhdr?). It also made it possible to have mail sent out to peers before the other recipients (but don't get too excited about that, peer-format = full header + inter-server tags so I seriously doubt it CAN reach its destination before short-header mail...) "Mail-Via= DISTRIBUTE" was not that easy to implement because of the various header formats. I had to make provisions to have one DISTRIBUTE job issue for each type of header for which there is at least one subscriber, and of course it does not optimize execution time. Mail is always sent to peers directly for better execution speed -- anyway they're supposed to be intelligently linked and I don't expect more than 2-3 peers per node. Valdis will be testing this feature on his UN*X-SRC list. I then did some performance analysis on LSVDIST. Amazingly, it spent more than 50% of its time obtaining the userid@nodes of all the servers... there are now 876 records in PEERS NAMES and EXECIO has always been an outrageously fast program -- not nearly as fast as NAMEFIND but it could almost compete with it ;-) LISTSERV will now build a file called PEERS NAMESUM whenever it receives a new copy of PEERS NAMES, and this info will be kept in storage and subsequently retrieved by LSVDIST. Execution time is now much more acceptable :-) Eric