Re: [ietf-smtp] Stray <LF> in the middle of messages
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
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
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
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
-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
-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
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
//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
ietf-smtp mailing list