Link to home
Start Free TrialLog in
Avatar of wyogirl77
wyogirl77

asked on

Line Length in an Email Message

I am trying to send out an HTML email without any line breaks in it and was wondering if there is a limit to the length of a line when sending through an SMTP server, is it 1024 characters, and if so can anyone point me to an RFC that covers this just so I can point it out to the higher ups?
ASKER CERTIFIED SOLUTION
Avatar of Barthax
Barthax
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of RanjeetRain
RanjeetRain

I would say it is a different ball game altogether. RFC 822 is for plain vanilla mails. It doesnt talk about line lengths etc at all. The consideration of like length is actually the worry of trasport protocols such as SMTP.

Sophistication was added when standards for SMTP protocol was developed and it was in the specification of SMTP that this line length limit was set. RFC for SMTP clearly states that:

"In particular, a significant portion of the Internet community wishes to
   exchange messages in which the content body consists of a MIME
   message [3] containing arbitrary octet-aligned material. This memo
   uses the mechanism described in [5] to define an extension to the
   SMTP service whereby such contents may be exchanged. Note that this
   extension does NOT eliminate the possibility of an SMTP server
   limiting line length; servers are free to implement this extension
   but nevertheless set a line length limit no lower than 1000 octets."

In the light of this line length limitation imposed by SMTP, mail clients needed a mechanism to transfer data longer in length than allowed as well as other content types such as embedded documents and attachments. To facilitate transfer of such data over a protocol like SMTP which restricted the length of each line that could be transferred, a way out was required. This requirement was fulfilled when the MIME extensions came into play. The RFC for MIME (RFC 1521) addresses the issue.

RFC 1521 suggest the use of CONTENT-TRANSFER and CONTENT-ENCODING headers. These headers put together specify how complex data such as embedded documents and attachment would be transferred over a transport protocol that was orginally developed for transferrring 7-bit ASCII data.

I recoomend you take a loook at RFC 1521 http://www.ietf.org/rfc/rfc0821.txt to understand this better. It would help further if you have the source of a few message in front of you while studying the RFC.
RFC 822 is the older version and has since been superceded by RFC 2822.  You have to think of RFCs as a time-line with the higher the number being the more recent.  RFC 1521 (MIME Part 1) and it's sibling RFCs 1522 are extensions on RFC 822 (along with others).  RFCs 1521 & 1522 have been superceded by RFCs 2045, 2046, 2047, 2048 and 2049.  RFC 2822 does it's best to hone the problems faced with non-conformant practices and solidify the possible components to fit the SMTP protocol.  Any message not conforming to RFC 2822 should consider itself binary in composition and thereby fall under the more recent RFC 3030 (which obsoletes RFC 1830): ftp://ftp.rfc-editor.org/in-notes/rfc3030.txt - SMTP Service Extensions for Transmission of Large and Binary MIME Messages.

To form an anology, the MIME protocols give protocol on how to create an envelope whereas RFC 2822 gives the protocol on what dimensions of envelope can fit through the letterbox of SMTP (RFC 2821).