MIME and mail

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

MIME

MIME (Multipurpose Internet Mail Extensions) is a container format mostly commonly used in mail sent through SMTP.

(The combination is sometimes called SMTP/MIME, but this is often avoided to avoid confusion with S/MIME, a public-key scheme that allows the signing and encrypting of MIME messages)

MIME deals with text coding (character set specification, and non-ASCII headers), but also with message structure, particularly multi-part bodies, which allows attachments (text and non-text), and message nesting (useful in replying and forwarding messages verbatim, including attachments).

Also related: Binary-to-text coding#Base64 and Binary-to-text coding#Quoted_printable

'MIME compatible'

MIME compatible basically means "this text data does not contain characters that would mess up if you dumped this verbatim within MIME message".

It is most usually seen wherever you want to transfer arbitrary data via MIME, that should not break things and should not be altered in the process.

Specific parts of MIME-formatted messages may not contain certain characters.

They may not control characters (0x00-0x1F, 0x7F), or non-ASCII (0x80-0xFF)(verify).

Some characters (like 0x0D and 0x0A) may well be altered or parsed out in the process of MIME parsing, so aren't used in any significant way.

As a result:

• arbitrary binary data cannot be safely embedded as-is, and must be encoded, most typically using Base64, which is a transformation to just printable ASCII characters (similar to uuencode, binhex), taking more space in the process.

• most character codings cannot be used without being Base64'd.

Both mean space efficiency isn't what it could theoretically be

MIME types

'MIME type' is technically now called Internet media type.

See also

• http://en.wikipedia.org/wiki/MIME
• http://www.iana.org/assignments/media-types/

Standards:

• RFC 2821: 'Simple Mail Transfer Protocol)' (SMTP)
• RFC 2822: 'Internet Message Format' (mostly outdates RFC 822)
• RFC 822: 'Standard for the Format of ARPA Internet Text Messages'

And also:

• RFC 2045: 'MIME Part One: Format of Internet Message Bodies'
• RFC 2046: 'MIME Part Two: Media Types'
• RFC 2047: 'MIME Part Three: Message Header Extensions for Non-ASCII Text'

• RFC 2231: 'MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations'

Also related, perhaps a little less interesting:

• RFC 4288: 'Media Type Specifications and Registration Procedures'
• RFC 4289: 'MIME Part Four: Registration Procedures'
• RFC 2077: 'The Model Primary Content Type for Multipurpose Internet Mail Extensions'

Mail

delivery tricks for admins

Sending to another host, via SSH

I wanted this to aggregate admin-ish mail such as "drive is starting to fail" errors -- stuff I script myself -- from various workstations to one server. That server has local-only delivery (and I didn't want a real mail server because properly securing one is a special hell).

My solution: Use a passphraseless ssh keypair, and a command like the following:

echo "Message for root on host2" | ssh mailuser@host2 "mailx root"

...which is really just running mailx remotely and piping some text into it.

Forwarding mail to another host, via SSH

The above only works if you're a script willing to run that ssh command yourself.

I wanted all of root's mail (e.g. cron, logwatch, and other such messages) to be sent elsewhere.

Since .forward allows commands[1], this amounts to a variation of the above:

|"ssh user@host2 'mailx user2'"