Re: lines, SMTP, ...
This part of the "protocol" is like the unwritten, but widely accepted
human protocols that call for speaking clearly so other can understand
what you want them to understand, or using visible ink in your writing
pen, or writing in a font that is large enough to see without a
microscope, etc, et al. No magic here, just a little common sense.
Actually, Stef didn't mention this, but some mail transport agents will
wrap lines over some number of characters (commonly as low as 120,
occasionally even 80). So if you CARE about how your lines are wrapped,
you should do it yourself before some "smart" mail transport program
does it for you.
Eudora (Macintosh) wraps them at the nearest word boundary <=76! Steve
Dorner insists this is necessary because some MTAs fail if handed a line
longer than 80 columns.
I have heard this assertion so often, I've taken it to be true. But I've
actually encountered such a beast --- maybe I've been lucky. But maybe
story is just a myth. Can anyone point to a MTA and tell me it fails if
you send it a string >=80?
Stef's argument about common sense brings to mind an interesting point. As
UAs increase in sophistication, the necessity to cling to the "glass tty"
model becomes decreasingly relevant. My mail to you (probably) looks funny
because of Eudora's ideosyncratic line breaks. But I never see it, because
Eudora replaces a single <crlf> with a space, giving me the freedom to
resize my window, modifying where line breaks fall. (Eudora treats
<crlf><crlf> as a paragraph mark, btw).
I disagreed with Steve's choice to wrap at 76, because I had a "glass tty"
perspective. But now I'm beginning to come around to his way of thinking.
What we're doing in RFC-XXXX changes the assumptions we can make about
viewing a message.
|Previous by Date:
||On encodings : random thoughts...., Alain FONTAINE (Postmaster - NAD)
|Next by Date:
||EBCDIC, uuencode, etc, John C Klensin
|Previous by Thread:
||Re: lines, SMTP, ..., Nathaniel Borenstein
|Next by Thread:
||Re: lines, SMTP, ..., David_Thompson%GN%7cg