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).
|
