| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 506.1 | Wrong Conference | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Apr 22 1997 11:13 | 10 |
|
Present versions of Mail all have hardcoded assumptions around
the longest record length that can be supported. Any future
modifications to Mail will require contact via a product manager,
and/or IPMT requests from customers.
The mail notes conference is VMSZOO::VMSMAIL.
The POP3 conference is LASSIE::UCX.
|
| 506.2 | | AUSS::GARSON | DECcharity Program Office | Tue Apr 22 1997 19:54 | 20 |
| re .0
What kind of file is the customer attempting to send?
What is the sender?
While a 255 char limit is probably not ideal design, various encodings
(such as UUENCODE) specifically limit the line length. I suppose this
is an indication that in the UNIX world one should not make the
assumption that any particular mail system supports longish lines.
If you are using a mail client that is MIME aware then encoding the
file before sending may workaround the problem transparently (to the
receiver). One could additionally argue (somewhat dubiously) that the
sender should automatically encode a file with "long" lines - thus
making it transparent to the sender as well.
Since you mention POP I would ASSuME that SEND/FOREIGN is not a viable
workaround.
HTH
|
| 506.3 | | HANSBC::BACHNER | Mouse not found. Click OK to continue | Thu Apr 24 1997 06:50 | 11 |
| The customer is trying to *receive* files - probably from a PC environment. The
customer is a university which frequently exchanges source files, and many of
the incoming files apparently have lines longer than 255 characters.
I've tried to reproduce this but all the mail clients I used don't make long
lines from source code.
I'll suggest that he contacts his partners to use a different mail format.
Thanks for the info,
Hans.
|
| 506.4 | VMS Mail May Not Be Culprit -- More Info Needed | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Apr 24 1997 10:22 | 16 |
| re: Note 506.3 by HANSBC::BACHNER
:The customer is trying to *receive* files - probably from a PC environment.
How is the mail arriving at OpenVMS? Directly via SMTP, or via a
SMTP-to-Mail11 gateway? If the former, check with UCX. If the
latter, find out which gateway software is in use.
:The customer is a university which frequently exchanges source files, and
:many of the incoming files apparently have lines longer than 255 characters.
One often uses zip/unzip and uuencode/uudecode when transfering files
among various clients. I've seen more than a few PC clients that do
not insert end-of-line characters, and this causes no end of problems
for the OpenVMS MAIL tool.
|
| 506.5 | | AUSS::GARSON | DECcharity Program Office | Sun Apr 27 1997 20:07 | 9 |
| re .3
Perhaps look at file sharing rather than mail as the means of
exchanging files. (PATHWORKS, LANmanager)
P.S. Source files with lines longer than 255 is poor practice. Is this
really the case or is something else at work? That is, have you
examined the source file on the PC and confirmed that it really has
such long lines (and secondly confirmed that this is needed).
|
| 506.6 | Common PC "Design"... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Apr 28 1997 10:32 | 12 |
|
: P.S. Source files with lines longer than 255 is poor practice. Is this
: really the case or is something else at work? That is, have you
: examined the source file on the PC and confirmed that it really has
: such long lines (and secondly confirmed that this is needed).
Source files on PCs with linese longer than 255 are fairly common.
Most PC text display packages seem to implicitly wrap the lines, and
this can make text file formatting a "joy" -- when combined with FTP,
one often ends up with long lines and (once manually reset) stream-LF
format files.
|