The idea of a 'storeheader' command seems good to me; anyway, the main point for the include proposal is that is would allow a *separate* maintenance for the descriptive part, which could then be treated as a normal file and stored with a single operation at all the peer servers by a single coordinator. I.e, I find useful to be able to separate the parameter part from the description part. Perhaps both options could be implemented; another strategy would be to allow only selected filetypes for included files and have specific commands for those includings: for example, % DESCRIPTION could mean 'include here the description file (supposed to have a fileid of "listname DESCRIPT")', and % PARAMETER could mean 'include "listname PARMS"' or suchlike. The interpretation process definition could state that the DESCRIPT file would not contain keywords and the PARMS file would contain preferably only keywords, probably with some rule allowing 'blank' or 'override' keywords. This rises another important point: maintaining a large number of lists would be much easier if some part of the headers could be commoned -- note that in this case one cannot use the 'fixed fileid' rule. I'm thinking, for example, in the 60+ ARPA redistribution lists: we could define unique DESCRIPT files for each list, create a special ARPA FILELIST for them, correctly linked (and not necessaryly limited to the redistribution backbone), create also a ARPA HEADER or ARPA PARMS common file, and have each list defined simply by a title, possibly a 'reply-to' keyword, the local main postmaster, two includes and the local subscribers. A final point: it's often necessary to have the 'main' postmaster as the first owner, to be able to set Errors-To= Owner. Is it possible to duplicate owners? Jose Maria