First, if the number of FS file to be written is determined: it is the number of special recipients plus, if there is a sender template or template contents from a custom DLL, the number of fax recipients. This determines the number of FS file numbers which will be obtained. Failure to get FS numbers results in error (2). The first FS number obtained will be used to name saved attachment files.
If the main message is not a multipart message, its message body and body content type will be saved as the message body to be used, if it is text/plain or text/html. Otherwise, if an attachment can not be found, error (29) results;
For multipart messages, the message hierarchy is traversed to enumerate all the message parts and the type of each part.
All the attachments are then analyzed as follows:
•S/MIME signature parts are identified
•Content types which are 'message' are identified if the setting to discard embedded message attachments is enabled
•Content types which are 'application/x-microsoft-rpmsg-message' are identified
•Content types which are 'mstnef' or attachments with name winmail.dat or att*.dat are identified as TNEF and decoded. A failure to decode results in a notification GWTNEFERROR being initiated and in error (19). The same error is reported if there are multiple such attachments in the message.
•Attachment filenames with extensions .gct, .gtt or .cvr are identified as cover sheets for fax purposes.
•Invalid filename characters are removed from attachment names which will be used to save attachments.
•Image attachments are identified and their Content ID is saved.
Next the identified message-body parts are analyzed as follows to select the message body to be used:
•If the message has a 'special recipient' the text of the first body encountered is saved for use with the special recipients (see 'writing an FS file')
•if the first message body is text/plain or text/html) is saved in case a later body is not in a text format
•if a variable USE_FIRST_BODY had a non-empty value in content from a custom DLL, bodies other than the first are ignored.
•if sender option 8 (use rich content) is set and the message body is not text/plain, it is marked for saving as the chosen message body
•if sender option 8 (use rich content) is not set and the message body is text/plain and also not a text attachment, it is marked for saving as the chosen message body
•if the message body type is Word, Excel or PDF, it is saved as the chosen message body
•if sender option 8 (use rich content) is set and there is a TNEF attachment and it contains a message body, the body is saved in the attachments folder as an RTF file but is not used as the chosen message body.
If the chosen message-body part is HTML it is processed as follows:
•if sender option 6 (allow scripts) is not set the text is checked for a content <script> ,,, </script>. If found, the script content is removed.
•the html text is then scanned for tags starting <img or <v:imagedata. If found, the following content id (cid:) is matched against the image attachments. If matched, the image source in the html body is replaced with a file:/// reference to the folder where the image attachment will be saved.
•if sender options 1 (do not fax message) and 8 (fax plain text) are not set, the html text is saved and added to the list of files to be faxed.
If the chosen message-body part is plain text it is processed as follows:
•the plain text body is saved.
•if sender options 1 (do not fax message) and 9 (use plain text in cover memo) are not set, and if the text is not empty, it is added to the list of files to be faxed.
If the chosen message-body part is not text, but text has been saved for use as body text, it is processed as follows:
•the content is saved as .rtf if identified as RTF, or as .txt otherwise.
•if sender options 1 (do not fax message) and 9 (use plain text in cover memo) are not set, and if the text is not empty, it is added to the list of files to be faxed.
The body parts have now either been saved or will be marked for use as MEMO variables for a fax cover sheet.
