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.
If you want to talk about MML in a message, you need a way to “quote” these tags. The way to do that is to include an exclamation point after the opening two characters; i. e. ‘<#!part ...>’.
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.
The MIME type of the part (Content-Type).
Use the contents of the file in the body of the part
(Content-Disposition).
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.
The contents of the body of the part are to be encoded in the character
set specified (Content-Type). See Charset Translation.
Might be used to suggest a file name if the part is to be saved
to a file (Content-Type).
Valid values are ‘inline’ and ‘attachment’
(Content-Disposition).
Valid values are ‘7bit’, ‘8bit’, ‘quoted-printable’ and
‘base64’. See Charset Translation. This parameter says what
Content-Transfer-Encoding to use when sending the part, and is
normally computed automatically.
This parameter says what encoding has been used on the data, and the data will be decoded before use. Valid values are ‘quoted-printable’ and ‘base64’. This is useful when you have a part with binary data (for instance an image) inserted directly into the Message buffer inside the ‘"<#part>...<#/part>"’ tags.
A description of the part (Content-Description).
Date when the part was created (Content-Disposition).
This uses the format of RFC 822 or its successors.
RFC 822 (or later) date when the part was modified
(Content-Disposition).
RFC 822 (or later) date when the part was read (Content-Disposition).
Who to encrypt/sign the part to. This field is used to override any auto-detection based on the To/Cc headers.
Identity used to sign the part. This field is used to override the default key used.
The size (in octets) of the part (Content-Disposition).
What technology to sign this MML part with (smime, pgp
or pgpmime)
What technology to encrypt this MML part with (smime,
pgp or pgpmime)
Parameters for ‘text/plain’:
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 Flowed text.
Parameters for ‘application/octet-stream’:
Type of the part; informal—meant for human readers
(Content-Type).
Parameters for ‘message/external-body’:
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.)
RFC 822 (or later) date after which the file may no longer be fetched.
(Content-Type.)
The size (in octets) of the file. (Content-Type.)
Valid values are ‘read’ and ‘read-write’
(Content-Type).
Parameters for ‘sign=smime’:
File containing key and certificate for signer.
Parameters for ‘encrypt=smime’:
File containing certificate for recipient.