Release 1.7e introduced support for messages with lines longer than 80 bytes - provided the local mailer also supports such messages (ie that it supports mail in Netdata format). But in order to reliably exploit this new feature, all major gateways and the entire DISTRIBUTE backbone need to be upgraded to support Netdata format. This message contains a status report, instructions for upgrading your mailer or gateway, and a new requirement for the DISTRIBUTE backbone which will take effect after the March table update. Gateways -------- The INTERBIT gateways will, in principle, be defined as Netdata-capable with the February table update. If you are running a local/national gateway registered in DOMAIN NAMES, it is your responsibility to declare its ability to process Netdata files in BITEARN NODES (all gateways based on IBM's SMTP code or on a VAX running JNET are Netdata-capable). If the gateway userid is the main mailer on your system, you would change your BITEARN NODES entry from: :node.SEARN :servers1.MAILER@SEARN(MAIL,PU,M,BSMTP,p_eric) to :node.SEARN :servers1.MAILER@SEARN(MAIL,ND PU,M,BSMTP,p_eric) If on the other hand the gateway is an additional server (typically a SMTP server), you would add a new tag to your entry with "OUTONLY", to indicate that this is not the main mailer for your node: :node.SEARN :servers2.SMTP@SEARN(MAIL,ND PU,M,OUTONLY,p_eric) If you are making changes to your mailer configuration and/or DOMAIN NAMES to redirect INTERBIT mail to your local SMTP, make sure that this mail is delivered in Netdata format. With LMail, the recommended method is to use the LSM$DNT exit rather than changing DOMAIN NAMES; make sure to use the NETDATA parameter. With the Crosswell/Wagner mailer, make sure to use the BSMTPN exit rather than BSMTP if you are post-processing MAILER PROFILE; if you are modifying DOMAIN NAMES, make sure the entries you are changing to point to your local SMTP have a ':mformat.ND PU' tag. LISTSERV servers ---------------- All LISTSERV servers on the backbone are now running 1.7e. Thus there is no risk of truncation by the LISTSERV servers themselves. Unfortunately, only about 20% of the backbone servers run a mailer that supports long lines. This means most of the messages with long lines will be truncated during delivery, which is not acceptable. For this reasons, servers on the DISTRIBUTE backbone will be required to run a Netdata capable mailer from the March table update. Warnings will be issued by the LISTSERV version monitor at SEARN starting in February. Note that this only applies to LISTSERV servers on the DISTRIBUTE backbone, ie servers with ':backbone.YES DISTRIBUTE(NO)' and LISTEARN servers are not affected. Netdata-capable mailers ----------------------- There are presently two Netdata-capable mailers for VM: Crosswell/Wagner (XMAILER) R2.10 or higher, and LMail. While only LISTSERV sites on the DISTRIBUTE backbone will be *required* to run one of these two mailers after the March update, all LISTSERV and LISTEARN sites are advised to migrate at their earliest convenience. The recommended mailer for LISTSERV is LMail, which provides additional functionality to LISTSERV when running version 1.7f or higher, or version 1.7e with development fix 17E-002D applied. LMail also requires about 3 times less CPU and 4 times less I/O operations than XMAILER R2.08. To order LMail, send mail to ERIC@SEARN from the userid of the person who will be in charge of maintaining it. If you prefer to implement the new requirement with XMAILER R2.10, you must also add the following line to LOCAL SYSVARS: NDMAIL = 1 You will not be fulfilling the requirement unless you add this statement, which tells LISTSERV that you are running a Netdata-capable mailer. For better safety, you should do it even if you are running LMail: if for any reason LMail is not logged on when LISTSERV is started, LISTSERV will not be able to query it and will assume a Punch-only mailer to avoid permanent loss of data. Conclusion ---------- The goal of all these changes and requirements is to make it possible for messages with lines longer than 80 characters (such as postscript files or source code) to be properly processed by BITNET mailing lists within about 2 months. An important side effect of these changes is that X.400 users with addresses longer than some 60-70 bytes will no longer be barred from using BITNET services by a bug in IBM's SMTP code (which IBM decided not to do anything about, because it is only present when using PUNCH format).