Reputation: 2465
I am trying to find out what universal subroutines can I have in an email parsing library.
I know of two MIME fields that often take parameters:
Content-Type: application/x-stuff;
title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
(example from https://www.rfc-editor.org/rfc/rfc2231)
and
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
(example from https://www.rfc-editor.org/rfc/rfc2183)
Are they the only ones - or is this an universal mechanism? https://www.rfc-editor.org/rfc/rfc822 only talks about 'structured' fields - the fields above are 'structured' for sure, but the example in rfc822 is about an address field - which is a different structure - list of addresses.
Upvotes: 0
Views: 809
Reputation: 189628
The Received: header is typically structured, although the spec is rather vague and there is no serious standardization effort. The closest thing resembling a de facto standard is Sendmail, which is mimicked more or less closely by Postfix. The DKIM signature is structured, in a fairly clever way. The ad hoc header inserted by SpamAssassin has a structure; it tells you why a message was classified as spam. There are oodles more, but this should give you something to start chewing. None of the examples here use the Mime Content-xxx syntax.
Upvotes: 1
Reputation: 1628
There are two more MIME fields in email as far as I know:
MIME-Version: 1.0
which has no parameters, and
Content-Transfer-Encoding: ...
has none, either.
There is no general "MIME header field parameter rule", just look up the standard definition for each header field.
(EDIT:) After your additions to the original question, you can of course use universal subroutines. Be warned that email heaader parsing is a nontrivial task (cf. RFC 2822). These universal subroutines come into my mind:
However, all this exists in many open source libraries of course.
Upvotes: 1