>People in the X.400 world produce messages which contain more than 80
>columns and send it to users in EARN/BITNET for example [log in to unmask]
In that case it is not a problem, because when LISTSERV gets a file for
itself it will "RECEIVE" it (not using the IBM RECEIVE command but the
result is the same). It can do that because it knows the file is for
itself, and contains commands to be executed. If it is sent in a format
VM cannot handle, the file has intrinsically no value and can be
discarded. If the deck contains more than one file, it is difficult to
"define" what LISTSERV is supposed to do with it and this is rejected
with an error message.
The problem is when the X.400 people send it to a list, for instance
[log in to unmask] This arrives as a file, not mail, and it can be rejected
if the list is set not to accept files. If it is not rejected, LISTSERV
assumes this is not mail but a file which cannot be distributed via mail,
for instance an object file. This object file could be in VMSDUMP format
(which can only be RECEIVEd on a VAX), or it could be MVS object code
from a PDS packed into a NETDATA deck that can be processed only on TSO
because it contains N>2 files from a PDS, or whatever. Anyway LISTSERV
does not attempt to RECEIVE the file, but merely forwards it untouched to
the recipients of the list. Those who can handle NETDATA will see the
text, the others won't; finally, people subscribed with a domain address
which doesn't map to a BITNET nodeid (possibly because no :internet is
defined) get it in a mail envelope, and the resulting file can usually
not be PEEKed even after your remove the mail headers and repunch it to
yourself, either because of EBCDIC<->ASCII translation or because BSMTP
lost the character in column 80 because of a dot in column 1.
>I do not really know why those postmasters worldwide (except me) get
>those rejection messages and I do not know whether it helps to take away
>the ACK-option using SENDFILE.
It does not help to take away the ACK option: this is indeed desirable,
because then the end-users who receive the file do not send an
acknowledgement file to the gateway, but it does not solve this problem
because LISTSERV does not try to RECEIVE the file. The postmasters get a
nastygram because the DISTRIBUTE acknowledgements from LISTSERV to the
gateway cause an error message from the gateway to LISTSERV which is
eventually resent to the LISTSERV postmaster.
To conclude, the problem is purely metaphysical: is the data from the
X.400 people "mail" (ie text) or also "binaries"? If it is only mail, ie
something supposed to be read by a human user, NETDATA should not be used
because, when it is sent to a list, it may (1) be completely rejected
(and the X.400 user will not know, since the notification is sent to the
gateway userid) or (2) distributed in a form that many sites cannot read.
Instead, the gateway should wrap the lines to reduce the LRECL to 80,
which is what happens anyway on most terminals when the human user reads
the text. If binaries are sent in this way, a mechanism needs to be
introduced to let the user tell the gateway that "this is binary code, do
NOT wrap it".
Eric
|
