🚀 go-pugleaf

Dick Munroe (munroe@dmc.com) wrote:
: I've performed a series of experiments and something is
: stripping blanks from mail messages:

: 1. Sent a message containing:

: aaaaaaaaaaa
:            
: bbbbbbbbbbb

: to myself via UUCP%"munroe@dmc.com"

: The "blank" line had been filled with spaces.

: 2. Checked the spool file, it had spaces in it.

: 3. Checked the copy self copy delivered by mail.  IT had spaces
: in it.

: 4. When UUCP/MX delivered the mail, the spaces were gone.

: So a few questions:

: (1) is my experiment bogus?

	No it is not.

: (2) Does DECUS UUCP (or MX, since that's REALLY the entity that
: had the message last) strip blanks?

	It is MX that is doing the stripping.

: (3) Is this behavior legal?

	I don't think so.

: (4) Should it be stopped?

	I had mentioned it to Hunter after I found it.  You can see it also if
you are running MX and not UUCP.  I noticed it with a mail message send via
SMTP and delivered with the traling blanks removed from each line.


-- 
Earle Ake  Internet: <ake@dayton.saic.com>  NSI-DECnet (SPAN): 28276::ake

Yes, MX trims trailing blanks.  It does this for two reasons.

    1.  You have to trim blanks on messages coming in from BITNET.
        The typical message format there is fixed-length 80-byte records.

    2.  It saves space on disk.

The BITNET problem should probably be handled by doing the blank-trimming in
the MX-Jnet interface ONLY.  And saving disk space is probably not as
important as retaining message integrity.  It typically isn't harmful,
though.

You should not expect trailing blanks to be retained on any message you
send, however, in case it has to pass through a network and/or system
that does blank-trimming.

-Matt
--
Matthew Madison | madison@tgv.com    | +1 408 427 4366
TGV, Inc.       | 603 Mission Street | Santa Cruz, CA 95060 USA

In article <1992Dec24.082048.1098@dmc.com>, munroe@dmc.com (Dick Munroe) writes:
> I've performed a series of experiments and something is
> stripping blanks from mail messages:

Well, it was indeed MX, as Earle pointed out.  Specifically it appears to be
MX_RMAIL.  The fix was pretty easy and for those of you with sources the DIFF
to MX_RMAIL.B32 is enclosed.  I've mailed this to Hunter for inclusion in the
next release of MX.

Merry Holidays all.

Dick Munroe
--------------------------------------------------------------------------------
*** mx_rmail.b32.1
--- mx_rmail.b32
**************
*** 1,5
  %TITLE 'MX_RMAIL'
! MODULE MX_RMAIL (IDENT='V1.4-1', MAIN=MX_RMAIL) =
  BEGIN
  !++
  ! FACILITY: 	    MX UUCP interface
--- 1,5 -----
  %TITLE 'MX_RMAIL'
! MODULE MX_RMAIL (IDENT='V1.5', MAIN=MX_RMAIL) =
  BEGIN
  !++
  ! FACILITY: 	    MX UUCP interface
**************
*** 34,39
  !   20-MAY-1991	V1.3-1	Madison	    Check for 822-type address in From_ header.
  !   04-NOV-1991	V1.4	Madison	    Use new RCPTDEF structure.
  !   15-NOV-1991	V1.4-1	Madison	    MEM RCPT rtns.
  !--
  
      LIBRARY 'SYS$LIBRARY:STARLET';
--- 34,41 -----
  !   20-MAY-1991	V1.3-1	Madison	    Check for 822-type address in From_ header.
  !   04-NOV-1991	V1.4	Madison	    Use new RCPTDEF structure.
  !   15-NOV-1991	V1.4-1	Madison	    MEM RCPT rtns.
+ !   27-Dec-1992 V1.5	Munroe	    Do NOT trim blanks from the message when it
+ !				    is put into the message queue!!!
  !--
  
      LIBRARY 'SYS$LIBRARY:STARLET';
**************
*** 373,378
      ELSE
      	STR$COPY_DX (SENDER, %ASCID'<>');
  
      FLQ_ADD (.QAB, NEWENT);
  
      WRITE_INFO (.QAB, NEWENT, %ASCID'SRC_INFO', SENDER, INFOQ,
--- 375,384 -----
      ELSE
      	STR$COPY_DX (SENDER, %ASCID'<>');
  
+     !++
+     ! Add the UUCP message to the router queue.
+     !--
+     
      FLQ_ADD (.QAB, NEWENT);
  
      WRITE_INFO (.QAB, NEWENT, %ASCID'SRC_INFO', SENDER, INFOQ,
**************
*** 390,398
      END;
      WHILE MDM_READF (.UNIT, STR2) DO
      BEGIN
!     	STR$TRIM (STR, STR2);
!     	MDM_WRITEF (.UNIT2, STR);
!     	NEWENT [QENT_L_SIZE] = .NEWENT [QENT_L_SIZE] + .STR [DSC$W_LENGTH];
      END;
      MDM_CLOSEF (.UNIT);
      MDM_CLOSEF (.UNIT2);
--- 396,403 -----
      END;
      WHILE MDM_READF (.UNIT, STR2) DO
      BEGIN
!     	MDM_WRITEF (.UNIT2, STR2);
!     	NEWENT [QENT_L_SIZE] = .NEWENT [QENT_L_SIZE] + .STR2 [DSC$W_LENGTH];
      END;
      MDM_CLOSEF (.UNIT);
      MDM_CLOSEF (.UNIT2);
--------------------------------------------------------------------------------
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma.				FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.

In article <1992Dec29.183421.22777@news.arc.nasa.gov>, madison@tgv.com (Matt Madison) writes:
> Yes, MX trims trailing blanks.  It does this for two reasons.
> 
>     1.  You have to trim blanks on messages coming in from BITNET.
>         The typical message format there is fixed-length 80-byte records.
> 
>     2.  It saves space on disk.
> 
> The BITNET problem should probably be handled by doing the blank-trimming in
> the MX-Jnet interface ONLY.

And only if the message came in in PUNCH format. Within a few months most of
BITNET (in terms of amount of generated messages, rather than amount of
machines) should be running NETDATA-capable mailers, and there you don't want
to strip spaces. I realize that the JNET interface probably isn't told what
format the file came in, but if the blank line separating the header from the
body is exactly 80 bytes long you can be fairly sure the message was sent in
PUNCH format.

  Eric