[Top] [All Lists]

Re: [ietf-smtp] Stray <LF> in the middle of messages

2020-06-11 08:03:19
Hi Keith,

On 6/10/2020 7:33 AM, Keith Moore wrote:
On 6/8/20 10:03 AM, Hector Santos wrote:

CRLF also may have had an advantage in that text files using that
representation could be sent directly to an ASCII terminal (like a
teletype or CRT) or printer without the need for translation.


My early software development career was working on teletypes, punch card machines, dumb, smarter, raster vs vector graphics capable terminals, printers, include lasers and plotters. I provided tools to make "life" easier for the corp, so I am well-verse with the input/output control designs.


My burned-out memory is fading, but here goes:

You are correct ASCII control codes (0 to 31) were used for text-based devices to control the movement of the printer head or the terminal cursor position. Graphical capable terminals also had own set, usually, ESCAPE sequence based, to control their CURSOR/HEAD.

The 80x25 screen dimension with the 80 columns, was an emulation of punch card machines. 8x8 pixel cells were used hence why early terminals in graphic mode were 640x400 pixels dimension, 80x8=640, 8x25=400. I believe the IBM terminals had different capabilities. I never programmed them.

With smarter graphical-capable terminals (switchable from raster vs vector graphics) allowed for 132 columns (in graphic mode) which was an extension for additional columns punch card emulation.

Programming Punch Card machines was basically mechanical for repeatability to reduce typing and auto push out the current and add the next card.

I have written ANSI/VT10x drivers/emulators, telecomm clients that worked with early hosting software. Over X.25, PCBOARD was among the first, if not the first, hosting app reprogrammed (upon my request) to support non-modem (RS232) profiles also called NULL modems to support EICON and X.25 with PAD (Packet Assembler/Disassembler) devices. They worked by waking up the host with a CR character or it raised the hardware carrier detection signal. PADs also had to be programmed to be in passthru mode and switched from software-based Flow Control to Hardware-based Flow Control. Otherwise binary file transfer would stop if there was a control S, ^S, characters in the payload that were not escaped.

In my early X.400 work, I worked a program ("Emailatator"), an MUA per se, to capture ASCII screen dumps of X.400 messages to print the messages for managers/engineers to read first thing in the morning with their coffee and donuts. People may recall when we used our office telephone as a data connection to some device (probably a PAD) that woke up the X.400 software. That is why I didn't recall what X.400 used for its EOL because the host displayed the email line by line. The screen capture software did not see control characters, just the rendered screen output. With CompuServe, an early Offline Mail Readers (MUA) called TapCIS used the same primitive screen capturing method. But on PCs, now the "Smarter" terminal now only with graphics, it has Memory and Storage now. When the backend host began to offer "add-on" backend hooks allowing Mail Packing software to be installed (on the backend) to allow a companion frontend apps (on the frontend, a MUA pe se) to pickup compressed mail packets, and also send back. Qmail Deluxe was the first to do this and Silver Xpress (my first commercial product) followed suit using the QWK and OPX mail format. Al Gore had yet to "invent the internet" but when he did, that was my first venture into the IETF when I added RFC822 support to the Silver Xpress MUA. The backend used UUCP/UUCICO as a store and forward mail gateway.

Today Wildcat! still supports VT10x/ANSI connection detection and emulations for the various text-based interfaces devices, example;


It will know if you are human using an ANSI/TERMINAL or an automated mail data transfer app. It also detected PPP, "mini-ppp" and the old RIP protocol (obsolete) which as an early competitor to HTML and of course, HTML won. The proprietary Mini-PPP used a similar PPP detection designed to interface with a graphical Frontend.

The text-based terminals and client software, all offered configurations add either just send the CR or CRLF with the enter key. So I think the OSes used CR or CRLF as a EOL for that reason or LF for *nix although I don't see why a human would type a LF as a terminator when it takes two key (^J) but then again, today, many online messaging/comment logic don't use the enter key to submit the text. Oh boy, many will be in trouble is the ENTER key was the EOL. But technically, LF does not move the cursor or "file position" to the beginning of the next line, so for storage, why did *nix use LF for its EOL?

When I worked with text and laser printers, such as HP, OkiData printers, one of my early programs which started on a VAX then moved to the PC, was my LPRINT program to print text files with first page user name banner similar to the batch job print outputs we use to get. I still have lprint:

lprint V3.00/32 - Laser print utility by SSI
usage: lprint [file spec] <file spec>...<file spec> <options>

       infile   - any text file
        -H produce header with file name, page #
        -D print current system date on header (-D promotes -H)
        -L landscape print -B bold print, -C condense
        -B bold print
        -C condense print
-X print preformatted files, like WORD. All other switches ignored.
        -PLxx set the page length
        -L6 set the 6 lines per inch (default, Auto sets PL to 55)
        -L8 set the 8 lines per inch. (Auto sets PL to 75
        -WW set word wrap on
        -TXxx expand tabs to XX blanks (default 8)
-Ooutfile (default is LPT1. Overwritten by environment PRN string)
        -GB (Generate Banner Page, default None)
        -V  verify file to print (Ask you Y/N to print file)
        -DG DG laser printer HP Mode

sample: LPRINT source.c *.h *.mak -h -d -c

Lprint will format your file for text/laser printing. A banner page will be
printed with your file name, your user name, and date. The user name is
defined by having a SET ID= environment string (or USERNAME). Lprint also
looks for SET PRN= environment string if the output file is not defined.
Within the text file itself, you may embed the following keywords in
column one:

      //PAGE or /*PAGE*/          :  force pagination of your print.
      //BOLD or /*BOLD*/          :  force bold print.
      //CONDENSE or /*CONDENSE*/  :  force condense print.
      //NORMAL  or /*NORMAL*/     :  force normal print.

I recall using the built-in (default) BIOS character set to get the 8x8 pixel cells per character and used that to do the large print banners of your name, i.e. HSANTOS, KMOORE, etc.

I also worked on FAX devices which used scan lines. It also used 8x8 cells, at least early ones as I recalled programming one.

Anyway, as you can see, I was well verse with all these earlier terminal/printer HEAD/CURSOR control design considerations.

I did not why with CRLF was used for RFC822 but as you said FTP was an early start into transferring "mail".

But I have always believed (presumed) when the dumb terminals were used to program and test the early text-based client/server protocols like FTP, POP3, SMTP, NNTP, etc the developers was hitting enter (CR) key. It was all the human had to naturally do to end the line and send it to there to the backend host. Either the terminal was send the CR or optionally CRLF. The backend could also echo back each character in full duplex mode including the CR and/or LF.

Microsoft Telnet has these two options:

o Local echo off
o Line feed mode - Causes return key to send CR

The line feed mode sends an CR because the backend (telnet server) is expected to echo back the LF. When the terminal is in Local Echo Off mode, it is expected of the backend will echo back all characters.

Ironically, Legacy applications still thrive! One my current projects is writing a cSharp (c#) SDK libraries for ANSI/VT100 and IBM Extended character emulation. 3rd party developers are writing C#-based applications are spawned by the Host to take over the COMM I/O with end users. Many of them are writing games or had some text/andi/vt100 service.


Hector Santos,

ietf-smtp mailing list