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.
Bingo.
| 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
possible.
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
software.
(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)
-D
--
There is not a righteous man on earth
who does what is right and never sins.
Ecclesiastes 7:20
http://dman.ddts.net/~dman/
pgp00000.pgp
Description: PGP signature
