attachments is a formatted parameter which may specify any number of attachments:

MAP1 ATTACHMENTS

   MAP2 ATT’COUNT,B,2               ! # of attachments

   MAP2 ATTX(n)                     ! n >= value of ATT’COUNT

      MAP3 ATT’FILE,S,128           ! attachment filespec

      MAP3 ATT’CONTENT’TYPE,S,127   ! content’type string

      MAP3 ATT’ENCODING,B,1         ! See CTE’xx in EMAILX.DEF

If you are not using attachments, you can specify the attachments parameter as a null string (mapped or literal) for simplicity.

The size of the ATTX() array (n as shown above) is up to you, but must be at least as large as ATT’COUNT, which in turn must equal the number of items in the array (i.e. attachments) which are to be used. The maximum is currently 10 (i.e. up to 10 attachments allowed.)

The ATT’FILE() items must contain the name of the file to be attached in either AMOS or native format.

ATT’CONTENT’TYPE() is optional; if non-blank, it should be a legal MIME Content-Type header, for example:

Content-Type: application/octet-stream; name="xyz.doc"

You may omit the "Content-Type:" preface to the string, since if not present, it will automatically be added. You can also omit the name= field, in which case the name will be set to the actual name of the attachment (stripped of its directory.) If the entire string is blank, EMAILX will build one using "application/octet-stream" as the type.

ATT’ENCODING() indicates the MIME Content-Transfer-Encoding to be used. The default (0) is base64, which should work for all attachments because it delivers an exact copy of the attached file. The only downside is that the encoding increases the size of the mail message by about 34%.

Note that EMAILX will automatically perform the Base64 encoding for you; you just supply the name of the file.

The encoding types are defined as:

CTE’7BIT, CTE’8BIT, and CTE’BINARY are all similar in that they indicate that no encoding has been done to the attachment. Of these, the first two should only be used with text consisting of reasonably short delimited lines. CTE’BINARY indicates that the data is truly raw, possibly not fitting into the line length requirements of SMTP. Both CTE’8BIT and CTE’BINARY require that all of the MTA’s (Mail Transfer Agents) can handle 8 bit data, which is not necessarily guaranteed. (This is why CTE’BASE64 is preferred, since it encodes anything using a 7 bit character set.)

Also note that most mail readers will display 7bit text/plain attachments as if they were simply part of the message body rather than clearly separating them as attachments.

CTE’QUOTED indicates that the attachment is already in "quoted printable" format. This is a format that consists mostly of plain text, with an escape mechanism use to encode special characters. The advantage of this over Base64 is primarily that it is still somewhat readable even if the mail reader doesn’t understand the encoding. (Base64, on the other hand, is not human-readable at all.) However, by now, virtually all mail readers support Base 64, so we have not bothered to implement quoted printable encoding, other than to allow you to do your own encoding and then indicate that it has been done.

It is worth repeating that if you want to use quoted printable (CTE’QUOTED) encoding, you must do it yourself. EMAILX will only supply the proper header for you.

Refer to RFC 1521 for more details on attachments and MIME headers.