[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] email standard maximum line length

On Thu, Apr 03, 2003 at 02:31:09PM -0800, Paul E Condon wrote:
| I am getting email from an old friend who is not a Debian type like
| me.  He types his email into a window on what he calls 'just a
| standard PC' and the computer automatically starts new lines on his
| screen when needed.

Not really -- it probably wraps the *display* but doesn't put any line
breaks in the data itself.  I've encountered a few (crappy) mail
programs that behave like this.

| His software is, in his words, 'just plain mail software, nothing
| special'.  Sometimes his emails are longer than a few dozen words,
| and when they exceed about one thousand characters of text, they are
| truncated. The last part of what he typed is simply missing from my
| copy. I suppose that there is a line buffer somewhere in the chain
| of delivery that is 1000 or 1024 bytes long. 


| I am curious about where in the chain of delivery the truncation might
| be happening. Is there a standard for email that specifies a line
| buffer size?

RFC 821, 822, 2821, 2822.

821 specifies SMTP -- the protocol used to transfer mail from one
machine to another.  2821 updates some stuff in 821.

822 specifies the format of the messages themselves, and likewise 2822
is the new version of it.

Here are the relevant snippets :

    RFC 821, section 4.5.3 :

         text line

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

    RFC 2821, section 4.5.3 :
       text line
          The maximum total length of a text line including the <CRLF>
          is 1000 characters (not counting the leading dot duplicated
          for transparency).  This number may be increased by the use
          of SMTP Service Extensions.

       message content
          The maximum total length of a message content (including any
          message headers as well as the message body) MUST BE at
          least 64K octets.  Since the introduction of Internet
          standards for multimedia mail [12], message lengths on the
          Internet have grown dramatically, and message size
          restrictions should be avoided if at all possible.  SMTP
          server systems that must impose restrictions SHOULD
          implement the "SIZE" service extension [18], and SMTP client
          systems that will send large messages SHOULD utilize it when

    RFC 2822, section 2.1.1

        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.

| My software is fetchmail and mutt. I have already established that the
| truncation is not happening in mutt, because I see it in
| /var/mail/pecondon .  I haven't yet figured out how I might check on
| fetchmail. I don't have access to the internals of my ISP.

Mutt, fetchmail (AFAIK), postfix, exim and sendmail all behave
correctly.  PMDF (an old commercial and crappy MTA used by my school)
can't handle long lines and merely truncates them.

| I'm working on getting him to press carriage return from time to time
| as he types, but he is somewhat set in his ways.

He either needs to make shorter paragraphs (by pressing return) or get decent

(Users aren't *supposed* to need to know about those line limits.
The software is *supposed* to handle that transparently.  If the MUA
encodes the line endings using the quoted-printable format then it
doesn't even change the contents of the message)


There is not a righteous man on earth
    who does what is right and never sins.
        Ecclesiastes 7:20

Attachment: pgpw4Ms7sXN5R.pgp
Description: PGP signature

Reply to: