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

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 9107
  • Last Modified:

Maximum length of "subject line" and body of an email

We need to store the content of incoming emails in
our database.

For determining the proper column lengths we need
to know how many characters a subject line and the
body of an email can contain (maximum values).

In RFC 821/822 I did not find a specification for that.
  • 5
1 Solution
Subject line, I don't recall we had to expand ours, tho'. Might be best to go as near 255 as you are comfortable. Many cases the line is truncated before recipient sees it anyway.

For text, It seems to go on forever. At least one client (Lotus) and one server truncate inconsistently around 64 KB. Best IMO is either go with known limits, if internal EM, or to allow it to be open-ended, if open to the world.

I also think your rfc references are old (<1000) and without looking I'd guess they've been superceded by now (with minor changes for modern world).
fwiw, we had to also expand the field for sender. THey are now being inhuman, long unique numbers to refect the recipients, for list maintenance.
Beware, that eMail itself can fall under a variety of protocols. That said,

822 has no such limit, the way I read it, it is not geared for filesytems or databases, but for terminal I/O. It does not use character counters (as you seek) or fixed or max length, but pre-agreed-to terminators (effectively infinite, in and of itself, fo your context); sample quote:


        Each header field may be represented on exactly one line  con-
        sisting  of the name of the field and its body, and terminated
        by a CRLF; this is what the parser sees.  For readability, the
        field-body  portion of long header fields may be "folded" onto
        multiple lines of the actual field.  "Long" is commonly inter-
        preted  to  mean greater than 65 or 72 characters.  The former
        length serves as a limit, when the message is to be viewed  on
        most  simple terminals which use simple display software; how-
        ever, the limit is not imposed by this standard.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

821 gives similar answer, and calls for 7-bit ascii:
"         Without some provision for data transparency the character
         sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
         by the user.

"The mail data may contain any of the 128 ASCII characters."

"The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency)."

The intent is that the message is not terminated through other than keyboard sequence, thus under user's discretionary control. Friendly. For RFCs, the 'C' is for Comment, not rule, they are more guidelines agreed to than fixed rules enforced by a big-brother. Since messages were typed, sizes were constrained by users getting tired of typing. This was prior to modern methods of pasting in files like Excel spreadsheets into the middle of a message. Internet was using FTP to move files around at the time, then permitted them to be attached (not embedded, as many in this topic area attempt).
About a year ago 821 & 822 were (Y2K) superceded by 2821 & 2822, FYI if a glutton for details. Sample 2822:

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

Note that for database purposes, one can define field as 'line' with multiple occurences.

Subject line is not structured, as such it falls under 2.2.1:

"2.2.1. Unstructured Header Field Bodies

   Some field bodies in this standard are defined simply as
   "unstructured" (which is specified below as any US-ASCII characters,
   except for CR and LF) with no further restrictions.  These are
   referred to as unstructured field bodies.  Semantically, unstructured
   field bodies are simply to be treated as a single line of characters
   with no further processing (except for header "folding" and
   "unfolding" as described in section 2.2.3).

(you already have the quote on what is constraint for a single line)
Hello Lewis

this question is open for more then 2 months
time to clean up
if not stated otherwise

my recom will be
-points to SunBow
-this will be finalized by an EE Moderator
-with no further update (09.11.2002)


posted by ToolzEE v1.0
Question has been closed as per recommendation

JGould-EE Moderator

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

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