To make life easier for EARN users who were used to a similar feature in LISTEARN, version 1.8a introduces support for a new command line keyword, SPLIT=, which can be used when ordering files to request delivery as multi-part MIME messages with the specified maximum size (in kilobytes). Thus for instance you could GET BLAH.ZIP SPLIT=100 if you know your gateway only supports messages of 100k or less. LISTSERV will not accept to cut files into pieces of less than 20k each, mostly to avoid bad surprises if you forget a zero. To avoid confusion, it is important to note that SPLIT=nnn is not a delivery format like F=NETDATA or F=MIME/APPL, but an option that instructs LISTSERV to further cut the file in a number of smaller pieces before sending it to you, in addition to whatever else it had to do to encode the file and get it to you. One does not order files "in SPLIT format", and indeed 'GET SOME.ZIP F=SPLIT' is not valid. You both select a format and tell LISTSERV what the maximum message size for your gateway is (in most cases you will just type SPLIT=nnn and let LISTSERV use the default format, which is "plain mail"). The SPLIT=nnn option is valid only for mail delivery formats: UUENCODE, XXENCODE, MIME/TEXT, MIME/APPL and of course MAIL. You cannot use it with NJE formats such as F=NETDATA because it would make little sense to order a NETDATA deck in 6 pieces which have to be assembled using PUNCH (NOH in the right sequence before you can RECEIVE the file. At any rate BITNET accepts much larger messages and there is no need to split NJE files in segments of 100k in the first place. The MIME multipart format was chosen because it is straightforward and reasonably intuitive to a human reader: people without a MIME user interface are not being sacrificed to a "chosen few". I have attempted to decode the messages using an old copy of MH (V6.7) I installed about a year ago on a local unix box and it claims the message is not valid and/or the last part is missing. I on the other hand claim the last part is not missing and/and the message is valid, it just doesn't have the "total=" indicator on all segments, nor does it need to, nor am I going to make two passes through the file just to supply it. I would appreciate feedback on the ability of current versions of MIME user interfaces to handle the output of both 'GET PEERS NAMES F=MIME SPLIT=20' and 'GET PEERS NAMES SPLIT=20' (I have just installed the code on LISTSERV@SEARN). Eric