Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the reason behind 76 characters being the length limit for MIME sections for Emails (RFC 2045)?

RFC 2045 defines the maxmimum line length for encoded data as 76. However, I cannot find any explanation as to why it is 76. Is this number entirely arbitrary, or is there some reasoning behind it?

like image 464
user616479 Avatar asked Feb 14 '11 16:02

user616479


3 Answers

RFC2822 is legacy standard of EMail. In section 2.1.1 of RFC2822, you can find reason as below: It also affects MIME.

There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.

The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages.

The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [RFC2821] if they actually cause
information to be lost). Again, even though this limitation is put on messages, it is encumbant upon implementations which display messages to handle an arbitrarily large number of characters in a line
(certainly at least up to the 998 character limit) for the sake of
robustness.

like image 149
appleleaf Avatar answered Oct 10 '22 16:10

appleleaf


Actually the original RFC 822 defines a limit at 72 characters and the culprit is a teletype, which was a standard output device with the early computers.

You can also "thank" teletype devices for the line terminator in emails (and Windows) being 2 characters, which are CR (Carriage Return) and LF (Line Feed).

It was essential to transmit this sequence at the end of each line in order for a teletype to move a caret to position 0 and advance paper one tick up.

By the time RFC 2822 obsoleted the original, nobody was using teletypes to render emails, so it was relaxed a bit in order to fit into a default TTY monitor device.

like image 5
Alexander Pogrebnyak Avatar answered Oct 10 '22 18:10

Alexander Pogrebnyak


The maximum line length of 80 including the terminating carriage return and line feed originates from the good old punch cards which contained up to 80 colums of holes.
Why 80? Because in any book, a line is rarely longer than 80 characters including spaces.
It implied a maximum line length of 80 including the terminating Carriage Return (which moved the carriage of the teletype or typing machine to the leftmost position) and Line Feed (which advanced the paper by one line).
Since Base64 is in multiples of 4 characters, we end up with a maximum of 76, not counting CR+LF.
Another example is the TLE (Two-Line Element set) which describes a satellite's orbit. It fits on just two punch cards.
Since CR (horizontal movement to the leftmost, maintaining the vertical position) and LF (vertical movement to next line, keeping the horizontal position as is) are two fully independent things, we still have both of them. The next line should start at the leftmost position, shouldn't it?
For printing in bold, a line was printed twice with only a CR between them, i.e. without advancing the paper. Therefore the standard sequence is CR first and then LF.
However, the good old mechanical typing machine usually did the LF first and then the CR.

like image 3
Henk Reints Avatar answered Oct 10 '22 16:10

Henk Reints