There has been some interesting mail about this draft on the BITNET LISTSERV meta-list [log in to unmask] - some readers of the Unix LISTSERV mailing list may want to subscribe to the LSTSRV-L mailing list to follow the discussion. (The subscribe command is the same, but remember that you use SIGNOFF rather than unsubscribe when dealing with BITNET LISTSERV). I've made some files accessible via LISTSERV or FTP from cs.columbia.edu for anyone interested - you can get them as /listserv/archives/<filename>.Z or via [log in to unmask], using "get listserv <filename>". The files available are mailservers-00.draft the actual draft RFC mailserver-mail the messages on LSTSRV-L rfc1327 RFC for RFC822<->X.400(88)<->X.400(84) mappings rfc987 obsolete RFC822<->X.400(84) mappings rfc1026 corrections to RFC987 There is also another BITNET LISTSERV meta-list: [log in to unmask], but it seems to mostly have discussion of mail forgery at the moment. I haven't looked too closely at the Internet Draft by Houttuin/Cargille, but it would certainly apply to the Unix LISTSERV implementation . I don't have anything against using X.400 for the definition, as long as all the terms are explained in such a way that someone knowing only RFC822 can understand it, but a brief look at the draft wasn't very encouraging. The first sentence of the Requirements section (the meat of the proposal) is particularly opaque to anyone unfamiliar with X.400: 4. Requirements MBSs shall follow the requirements defined in X.411 and X.420 as a minimum. This document describes additional requirements in terms of P1, P3, and P2. There is no description of the requirements specified in X.411 and X.420, or what their implications for RFC-822 based systems are, and P1, P2 and P3 are never defined, although I get the idea that they represent various parts of the X.400 message - perhaps envelope, header, and body? What's more, the specification is in terms of the older X.400(84) standard, while the latest RFC for RFC-822 <-> X.400 mapping uses the newer X.400(88) standard as a baseline. If we have to write RFCs using X.400 terminology, let's at least be consistent. Finally, although the draft talks a lot about what kinds of things one should do with headers, there is no attempt to talk about what kinds of commands these mail-based-servers should support. The commands I'm talking about here are the ones which go in the body of a message, which is just about the only part of a message you can *really* trust not to get mangled after your message has gone through Compuserve, UUCP, BITNET (and who know, even X.400!). You don't want to overspecify this part, since the subscription request commands which a LISTSERV might support aren't relevant to a mail-based archie server, but there is a lot of overlap in the commands which the different mail-based servers, and annoying little differences (is the command to set the return address PATH, MAILPATH, or ADDRESS?). And please don't say "just put the return address in the Reply-To: header (or P2.ReplyTo field)" since there are many many people out there who use mail systems which mangle even that field (or which can't generate it at all). At the very least, there should be some words to the effect that body lines which look like headers (first word ends in a ":") should be ignored (there are some horrible mail systems which generate these atrocities and the poor user has no way to disable them), that all commands should be case insensitive, that the command HELP on a line by itself should send a message explaining how to use the service, etc. etc. It would be interesting (as an appendix, perhaps) to list the implementations of mail-based servers which are available, with some indication how far they are from implementing the standard. There are a number of ones with very similar functionality, ranging from BITNET to Unix LISTSERV, to the Internet and various other NIC's automated file servers, the mail<->ftp gateway programs, and even programs like archie. It would be useful to compare the command sets of these programs and look for common functionality. In any case, assessing the various implementations of mail-based servers which are already out there will be important for evaluating the practicality of the Requirements for Mail Based Servers RFC. @alex -- inet: [log in to unmask] Member of the League for Programming Freedom -- write to [log in to unmask]