2.2 MML Definition

The MML language is very simple. It looks a bit like an SGML application, but it’s not.

The main concept of MML is the part. Each part can be of a different type or use a different charset. The way to delineate a part is with a ‘<#part ...>’ tag. Multipart parts can be introduced with the ‘<#multipart ...>’ tag. Parts are ended by the ‘<#/part>’ or ‘<#/multipart>’ tags. Parts started with the ‘<#part ...>’ tags are also closed by the next open tag.

There’s also the ‘<#external ...>’ tag. These introduce ‘external/message-body’ parts.

Each tag can contain zero or more parameters on the form ‘parameter=value’. The values may be enclosed in quotation marks, but that’s not necessary unless the value contains white space. So ‘filename=/home/user/#hello$^yes’ is perfectly valid.

The following parameters have meaning in MML; parameters that have no meaning are ignored. The MML parameter names are the same as the MIME parameter names; the things in the parentheses say which header it will be used in.

‘type’

The MIME type of the part (Content-Type).

‘filename’

Use the contents of the file in the body of the part (Content-Disposition).

‘recipient-filename’

Use this as the file name in the generated MIME message for the recipient. That is, even if the file is called ‘foo.txt’ locally, use this name instead in the Content-Disposition in the sent message.

‘charset’

The contents of the body of the part are to be encoded in the character set specified (Content-Type). See section Charset Translation.

‘name’

Might be used to suggest a file name if the part is to be saved to a file (Content-Type).

‘disposition’

Valid values are ‘inline’ and ‘attachment’ (Content-Disposition).

‘encoding’

Valid values are ‘7bit’, ‘8bit’, ‘quoted-printable’ and ‘base64’ (Content-Transfer-Encoding). See section Charset Translation.

‘description’

A description of the part (Content-Description).

‘creation-date’

RFC822 date when the part was created (Content-Disposition).

‘modification-date’

RFC822 date when the part was modified (Content-Disposition).

‘read-date’

RFC822 date when the part was read (Content-Disposition).

‘recipients’

Who to encrypt/sign the part to. This field is used to override any auto-detection based on the To/CC headers.

‘sender’

Identity used to sign the part. This field is used to override the default key used.

‘size’

The size (in octets) of the part (Content-Disposition).

‘sign’

What technology to sign this MML part with (smime, pgp or pgpmime)

‘encrypt’

What technology to encrypt this MML part with (smime, pgp or pgpmime)

Parameters for ‘text/plain’:

‘format’

Formatting parameter for the text, valid values include ‘fixed’ (the default) and ‘flowed’. Normally you do not specify this manually, since it requires the textual body to be formatted in a special way described in RFC 2646. See section Flowed text.

Parameters for ‘application/octet-stream’:

‘type’

Type of the part; informal—meant for human readers (Content-Type).

Parameters for ‘message/external-body’:

‘access-type’

A word indicating the supported access mechanism by which the file may be obtained. Values include ‘ftp’, ‘anon-ftp’, ‘tftp’, ‘localfile’, and ‘mailserver’. (Content-Type.)

‘expiration’

The RFC822 date after which the file may no longer be fetched. (Content-Type.)

‘size’

The size (in octets) of the file. (Content-Type.)

‘permission’

Valid values are ‘read’ and ‘read-write’ (Content-Type).

Parameters for ‘sign=smime’:

‘keyfile’

File containing key and certificate for signer.

Parameters for ‘encrypt=smime’:

‘certfile’

File containing certificate for recipient.

This document was generated on January 25, 2015 using texi2html 1.82.