This is a discussion on RE: Text attachments with long lines breaking incorrectly - VMS ; I had the same problem once. The kind people at process pointed out rfc2822: 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 ...
I had the same problem once. The kind people at process pointed out
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 998 character limit is due to limitations in many implementations
which send, receive, or store Internet Message Format messages that
simply cannot handle more than 998 characters on a line. Receiving
implementations would do well to handle an arbitrarily large number
of characters in a line for robustness sake. However, there are so
many implementations which (in compliance with the transport
requirements of [RFC2821]) do not accept messages containing more
than 1000 character including the CR and LF per line, it is important
for implementations not to create such messages.
The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [RFC2821] if they actually cause
information to be lost). Again, even though this limitation is put on
messages, it is encumbant upon implementations which display messages
Not sure of the slight variances you are seeing but I'm sure they could be
explained by someone more knowledgable than me. In my case I told the
developers to keep it under this limit or don't use email.
From: Ed Withers [mailto:WITHERS@src.org]
Sent: Tuesday, October 26, 2004 4:30 PM
Cc: email@example.com; WITHERS@src.org
Subject: Text attachments with long lines breaking incorrectly
I have a user that is trying to e-mail a text file with long records.
actually, it is a comma-separated values (.csv) file with long (>1024 char)
records. The problem is that the records are broken into multiple lines
and thus break the spreadsheet.
It appears that the record is broken at 1022 characters during the
encoding, but that depending on the tool used to read the mail, the record
also be truncated to 1000 characters. I'm basing this on sending a message
my VMS MAILbox and my Exchange mailbox. When I extract the copy with PMDF
MAIL and edit it, the record appears to break at 1022 characters, lose a
character, and then continue on the next line. When I extract the same
attachment using Outlook and edit it with a text editor (Notepad, TextPad,
Word) the first record ends at 1000 characters, then the next line is the
content starting at character 1024 just as seen in PMDF MAIL. This looks
the line was broken at 1022 characters and then truncated to 1000.
The user is using the VMS command PMDF SEND and has tried all the
combinations of /mode=block or /mode=record and /encoding=base64 and
/encoding=quoted_printable. (/Mode=text fails with
"Some input files are not accessible; send anyway [N]?" )
The following is the result of sending from the command line and reading
the mail in PMDF MAIL, then extracting the file with the EXTRACT command:
When sending with /mode=record, the resulting file runs all the records
together (no CR or CR-LF between records) and all records are 1022
characters. When sending with /mode=block each new record starts on its own
line, but those records greater than 1022 characters are broken into
lines and one character is lost at each new break. Changing the /encoding
doesn't seem to make any difference to the behavior.
So, what am I doing wrong? Is there a magic set of qualifiers I need to
include to handle long records, or are we forced to zip the file before
sending it? Any help would be greatly appreciated.
Ed Withers, Manager, Information Technologies
Semiconductor Research Corporation