Attachments require the construction of MIME headers and usually the encoding of the attachment using "base64". Most people do not want to know anything about how that is accomplished, and would prefer to imagine that it is as simple as just listing the names of the attached files in the header of the message (an illusion happily fostered by most email client applications.) Fortunately, EMAILX is willing to go along with this charade, allowing you to specify nothing other the names of the files you want to attach.

Most email clients make assumptions about the types of file attachments based either on the extension of the filename, or possibly by scanning the file to see if consists of anything other than text. Rather than get mired in such hocus-pocus, EMAILX adopts a simpler approach. If you don’t tell it otherwise, it automatically treats each attachment as being of type "application/octet-stream" which is the most general type. If you want to be more specific, you can specify one of the content types defined in the email standard (see RFC 1521 and 1522), such as:

application/postscript

image/jpeg+

image/gif

audio/basic

video/mpeg

The following example uses the same configuration file (emailx.cfg) as in the previous example, and is otherwise very similar except for the inclusion of two attachments and the addition of a signature block:

EMSIG.TXT ----------------------------------------------------------

************************************************************

*************** EMAIL Field Research and Testing ***********

************************************************************

EMATT.BAS ----------------------------------------------------------

MAP1 EMAIL’PARAMS

   MAP2 EM’OPFLAGS,B,2

   MAP2 EM’TO,S,200

   MAP2 EM’CFGFILE,S,20,"EMAILX.CFG"

   MAP2 EM’FROM,S,50

   MAP2 EM’HEADER,S,1000

   MAP2 EM’BODY,S,1000

   MAP2 EM’ERRMSG,S,100

   MAP2 CRLF$,S,2

   MAP2 EM’STATUS,F

MAP1 EM’ATTACHMENTS

   MAP2 ATT’COUNT,B,2

   MAP2 ATTX(10)

      MAP3 ATT’FILE,S,128

      MAP3 ATT’CONTENT’TYPE,S,127

      MAP3 ATT’ENCODING,B,1

++INCLUDE EMAILX.DEF

EM’OPFLAGS = EMF_NORMAL

EM’TO = "test@microsabio.com"

CRLF$ = chr(13) + chr(10)

EM’HEADER = "To: Attachment Test Department" + CRLF$ &

+ "From: Field Research" + CRLF$ + "Subject: Testing Attachments"

EM’BODY = "There are two attachments to this message:" + CRLF$ + " EMAILX.SBX (binary) and miame.ini (text)" + CRLF$

ATT’COUNT = 2

ATT’FILE(1) = "BAS:EMAILX.SBX"

ATT’CONTENT’TYPE(1) = ""         ! (let it default)

ATT’ENCODING(1) = CTE’BASE64      ! (base64 encoding)

ATT’FILE(2) = "/vm/miame/miame.ini"

ATT’CONTENT’TYPE(2) = "text/plain"

ATT’ENCODING(2) = CTE’7BIT      ! 7 bit text, no encoding

XCALL EMAILX,EM’OPFLAGS,EM’CFGFILE,EM’TO,EM’HEADER,EM’BODY, EM’STATUS,EM’FROM,EM’ATTACHMENTS,"EMSIG.TXT",EM’ERRMSG

IF EM’STATUS # 0 then print "Error #";EM’STATUS;" – ";EM’ERRMSG

Note that there was no particularly good reason to not use base64 encoding (CTE’BASE64) for the second attachment as well, other than to save a few bytes. In fact, one possible problem with text/plain encoding is that the line terminators will be converted to CRLF, even if they were originally just LF. Base64 encoding eliminates this possibility.