Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1904
  • Last Modified:

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?
0
wyogirl77
Asked:
wyogirl77
  • 2
1 Solution
 
BarthaxCommented:
RFC 2822 is your baby:

"2.1.1. Line Length Limits

   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."

http://www.faqs.org/rfcs/rfc2822.html
0
 
RanjeetRainCommented:
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.
0
 
BarthaxCommented:
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).
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now