vms mail attachement size

[Gérard Wendling]

Hello,

openvms alpha 7.3-1 : i would like to know what is the maximum attachement size in vms mail and if it is configurable.

Thank's in advance.
Gerard

[Hoff · Accepted solution]

I don't know that the OpenVMS MAIL utility particularly "cares" about this sort of thing (inside the limits of the user's disk quota and the disk storage capacity and the RMS file limits), but the intermediate SMTP servers involved with most mail traffic most certainly do care about this sort of thing, and to have limits here. Send a big message to OpenVMS and MAIL basically creates a gigantic disk file, and links to it via an entry in the user's MAIL.MAI file.

If you're interested, run some basic tests and report back. This should take ten or fifteen minutes of your time to test this in your particular environment, using MIME or SFF or otherwise to add an attachment and then toss it to your mail server.

If you're seeing a specific error, disconnection, dropped message or other untoward behavior, please consider identifying the configuration, the command(s) used, the (mis)behavior and any error(s) received.

The MIME tool has had its share of bugs in older releases, so do look to load the current ECO kit or (better) upgrade to an OpenVMS release more current than V7.3-1. SMTP, too, has had some bugs and a current ECO kit for TCP/IP Services (or whatever IP stack you're using) is appropriate; MIME stuff generally means IP, which means an IP stack and any number of intermediate pieces.

Stephen Hoffman
HoffmanLabs LLC

[Hein van den Heuvel]

Bonjour Gérard. Bienvenue.

VAXmail does not really do attachments.
Those are in the eyes of the Email content interpreters.
Short messages are stored as data in a single RMS, timestamped, record. Larger messages, ( more than 3 block (1536 bytes) or messages SEND/FOREING are stored as pointers to external files.
Interestingly, the VAXmail API provides the message size in RECORDS.

Internally it uses a LONGWORD bytes counter, so the max message is 2 Gigabytes ( or 4 if the code was written very carefully using unsigneds throughout ) that size is then further stored, and manipulated in BLOCKS (of 512 bytes).


fiw,
Hein.

[Gérard Wendling]

thank's to all for th quick answes.

I ll get some more details and come back...

[Gérard Wendling]

hello,

Here is the error message when sending large files:
%MAIL-E-SENDERR, error sending to user HUGUES.ROOS@MGEL.FR at LOCAL:.MGEL2
-MAIL-E-READERR, error reading $1$DGA1:[PROG.HUG]ENVOI.MIME
-RMS-W-RTB, 47213 byte record too large for user's buffer
%TCPIP-E-SMTP_ABORT, SMTP session aborted

look's like a user's quota no ?
Witch one could it be?

Thanks
Gerard

[Joseph Huber_1]

>> RMS-W-RTB, 47213 byte record too large for user's buffer

This error is not due to the size of the message, but means the record structure is bad.
Either the file header RFM lies: e.g. says it is RFM:STM but in fact is RFM:STMLF, so no line terminator is ever seen.

Do a DIR/FULL of the MIME file.

How was the MIME file constructed ? Imported from another system by which method ?

[Gérard Wendling]

Hello,
This is the way the mime file is created

$! P1 = Name of the attachment file

$! P2 = Destination address

$! P3 = Subject (facultatif)

$

$ define TCPIP$SMTP_FROM "informatique@mgel.fr"

$

$ OPEN/WRITE FILE MIME.COM

$ WRITE FILE "$ MIME :== $SYS$SYSTEM:MIME.EXE"

$ WRITE FILE "$ MIME"

$ WRITE FILE "NEW/NOEDIT ENVOI.MIME"

$ WRITE FILE "ADD ''P1'"

$ WRITE FILE "SAVE"

$ WRITE FILE "EXIT"

$ CLOSE FILE

$ @MIME

$ MAIL/SUBJECT="''P3'" ENVOI.MIME "''P2'"

$ DELETE ENVOI.MIME.*

$ DELETE MIME.COM.*




You mean a dir/full of the mime file or the attachement file?

Thank"s

[Joseph Huber_1]

>>
You mean a dir/full of the mime file or the attachement file?


I mean the MIME file, because that's the one where the "record too big" error happens, i.e.at mail input, not the result.

I wonder what happened to the MIME generated file, the result should be
Record format: Stream_LF

[Joseph Huber_1]

And control the file using TYPE:
it should be a text file with lines no longer than 80 bytes.
For Your problem file, type would get the same "record too big" error than mail.

[Hein van den Heuvel]

When VAXmail creates the extension/external files, it uses OpenVMS RMS record IO.
RMS records are limited to roughly 32KB (16 bits, exact number depends on file type).

Hein.

[Joseph Huber_1]

Just a suspicion:
The file to be Mime encoded is of 'binary' type ,
but You did not ADD/BINARY, and have no entry for the file extension in
SYS$COMMON:[SYSMGR]MIME$FILETYPES.DAT to force /BINARY encoding by the MIME utility ?

[Gérard Wendling]

Thank's for the quick answer..

here is the dir /full
Directory $1$DGA1:[PROG.HUG]



ENVOI.MIME;1 File ID: (74702,10,0)

Size: 8460/8494 Owner: [SYSTEM]
Created: 18-SEP-2009 09:19:29.79
Revised: 18-SEP-2009 09:19:30.46 (1)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 8494, Extend: 0, Global buffer count: 0
No version limit
Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RWED, World:RWE
Access Cntrl List: None
Client attributes: None

Total of 1 file, 8460/8494 blocks.



The type command show another error:

511 | MG000 | 999 | 090908 | 091001 | 100930 | 198410 | 2841002691055 |8

| 542 | PACK | 308 | 090817 | 090818 | 000000 | 198410 | 2841054304073 | 3 | B4

%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;

-RMS-F-SYS, QIO system service request failed

-SYSTEM-F-EXQUOTA, process quota exceeded


I don't find sys$manager:mime$filetypes.dat

[Hein van den Heuvel]

>> Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes

It's lying. That's a forced, incorrect value.

The real LRL is at least 47213 according to:

-RMS-W-RTB, 47213 byte record too large for user's buffer

>> The type command show another error:
%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

No duh! This is controlled by SYSGEN param MAXBUF.
Check with $ mcr sysgen show maxbuf
(the max is 64,000)

Hein.

[Joseph Huber_1]

The error with type just shows again that the file is not a correct mime file, because it must be only text, and must not have lines longer than 80 bytes.
It surely is not encoded in base64, but simply a copy of the binary input file, caused by the missing /BINARY in the ADD command.
Try it again with ADD/BINARY and the result will be correct.

>>
I don't find sys$manager:mime$filetypes.dat

I don't know if the MIME utility installation does produces a template or default file,
eventually get mine from

http://wwwvms.mppmu.mpg.de/vms$common/sysmgr/mime$filetypes.dat

Anyway, if the file does not exist, then You have to use ADD/BINARY explicitly in the mime utility.

[Gérard Wendling]

The ADD/BINARY solved the problem...

Nice to feel less alone in the Vms community.
Thank's to all

[Gérard Wendling]

hello,

Since we added the /BINARY in the file creation procedure, it seems the CR (carriege return) is no more recognized in the attachement file.
How can we correct this?

Thank's
Gérard

[Joseph Huber_1]

Several possible combination of reasons are possible:
The input file has in the header record type stream_lf, but is in fact stream_cr or stream:
Do a DIRECTORY/FULL on the input file.
Since You got the "record too big", I assume the record header is wrong. Use SET FILE/ATTRIBUTE=RFM:stmcr , stmlf, stm , whatever is the real format.

Then it depends on the receiving system, what kind of files it expects.
A unix type system expects line terminators, and will show the whole file as one long record if it is stream_cr.
A DOS/windows system expects line terminators, and needs an intelligent editor to handle it.

Assuming the file on VMS has the correct header attributes, maybe instead of ADD/BINARY,
ADD/CONTENT_TYPE="text/plain"
/ENCODING_TYPE="Quoted-Printable" may be the better choice.

So if the receiving file can't handle the input file, a conversion on VMS using the CONVERT command may be necessary before doing the mime encoding.

Command files doing the conversion can be seen at
http://wwwvms.mppmu.mpg.de/vms$common/com/
files:
CONVERT_TO_STM.COM
CONVERT_TO_STMCR.COM
CONVERT_TO_STMLF.COM

[John Gillings]

Gerard,

What you're seeing here is a clash between different file formats. OpenVMS supports several formats. For the most part, if you're accessing the files using RMS, on OpenVMS, the format is invisible and irrelevant. However, if you want to move a file to another OS, or fit it into an external standard, like MIME, you may need to do some conversions (sometimes RMS does this for you, sometimes it doesn't).

You need to work out exactly what you want the file to look like at the end of the process, then work backwards to figure out what steps are needed to get there. You may need to determine which bytes are "data" and which are "meta data" (ie: record formatting or delimiting). Sometimes, it's necessary to convert what OpenVMS sees as meta data into data for another system (and the general rule with this type of activity is that the OpenVMS system always does all the work ;-)

The command procedures referenced by Joseph will work, but for high enough versions of OpenVMS you can do them with a single command, since the /FDL qualifier for CONVERT now accepts an FDL string, as an alternative to an FDL filespec:

CONVERT_TO_STM.COM =
$ CONVERT/FDL="FILE;ORG SEQ;REC;CAR CAR;FORM STREAM" input output

CONVERT_TO_STMCR.COM =
$ CONVERT/FDL="FILE;ORG SEQ;REC;CAR CAR;FORM STREAM_CR" input output

CONVERT_TO_STMLF.COM =
$ CONVERT/FDL="FILE;ORG SEQ;CAR CAR;REC;FORM STREAM_LF" input output

[Gérard Wendling]

Thank you very much !

I "ll do some tests and come back.

Regards
Gerard