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'"

Unsorted

Spamassassin

Hooking a working spamassassin into postfix

✎ 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.

Assuming you've already set up spamassassin itself so that it functions, the next step is to make it actually filter postfix mail.

The first part is to add spamassassin as a content filter.

Which mostly means it adds X-Spam headers. This does not do any rejection yet.

In /etc/postfix/master.cf add a line like (this can vary a little, a little reading around here can't hurt)

spamassassin unix -     n       n       -       -       pipe user=spamfilter argv=/usr/bin/spamc -f -e  /usr/sbin/sendmail -oi -f ${sender} ${recipient}

If you want to be careful about what you bounce, then you may want to put the threshold for marking it spam (required_hits in /etc/spamassassin/local.cf (defaults to 5, which seems sensible) lower than the rejection threshold (next bit:).

To do the actual filtering, edit/create a /etc/postfix/header_checks, which is a rule system based on header matches. Which we do based on X-Spam headers we've just configured it to add.

You can get control of what level to filter by looking at X-Spam-Level. For example to reject level 7 or higher:

/^X-Spam-Level: \*\*\*\*\*\*\*/ REJECT spam content

You can choose to

• REJECT for an explicit bounce
• DISCARD to say you accepted it, but actually drop it
• HOLD for review (only makes sense if you have someone actually doing this)
• REDIRECT to a spam address, e.g. a local mailbox (if you have someone looking at this, or want to collect it for fun)

Also ensure this header_checks file is hooked into main.cf, looking for a line like:

header_checks = regexp:/etc/postfix/header_checks

Restart postfix

/etc/init.d/postfix reload

and send a test. The following is a test string that is always considered spam[2]

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Check your mail log to see the response.

tail -F /var/log/mail.log

.forward

✎ 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.