home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / vmsnet / mail / mx / 1219 < prev    next >
Encoding:
Text File  |  1993-01-01  |  1.3 KB  |  33 lines
  1. Newsgroups: vmsnet.mail.mx
  2. Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
  3. From: eric@sejnet.sunet.se (Eric Thomas)
  4. Subject: Re: Something is stripping blanks....
  5. Message-ID: <1993Jan1.102312.1@sejnet.sunet.se>
  6. Lines: 20
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References: <1992Dec24.082048.1098@dmc.com> <1992Dec29.183421.22777@news.arc.nasa.gov>
  11. Date: Fri, 1 Jan 1993 10:23:12 GMT
  12.  
  13. In article <1992Dec29.183421.22777@news.arc.nasa.gov>, madison@tgv.com (Matt Madison) writes:
  14. > Yes, MX trims trailing blanks.  It does this for two reasons.
  15. > 
  16. >     1.  You have to trim blanks on messages coming in from BITNET.
  17. >         The typical message format there is fixed-length 80-byte records.
  18. > 
  19. >     2.  It saves space on disk.
  20. > 
  21. > The BITNET problem should probably be handled by doing the blank-trimming in
  22. > the MX-Jnet interface ONLY.
  23.  
  24. And only if the message came in in PUNCH format. Within a few months most of
  25. BITNET (in terms of amount of generated messages, rather than amount of
  26. machines) should be running NETDATA-capable mailers, and there you don't want
  27. to strip spaces. I realize that the JNET interface probably isn't told what
  28. format the file came in, but if the blank line separating the header from the
  29. body is exactly 80 bytes long you can be fairly sure the message was sent in
  30. PUNCH format.
  31.  
  32.   Eric
  33.