Editing 8-bit clean (section)

==SMTP and NNTP 8-bit cleanness==
Historically, various media were used to transfer messages, some of them only supporting 7-bit data, so an 8-bit message had high chances to be [[mojibake|garbled]] during transmission in the 20th century. But some implementations really did not care about formal discouraging of 8-bit data and allowed high bit set bytes to pass through. Such implementations are said to be 8-bit clean. In general, a communications protocol is said to be 8-bit clean if it correctly passes through the high bit of each byte in the communication process.

Many early [[communications protocol]] standards, such as {{IETF RFC|780|788|821|2821|5321}} (for [[SMTP]]), {{IETF RFC|977}} (for [[NNTP]]) and {{IETF RFC|1056|leadout=and}}, were designed to work over such "7-bit" communication links. They specifically require the use of ASCII character set "transmitted as an 8-bit byte with the high-order bit cleared to zero" and some of these<ref>{{IETF RFC|780}}: Appendix&nbsp;A, {{IETF RFC|788}}: 4.5.2., {{IETF RFC|821}}: Appendix&nbsp;B, {{IETF RFC|1056}}: 4.</ref> explicitly restrict ''all'' data to 7-bit characters.

For the first few decades of email networks (1971 to the early 1990s), most email messages were [[plain text]] in the 7-bit US-ASCII character set.<ref> John Beck. [http://www.sendmail.com/sm/open_source/docs/email_explained/ "Email Explained"]. 2011.</ref>

The {{IETF RFC|788}} definition of SMTP, like its predecessor {{IETF RFC|780}}, limits Internet Mail to lines (1000 characters or less) of 7-bit US-ASCII characters.<ref>{{cite RFC
 |         rfc = 788
 |       title = SIMPLE MAIL TRANSFER PROTOCOL
 | sectionname = 4.5.3. SIZES
 |       quote = The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency).
 |        date = November 1981
 |      author = Jonathan B. Postel
 }}
</ref><ref>{{cite RFC
 |         rfc = 1428
 |       title = Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
 |      author = G. Vaudreuil
 |        date = February 1993
 | sectionname = 2. The Problem
 |       quote = SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII characters.
 }}
</ref><ref> Dan Sugalski. [http://www.foo.be/docs/tpj/issues/vol4_2/tpj0402-0010.html "E-mail with Attachments"]. "The Perl Journal". Summer 1999. "When mail was standardized way back in 1982 with RFC822, ... The only limits placed on the body were the character set (7-bit ASCII) and the maximum line length (1000 characters)."</ref><ref name="RFC2045" />

Later, the format of email messages was redefined in order to support messages that are not entirely US-ASCII text (text messages in character sets other than US-ASCII, and non-text messages, such as audio and images).<ref name="RFC2045">{{cite RFC
 |         rfc = 2045
 |       title = Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
 |     author1 = N. Freed
 |     author2 = N. Borenstein
 |        date = November 1996
 | sectionname = Abstract
 | quote = Multipurpose Internet Mail Extensions, or [[MIME]], redefines the format of messages
 }}
</ref> The header field Content-Transfer-Encoding=binary{{efn|The header field Content-Transfer-Encoding{{=}}8BIT does not designate 8-bit clean, since [[CRLF]] has special significance.}} requires an 8-bit clean transport.

{{IETF RFC|3977}}<ref>{{cite IETF
 |     rfc = 3977
 |   title = Network News Transfer Protocol (NNTP)
 |    date = October 2006
 |  author = C. Feather
 }}
</ref> specifies that "NNTP operates over any reliable bi-directional 8-bit-wide data stream channel", and changes the character set for commands to UTF-8. However, {{IETF RFC|5536}}<ref>{{cite IETF
 |     rfc = 5536
 |   title = Netnews Article Format
 |    date = November 2009
 | author1 = C. Lindsey
 | author2 = D. Kohn
 |  editor = K. Murchison
}}
</ref> still limits the character set to ASCII, including {{IETF RFC|2047}}<ref>{{cite RFC
 |     rfc = 2047
 |   title = MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
 |    date = November 1996
 |  author = K. Moore
 }}
</ref> and {{IETF RFC|2231}}<ref>{{cite IETF 
 |     rfc = 2231
 |   title = MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
 |    date = November 1997
 | author1 = N. Freed
 | author2 = K. Moore
}}
</ref> MIME encoding of non-ASCII data.

The Internet community generally adds features by ''extension'', allowing communication in both directions between upgraded machines and not-yet-upgraded machines, rather than declaring formerly standards-compliant legacy software to be "broken" and insisting that all software worldwide be upgraded to the latest standard. The recommended way to take advantage of 8-bit-clean links between machines is to use the ESMTP ({{IETF RFC|1869}}) [[8BITMIME]] extension<ref>{{Cite web|url=http://www.imc.org/ietf-smtp/old-archive/msg02018.html|title=8-bit transmission in NNTP|author=Theodore Ts'o|author-link=Theodore Ts'o|author2=Keith Moore|author2-link=Keith Moore|author3=Mark Crispin|author3-link=Mark Crispin|work=[[IETF]]-SMTP mail list|date=12 September 1994|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120320233721/http://www.imc.org/ietf-smtp/old-archive/msg02018.html|archive-date=20 March 2012|url-status=dead|df=dmy-all}}</ref><ref>{{Cite web|url=http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|title=comp.mail.mime FAQ, part 3 'What's ESMTP, and how does it affect MIME?'|work=[[Usenet]] FAQs|date=8 August 1997|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120118070711/http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|archive-date=18 January 2012|url-status=dead|df=dmy-all}} </ref> for message bodies and the SMTP [[SMTPUTF8]]<ref>{{cite IETF|
 |     rfc = 8531
 |   title = SMTP Extension for Internationalized Email
 |    date = February 2012
 | author1 = J. Yao
 | author2 = W. Mao
}}
</ref> extension for message headers. Despite this, some [[mail transfer agent]]s, notably [[Exim]] and [[qmail]], relay mail to servers that do not advertise 8BITMIME without performing the conversion to 7-bit MIME (typically [[quoted-printable]], "Q-P conversion") required by {{IETF RFC|6152}}. This "just-send-8" attitude does not, in fact, cause problems in practice because virtually all modern email servers are 8-bit clean.<ref>{{cite web|url=http://cr.yp.to/smtp/8bitmime.html|title=The 8BITMIME extension}}</ref>