<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>The KMime Library</title>
<style type="text/css">
.cp-doNotDisplay { display: none; }
@media aural, braille, handheld, tty { .cp-doNotDisplay { display: inline; speak: normal; }}
.cp-edit { text-align: right; }
@media print, embossed { .cp-edit { display: none; }}
</style>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="meta" href="http://www.kde.org/labels.rdf" type="application/rdf+xml" title="ICRA labels" />
<meta name="trademark" content="KDE e.V." />
<meta name="description" content="K Desktop Environment Homepage, KDE.org" />
<meta name="MSSmartTagsPreventParsing" content="true" />
<meta name="robots" content="all" />
<meta name="no-email-collection" content="http://www.unspam.com/noemailcollection" />
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link rel="shortcut icon" href="../../favicon.ico" /><link rel="icon" href="../../favicon.ico" />
<link rel="stylesheet" media="screen" type="text/css" title="KDE Colors" href="../../kde.css" />
<link rel="stylesheet" media="print, embossed" type="text/css" href="../../print.css" />
<link rel="stylesheet" media="screen, aural, handheld, tty, braille" type="text/css" title="Flat" href="../../flat.css" />
<link rel="stylesheet" type="text/css" href="../../doxygen.css" />
<link rel="stylesheet" type="text/css" href="../../tabs.css" />
</head>
<body>
<ul class="cp-doNotDisplay">
<li><a href="#cp-content" accesskey="2">Skip to content</a></li>
<li><a href="#cp-menu" accesskey="5">Skip to link menu</a></li>
</ul>
<div id="container">
<div id="header">
<div id="header_top"><div><div>
<img alt ="" src="../../top-kde.jpg"/>
</div></div></div>
<div id="header_bottom">
<div id="location">
<ul>
<li><a href="http://api.kde.org">KDE API Reference</a></li>
<li><a href="../../index.html">kdepimlibs-4.10.5 API Reference</a></li>
</ul>
</div>
<div id="menu">
<ul>
<li><a href="http://www.kde.org/">KDE Home</a></li>
<li><a href="http://kde.org/contact/">Contact Us</a></li>
</ul>
</div>
</div>
</div>
<!-- End page header -->
<div id="body_wrapper">
<div id="body">
<!-- begin main content -->
<div id="right">
<div class="content">
<div id="main">
<div class="clearer"> </div>
<h2><a name="content"></a>KMIME Library</h2>
<!-- BC -->
<div id="top">
<!-- Generated by Doxygen 1.8.3.1 -->
</div><!-- top -->
<div class="header">
<div class="headertitle">
<div class="title">The <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> Library </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><h1><a class="anchor" id="introduction"></a>
Introduction</h1>
<p><a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> is a library for handling mail messages and newsgroup articles. Both mail messages and newsgroup articles are based on the same standard called MIME, which stands for <b>Multipurpose Internet Mail Extensions</b>. In this document, the term <code>message</code> is used to refer to both mail messages and newsgroup articles.</p>
<p><a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> deals solely with the in-memory representation of messages, topics such a transport or storage of messages are handled by other libraries, for example by <a href="http://api.kde.org/4.x-api/kdepimlibs-apidocs/mailtransport/html/index.html">the mailtransport library</a> or by <a href="http://api.kde.org/4.x-api/kdepimlibs-apidocs/kimap/html/index.html">the KIMAP library</a>. Similary, this library does not deal with displaying messages or advanced composing, for those there are the <a href="http://api.kde.org/4.x-api/kdepim-apidocs/messageviewer/html/index.html">messageviewer</a> and the <a href="http://websvn.kde.org/trunk/KDE/kdepim/messagecomposer/">messagecomposer</a> components in the KDEPIM module.</p>
<p><a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a>'s main function is to parse, modify and assemble messages in-memory. In a <a class="el" href="index.html#string-broken-down">later section</a>, <em>parsing</em> and <em>assembling</em> is actually explained. <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> provides high-level classes that make these tasks easy.</p>
<p>MIME is defined by various RFCs, see the <a class="el" href="index.html#rfcs">RFC section</a> for a list of them.</p>
<h1><a class="anchor" id="structure"></a>
Structure of this document</h1>
<p>This document will first give an <a class="el" href="index.html#mime-intro">introduction to the MIME specification</a>, as it is essential to understand the basics of the structure of MIME messages for using this library. The introduction here is aimed at users of the library, it gives a broad overview with examples and omits some details. Developers who wish to modifiy <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> should read the <a class="el" href="index.html#rfcs">corresponding RFCs</a> as well, but this is not necessary for library users.</p>
<p>After the introduction to the MIME format, the two ways of representing a message in memory are discussed, the <a class="el" href="index.html#string-broken-down">string representation and the broken down representation</a>.</p>
<p>This is followed by a section giving an <a class="el" href="index.html#classes-overview">overview of the most important KMime classes</a>.</p>
<p>The last sections give a list of <a class="el" href="index.html#rfcs">relevant RFCs</a> and provide links for <a class="el" href="index.html#links">further reading</a>.</p>
<h1><a class="anchor" id="mime-intro"></a>
Structure of MIME messages</h1>
<h2><a class="anchor" id="history"></a>
A brief history of the MIME standard</h2>
<p>The MIME standard is quite new (1993), email and usenet existed way before the MIME standard came into existence. Because of this, the MIME standard has to keep backwards compatibility. The email standard before MIME lacked many capabilities like encodings other than ASCII or attachments. These and other things were later added by MIME. The standard for messages before MIME is defined in <a href="http://tools.ietf.org/html/rfc5322">RFC 5322</a>. In <a href="http://tools.ietf.org/html/rfc2045">RFC 2045</a> to <a href="http://tools.ietf.org/html/rfc2049">RFC 2049</a>, several backward-compatible extensions to the basic message format are defined, adding support for attachments, different encodings and many others.</p>
<p>Actually, there is an even older standard, defined in <a href="http://tools.ietf.org/html/rfc733">RFC 733</a> (<em>Standard for the format of ARPA network text messages</em>, introduced in 1977). This standard is now obsoleted by RFC 5322, but backwards compatibilty is in some cases supported, as there are still messages in this format around.</p>
<p>Since pre-MIME messages had no way to handle attachments, attachments were sometimes added to the message text in an <a href="http://en.wikipedia.org/wiki/Uuencoding">uuencoded</a> form. Although this is also obsolete, reading uuencoded attachments is still supported by <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a>.</p>
<p>After MIME was introduced, people realized that there is no way to have the filename of attachments encoded in anything different than ASCII. Thus, <a href="http://tools.ietf.org/html/rfc2231">RFC 2231</a> was introduced to allow abitrary encodings for parameter values, such as the attachment filename.</p>
<h2><a class="anchor" id="examples"></a>
MIME by examples</h2>
<p>In the following sections, MIME message examples are shown, examined and explained, starting with a simple message and proceeding to more interesting examples. You can get additional examples by simply viewing the source of your own messages in your mail client, or by having a look at the examples in the <a class="el" href="index.html#rfcs">various RFCs</a>.</p>
<h3><a class="anchor" id="simple-mail"></a>
A simple message</h3>
<pre class="fragment">Subject: First Mail
From: John Doe <john.doe@domain.com>
Date: Sun, 21 Feb 2010 19:16:11 +0100
MIME-Version: 1.0
Hello World!
</pre><p> The above example features a very simple message. The two main parts of this message are the <b>header</b> and the <b>body</b>, which are seperated by an empty line. The body contains the actual message content, and the header contains metadata about the message itself. The header consists of several <b>header fields</b>, each of them in their own line. Header fields are made up from the <b>header field name</b>, followed by a colon, followed by the <b>header field body</b>.</p>
<p>The <b>MIME-Version</b> header field is mandatory for MIME messages. <b>Subject</b>, <b>From</b> and <b>Date</b> are important header fields, they are usually displayed in the message list of a mail client. The <code>Subject</code> header field can be anything, it does not have a special structure. It is a so-called <b>unstructured</b> header field. In contrast, the <code>From</code> and the <code>Date</code> header fields have to follow a special structure, they must be formed in a way that machines can parse. They are <b>structured</b> header fields. For example, a mail client needs to understand the <code>Date</code> header field so that it can sort the messages by date in the message list. The exact details of how the header field bodies of structured header fields should be formed are specified in an RFC.</p>
<p>In this example, the <code>From</code> header contains a single email address. More precisly, a single email address is called a <b>mailbox</b>, which is made up of the <b>display name</b> (John Doe) and the <b>address specification</b> (<a href="#" onclick="location.href='mai'+'lto:'+'joh'+'n.'+'doe'+'@d'+'oma'+'in'+'.co'+'m'; return false;">john.<span style="display: none;">.nosp@m.</span>doe@<span style="display: none;">.nosp@m.</span>domai<span style="display: none;">.nosp@m.</span>n.co<span style="display: none;">.nosp@m.</span>m</a>), which is enclosed in angle brackets. The <code>addr-spec</code> consists of the user name, the <b>local part</b>, and the <b>domain</b> name.</p>
<p>Many header fields can contain multiple email addresses, for example the <code>To</code> field for messages with multiple recipients can have a comma-seperated list of mailboxes. A list of mailboxes, together with a display name for the list, forms a <b>group</b>, and multiple groups can form an <b>address list</b>. This is however rarely used, you'll most often see a simple list of plain mailboxes.</p>
<p>There are many more possible header fields than shown in this example, and the header can even contain abitrary header fields, which usually are prefixed with <code>X-</code>, like <code>X-Face</code>.</p>
<h3><a class="anchor" id="encodings"></a>
Encodings and charsets</h3>
<pre class="fragment">From: John Doe <john.doe@domain.com>
Date: Mon, 22 Feb 2010 00:42:45 +0100
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Gr=FCezi Welt!
</pre><p>The above shows a message that is using a different <b>charset</b> than the standard <b>US-ASCII</b> charset. The message body contains the string "Grüezi Welt!", which is <b>encoded</b> in a special way.</p>
<p>The <b>content-type</b> of this message is <b>text/plain</b>, which means that the message is simple text. Later, other content types will be introduced, such as <b>text/html</b>. If there is no <code>Content-Type</code> header field, it is assumed that the content-type is <code>text/plain</code>.</p>
<p>Before MIME was introduced, all messages were limited to the US-ASCII charset. Only the lower 127 values of the bytes were allowed to be used, the so-called <b>7-bit</b> range. Writing a message in another charset or using letters from the upper 127 byte values was not allowed.</p>
<dl class="section user"><dt>Charset Encoding</dt><dd></dd></dl>
<p>When talking about charsets, it is important to understand how strings of text are converted to byte arrays, and the other way around. A message is nothing else than a big array of bytes. The bytes that form the body of the message somehow need to be interpreted as a text string. Interpreting a byte array as a text string is called <b>decoding</b> the text. Converting a text string to a byte array is called <b>encoding</b> the text. A <b>codec</b> (<b>co</b>der-<b>dec</b>oder) is a utility that can encode and decode text. In Qt, the class for text strings is QString, and the class for byte arrays is QByteArray. The base class of all codecs is QTextCodec.</p>
<p>With the US-ASCII charset, encoding and decoding text is easy, one just has to look at an <a href="http://en.wikipedia.org/wiki/ASCII_table">ASCII table</a> to be able to convert text strings to byte arrays and byte arrays to text strings. For example, the letter 'A' is represented by a single byte with the value of 65. When encountering a byte with the value 84, we can look that up in the table and see that it represents the letter 'T'. With the US-ASCII charset, each letter is represented by exactly one byte, which is very convenient. Even better, all letters commonly used in English text have byte values below 127, so the 7-bit limit of messages is no problem for text encoded with the US-ASCII charset. Another example: The string "Hello World!" is represented by the following byte array:<br/>
<code>48 65 6C 6C 6F 20 57 6F 72 6C 64</code><br/>
Note that the byte values are written in hexadecimal form here, not in decimal as earlier.</p>
<p>Now, what if we want to write a message that contains German umlauts or Chinese letters? Those are not in the ASCII table, therefore a different charset has to be used. There is a wealth of charsets to chose from. Not all charsets can handle all letters, for example the <a href="http://en.wikipedia.org/wiki/ISO-8859-1#ISO-8859-1">ISO-8859-1</a> charset can handle German umlauts, but can not handle Chinese or Arabic letters. The <a href="http://en.wikipedia.org/wiki/Unicode">Unicode standard</a> is an attempt to introduce charsets that can handle all known letters in the world, in all languages. Unicode actually has several charsets, for example <a href="http://en.wikipedia.org/wiki/UTF-8">UTF-8</a> and <a href="http://en.wikipedia.org/wiki/UTF-16">UTF-16</a>. In an ideal world, everyone would be using Unicode charsets, but for historic and legacy reasons, other charsets are still much in use.</p>
<p>Charsets other than US-ASCII don't generally have as nice properties: A single letter can be represented by multiple bytes, and generally the byte values are not in the 7-bit range. Pay attention to the UTF-8 charset: At first glance, it looks exactly like the US-ASCII charset, common latin letters like A - Z are encoded with the same byte values as with US-ASCII. However, letters other than A - Z are suddenly encoded with two or even more bytes. In general, one letter can be encoded in an abitrary number of bytes, depending on the charset. One can <b>not</b> rely on the <code>1 letter == 1 byte</code> assumption.</p>
<p>Now, what should be done when the text string "Grüezi Welt!" should be sent in the body of a message? The first step is to chose a charset that can represent all letters. This already excludes US-ASCII. Once a charset is chosen, the text string is encoded into a byte array. "Grüezi Welt!" encoded with the ISO-8859-1 charset produces the following byte array:<br/>
<code>47 72 FC 65 7A 69 20 57 65 6C 74 21</code><br/>
The letter 'ü' here is encoded using a single byte with the value <code>FC</code>. The same string encoded with UTF-8 looks slightly different:<br/>
<code>47 72 C3 BC 65 7A 69 20 57 65 6C 74 21</code><br/>
Here, the letter 'ü' is encoded with two bytes, <code>C3 BC</code>. Still, one can see the similarity between the two charsets for the other letters.</p>
<p>You can try this out yourself: Open your favorite text editor and enter some text with non-latin letters. Then save the file and view it in a hex editor to see how the text was converted to a byte array. Make sure to try out setting different charsets in your text editor.</p>
<p>At this point, the text string is sucessfully converted to a byte array, using e.g. the ISO-8859-1 charset. To indicate which charset was used, a <b>Content-Type</b> header field has to be added, with the correct <b>charset</b> parameter. In our example above, that was done. If the charset parameter of the <code>Content-Type</code>, or even the complete <code>Content-Type</code> header field is left out, the receiver can not know how to interpret the byte array! In these cases, the byte array is usually decoded incorrectly, and the text strings contain wrong letters or lots of questionmarks. There is even a special term for such wrongly decoded text, <a href="http://en.wikipedia.org/wiki/Mojibake">Mojibake</a>. It is important to always know what charset your byte array is encoded with, otherwise an attempt at decoding the byte array into a text string will fail and produce Mojibake. <b>There is no such thing as plain text!</b> If there is no <code>Content-Type</code> header field in a message, the message body should be interpreted as US-ASCII.</p>
<p>To learn more about charsets and encodings, read <a href="http://www.joelonsoftware.com/articles/Unicode.html">The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)</a> and <a href="http://www.cs.tut.fi/~jkorpela/chars.html">A tutorial on character code issues</a>. Especially the first article should really be read, as the name indicates.</p>
<dl class="section user"><dt>Content Transfer Encoding</dt><dd></dd></dl>
<p>Now, we can't use the byte array that was just created in a message. The string encoded with ISO-8859-1 has the byte value <code>FC</code> for the letter 'ü', which is decimal value 252. However, as said earlier, messages are only valid when all bytes are in the 7-bit range, i.e. have byte value below 127. So what should we do for byte values that are greater than 127, how can they be added to messages? The solution for this is to use a <b>content transfer encoding</b> (CTE). A content transfer encoding takes a byte array as input and transforms it. The output is another byte array, but one which only uses byte values in the 7-bit range. One such content transfer encoding is <b>quoted-printable</b> (QTP), which is used in the above example. Quoted-printable is easy to understand: When encountering a byte that has a value greater than 127, it is simply replaced by a '=', followed by the hexadecimal code of the byte value, represented as letters and digits encoded with ASCII. This means that a byte with the value 252 is replaced with the ASCII string <code>=FC</code>, since <code>FC</code> is the hexadecimal value of 252. The ASCII string <code>=FC</code> itself is now three bytes big, <code>3D 46 43</code>. Therefore, the quoted-printable encoding replaces each byte outside of the 7-bit range with 3 new bytes. Decoding quoted-printable encoding is also easy: Each time a byte with the value <code>3D</code>, which is the letter '=' in ASCII, is encountered, the next two following bytes are interpreted as the hex value of the resulting byte. The quoted-printable encoding was invented to make reading the byte array easy for humans.</p>
<p>The quoted-printable encoding is not a good choice when the input byte array contains lots of bytes outside the 7-bit range, as the resulting byte array will be three times as big in the worst case, which is a waste of space. Therefore another content transfer encoding was introduced, <b>Base64</b>. The details of the base64 encoding are too much to write about here; refer to the <a href="http://en.wikipedia.org/wiki/Base64">Wikipedia article</a> or the <a href="http://tools.ietf.org/html/rfc2045#section-6.8">RFC</a> for details. As an example, the ISO-8859-1 encoded text string "Grüezi Welt!" is, after encoding it with base64, represented by the following ASCII string: <code>R3L8ZXppIFdlbHQh</code>. To express the same in byte arrays: The byte array <code>47 72 FC 65 7A 69 20 57 65 6C 74 21</code> is, after encoding it with base64, represented by the byte array <code>52 33 4C 38 5A 58 70 70 49 46 64 6C 62 48 51 68</code></p>
<p>There are two other content transfer encodings besides quoted printable and base64: <b>7-bit</b> and <b>8-bit</b>. 7-bit is just a marker to indicate that no content transfer encoding is used. This is the case when the byte array is already completley in the 7-bit range, for example when writing English text using the US-ASCII charset. 8-bit is also a marker to indicate that no content transfer encoding was used. This time, not because it was not necessary, but because of a special exception, byte values outside of the 7-bit range are allowed. For example, some SMTP servers support the <a href="http://tools.ietf.org/html/rfc1652">8BITMIME</a> extension, which indicates that they accept bytes outside of the 7-bit range. In this case, one can simply use the byte arrays as-is, without using any content transfer encoding. Creating messages with 8-bit content transfer encoding is currently not supported by <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a>. The advantage of 8-bit is that there is no overhead in size, unlike with base64 or even quoted-printable.</p>
<p>When using one of the 4 contents transfer encodings, i.e. quoted-printable, base64, 7-bit or 8-bit, this has to be indicated in the header field <b>Content-Transfer-Encoding</b>. If the header field is left out, it is assumed that the content transfer encoding is 7-bit. The example above uses quoted-printable.</p>
<pre class="fragment">From: John Doe <john.doe@domain.com>
Date: Mon, 22 Feb 2010 00:42:45 +0100
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: base64
R3L8ZXppIFdlbHQh
</pre><p> The same example, this time encoded with the base64 content transfer encoding.</p>
<pre class="fragment">From: John Doe <john.doe@domain.com>
Date: Mon, 22 Feb 2010 00:42:45 +0100
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: base64
R3LDvGV6aSBXZWx0IQ==
</pre><p> Again the same example, this time using UTF-8 as the charset.</p>
<pre class="fragment">From: John Doe <john.doe@domain.com>
Date: Mon, 22 Feb 2010 00:42:45 +0100
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Gr=C3=BCezi Welt!
</pre><p> The example with a combination of UTF-8 and quoted-printable CTE. As said somewhere above, with the UTF-8 encoding, the letter 'ü' is represented by the two bytes <code>C3 BC</code>.</p>
<pre class="fragment">From: John Doe <john.doe@domain.com>
Date: Mon, 22 Feb 2010 00:42:45 +0100
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7-bit
Hello World
</pre><p> A different example, showing 7-bit content transfer encoding. Although the UTF-8 charset has lots of letters that are represented by bytes outside of the 7-bit range, the string "Hello World" can be fully represented in the 7-bit range here, even with UTF-8.</p>
<p>In the <a class="el" href="index.html#links">further reading</a> section, you will find links to web applications that demonstrate encodings and charsets.</p>
<dl class="section user"><dt>Conclusion</dt><dd></dd></dl>
<p>When adding a text string to the body of a message, it needs to be encoded twice: First, the encoding of the charset needs to be applied, which transforms the text string into a byte array. Afterwards, the content transfer encoding has to be applied, which transforms the byte array from the first step into a byte array that only has bytes in the 7-bit range.</p>
<p>When decoding, the same has to be done, in reverse: One first has decode the byte array with the content transfer encoding, to get a byte array that has all 256 possible byte values. Afterwards, the resulting byte array needs to be decoded with the correct charset, to transform it into a text string. For those two decoding steps, one has to look at the <code>Content-Type</code> and the <code>Content-Transfer-Encoding</code> header fields to find the correct charset and CTE for decoding.</p>
<p>It is important to always keep the charset and the content transfer encoding in mind. Byte arrays and strings are not to be confused. Byte arrays that are encoded with a CTE are not to be confused with byte arrays that are <b>not</b> encoded with a CTE.</p>
<p>This section showed how to use different charsets in the <em>body</em> of a message. The next section will show what to do when another charset is needed in one of the <em>header</em> field bodies.</p>
<h3><a class="anchor" id="header-encoding"></a>
Encoding in Header Fields</h3>
<p>In the last section, we discussed how to use different charsets in the body of a message. But what if a different charset needs to be added to one of the header fields? For example one might want to write a mail to a mailbox with the display name "András Manţia" and with the subject "Grüezi!".</p>
<p>The header fields are limited to characters in the 7-bit range, and are interpreted as US-ASCII. That means the header field names, such as "From: ", are all encoded in US-ASCII. The header field bodies, such as the "1.0" of <code>MIME-Version</code>, are also encoded with US-ASCII. This is mandated by <a href="http://tools.ietf.org/html/rfc5322#section-2">the RFC</a>.</p>
<p>The <code>Content-Type</code> and the <code>Content-Transfer-Encoding</code> header fields only apply to the message body, they have no meaning for other header fields.</p>
<p>This means that any letter in a different charset has to be encoded in some way to statisfy the RFC. Letters with a different charset are only allowed in some of the header field bodies, the header field names always have to be in US-ASCII.</p>
<pre class="fragment">From: Thomas McGuire <thomas@domain.com>
Subject: =?iso-8859-1?q?Gr=FCezi!?=
Date: Mon, 22 Feb 2010 14:34:01 +0100
MIME-Version: 1.0
To: =?utf-8?q?Andr=C3=A1s?= =?utf-8?q?_Man=C5=A3ia?= <andras@domain.com>
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
bla bla bla
</pre><p>The above example shows how text that is encoded with a different charset than US-ASCII is handled in the message header. This can be seen in the bodies of the <code>Subject</code> header field and the <code>To</code> header field. In this example, the body of the message is unimportant, it is just "bla bla bla" in US-ASCII. The way the header field bodies are encoded is sometimes referred to as a <b>RFC2047 string</b> or as an <b>encoded word</b>, which has the origin in the <a href="http://tools.ietf.org/html/rfc2047">RFC</a> where this encoding scheme is defined. RFC2047 strings are only allowed in some of the header fields, like <code>Subject</code> and in the display name of mailboxes in header fields like <code>From</code> and <code>To</code>. In other header fields, such as <code>Date</code> and <code>MIME-Version</code>, they are not allowed, but they wouldn't make much sense there anyway, since those are structured header fields with a clearly defined structure.</p>
<p>RFC2047 strings start with "=?" and end with "?=". Between those markers, they consists of three parts: </p>
<ul>
<li>The charset, such as "iso-8859-1" </li>
<li>The encoding, which is "q" or "b" </li>
<li>The encoded text</li>
</ul>
<p>These three parts are sperated with a '?'. Encoding the third part, the text, is very similar to how text strings in the message body are encoded: First, the text string is encoded to a byte array using the charset encoding. Afterwards, the second encoding is used on the result, to ensure that all resulting bytes are within the 7-bit range.</p>
<p>The <em>second encoding</em> here is almost identical to the content transfer encoding. There are two possible encodings, <b>b</b> and <b>q</b>. The <code>b</code> encoding is the same as the base64 encoding of the content transfer encoding. The <code>q</code> encoding is very similar to the quoted-printable encoding of the content transfer encoding, but with some little differences that are described in <a href="http://tools.ietf.org/html/rfc2047#section-4.2">the RFC</a>.</p>
<p>Let's examine the subject of the message, <code>=?iso-8859-1?q?Gr=FCezi!?=</code>, in detail:<br/>
The first part of the RFC2027 string is the charset, so it is ISO-8859-1 in this case. The second part is the encoding, which is the <code>q</code> encoding here. The last part is the encoded text, which is <code>Gr=FCezi!</code>. As with the quoted-printable encoding, "=FC" is the encoding for the byte with the value <code>FC</code>, which in the ISO-8859-1 charset is the letter 'ü'. The complete decoded text is therefore "Grüezi!".</p>
<p>Each RFC2047 string in the header can use a different charset: In this example, the <code>Subject</code> uses ISO-8859-1, <code>To</code> uses UTF-8 and the message body uses US-ASCII.</p>
<p>In the <code>To</code> header field, two RFC2047 strings are used. A single, bigger, RFC2047 string for the whole display name could also have been used. In this case, the second RFC2047 string starts with an underscore, which is decoded as a space in the <code>q</code> encoding. The space between the two RFC2047 strings is ignored, it is just used to seperate the two encoded words.</p>
<p>There are some restriction on RFC2047 strings: They are not allowed to be longer than 75 characters, which means two or more encoded words have to be used for long text strings. Also, there are some restrictions on where RFC2047 strings are allowed; most importantly, the address specification must no not be encoded, to be backwards compatible. For further details, refer to the RFC.</p>
<h3><a class="anchor" id="multipart-mixed"></a>
Messages with attachments</h3>
<p>Until now, we only looked at messages that had a single text part as the message body. In this section, we'll examine messages with attachments.</p>
<pre class="fragment">From: frank@domain.com
To: greg@domain.com
Subject: Nice Photo
Date: Sun, 28 Feb 2010 19:57:00 +0100
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_8xriL5W6LSj00Ly"
--Boundary-00=_8xriL5W6LSj00Ly
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi Greg,
attached you'll find a nice photo.
--Boundary-00=_8xriL5W6LSj00Ly
Content-Type: image/jpeg;
name="test.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="test.jpeg"
/9j/4AAQSkZJRgABAQAAAQABAAD/4Q3XRXhpZgAASUkqAAgAAAAHAAsAAgAPAAAAYgAAAAABBAAB
[SNIP 800 lines]
ze5CdSH2Z8yTatHSV2veW0rKzeq30//Z
--Boundary-00=_8xriL5W6LSj00Ly--</pre><p> <em>Note: Since the image in this message would be really big, most of it is omitted / snipped here.</em></p>
<p>The above example consists of two parts: A normal text part and an image attachment. Messages that consist of multiple parts are called <b>multipart</b> messages. The top-level content-type therefore is <b>multipart/mixed</b>. <code>Mixed</code> simply means that the following parts have no relation to each other, it is just a random mixture of parts. Later, we will look at other types, such as <code>multipart/alternative</code> or <code>multipart/related</code>. A <b>part</b> is sometimes also called <b>node</b>, <b>content</b> or <b>MIME part</b>.</p>
<p>Each MIME part of the message is seperated by a <b>boundary</b>, and that boundary is specified in the top-level content-type header as a parameter. In the message body, the boundary is prefixed with <code>"&ndash;"</code>, and the last boundary is suffixed with <code>"&ndash;"</code>, so that the end of the message can be detected. When creating a message, care must be taken that the boundary appears nowhere else in the message, for example in the text part, as the parser would get confused by this.</p>
<p>A MIME part begins right after the boundary. It consists of a <b>MIME header</b> and a <b>MIME body</b>, which are seperated by an empty line. The MIME header should not be confused with the message header: The message header contains metadata about the whole message, like subject and date. The MIME header only contains metadata about the specific MIME part, like the content type of the MIME part. MIME header field names always start with <code>"Content-"</code>. The example above shows the three most important MIME header fields, usually those are the only ones used. The top-level header of a message actually mixes the message metadata and the MIME metadata into one header: In this example, the header contains the <code>Date</code> header field, which is an ordinary header field, and it contains the <code>Content-Type</code> header field, which is a MIME header field.</p>
<p>MIME parts can be nested, and therefore form a tree. The above example has the following tree: </p>
<pre class="fragment">multipart/mixed
|- text/plain
\- image/jpeg
</pre><p> The <code>text/plain</code> node is therefore a <b>child</b> of the <code>multipart/mixed</code> mode. The <code>multipart/mixed</code> node is a <b>parent</b> of the other two nodes. The <code>image/jpeg</code> node is a <b>sibling</b> of the <code>text/plain</code> node. <code>Multipart</code> nodes are the only nodes that have children, other nodes are <b>leaf</b> nodes. The body of a multipart node consists of all complete child nodes (MIME header and MIME body), seperated by the boundary.</p>
<p>Each MIME part can have a different content transfer encoding. In the above example, the text part has a <code>7bit</code> CTE, while the image part has a <code>base64</code> CTE. The multipart/mixed node does not specifiy a CTE, multipart nodes always have <code>7bit</code> as the CTE. This is because the body of multipart nodes can only consist of bytes in the 7 bit range: The boundary is 7 bit, the MIME headers are 7 bit, and the MIME bodies are already ancoded with the CTE of the child MIME part, and are therefore also 7 bit. This means no CTE for multipart nodes is necessary.</p>
<p>The MIME part for the image does not specify a charset parameter in the content type header field. This is because the body of that MIME part will not be interpreted as a text string, therefore the byte array does not need to be decoded to a string. Instead, the byte array is interpreted as an image, by an image renderer. The message viewer application passes the MIME part body as a byte array to the image renderer. The content type consists of a <b>media type</b> and a <b>subtype</b>. For example, the content type <code>"text/html"</code> has the media type "text" and the subtype "html". Only nodes that have the media type "text" need to specify a charset, as those nodes are the only nodes of which the body is interpreted as a text string.</p>
<p>The only header field not yet encountered in previous sections is the <b>Content-Disposition</b> header field, which is defined in a <a href="http://tools.ietf.org/html/rfc2183">seperate RFC</a>. It describes how the message viewer application should display the MIME part. In the case of the image part, is should be presented as an attachment. The <b>filename</b> parameter tells the message viewer application which filename should be used by default when the user saves the attachment to disk.</p>
<p>The content type header field for the image MIME part has a <b>name</b> parameter, which is similar to the <code>filename</code> parameter of the <code>Content-Disposition</code> header field. The difference is that <code>name</code> refers to the name of the complete MIME part, whereas <code>filename</code> refers to the name of the attachment. The <code>name</code> paramter of the <code>Content-Type</code> header field in this case is superfluous and only exists for backwards compatibility, and can be ignored; the <code>filename</code> parameter of the <code>Content-Disposition</code> header field should be prefered when it is present.</p>
<pre class="fragment">From: Thomas McGuire <thomas@domain.com>
To: sebastian@domain.com
Subject: Help with SPARQL
Date: Sun, 28 Feb 2010 21:57:51 +0100
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_PjtiLU2PvHpvp/R"
--Boundary-00=_PjtiLU2PvHpvp/R
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi Sebastian,
I have a problem with a SPARQL query, can you help me debug this? Attached is
the query and a screenshot showing the result.
--Boundary-00=_PjtiLU2PvHpvp/R
Content-Type: text/plain;
charset="UTF-8";
name="query.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="query.txt"
prefix nco:<http://www.semanticdesktop.org/ontologies/2007/03/22/nco#>
SELECT ?person
WHERE {
?person a nco:PersonContact .
?person nco:birthDate ?birthDate .
}"
--Boundary-00=_PjtiLU2PvHpvp/R
Content-Type: image/png;
name="screenshot.png"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="screenshot.png"
AAAAyAAAAAEBBAABAAAAyAAAAA0BAgATAAAAcQAAABIBAwABAAAAAQAAADEBAgAPAAAAhAAAAGmH
[SNIP]
YXJlLmpwZWcAZGlnaUthbS0w
--Boundary-00=_PjtiLU2PvHpvp/R--
</pre><p> The above example message consists of three MIME parts: The main text part and two attachments. One attachment has the media type <code>text</code>, therefore a charset parameter is necessary to correctly display it. The MIME tree looks like this: </p>
<pre class="fragment">multipart/mixed
|- text/plain
|- text/plain
\- image/jpeg
</pre><h3><a class="anchor" id="multipart-alternative"></a>
HTML Messages</h3>
<pre class="fragment">From: Thomas McGuire <thomas@domain.com>
Subject: HTML test
Date: Thu, 4 Mar 2010 13:59:18 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="Boundary-01=_m66jLd2/vZrH5oe"
Content-Transfer-Encoding: 7bit
--Boundary-01=_m66jLd2/vZrH5oe
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hello World
--Boundary-01=_m66jLd2/vZrH5oe
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head></head>
<body>
Hello <b>World</b>
</body>
</html>
--Boundary-01=_m66jLd2/vZrH5oe--
</pre><p>The above example is a simple HTML message, it consists of a plain text and a HTML part, which are in a <b>multipart/alternative</b> container. The message has the following structure: </p>
<pre class="fragment">multipart/alternative
|- text/plain
\- text/html
</pre><p> The HTML part and the plain text part have the identical content, except that the HTML part contains additional markup, in this case for displaying the word <code>World</code> in bold. Since those parts are in a multipart/alternative container, the message viewer application can freely chose which part it displays. Some users might prefer reading the message in HTML format, some might prefer reading the message in plain text format.</p>
<p>Of course, a HTML message could also consist only of a single <code>text/html</code>, without the multipart/alternative container and therefore without an alternative plain text part. However, people prefering the plain text version wouldn't like this, especially if their mail client has no HTML engine and they would see the HTML source including all tags only. Therefore, HTML messages should always include an alternative plain text part.</p>
<p>HTML messages can of course also contain attachments. In this case, the message contains both a multipart/alternative and a multipart/mixed node, for example with the following structure, for a HTML message that has an image attachment: </p>
<pre class="fragment">multipart/mixed
|- multipart/alternative
| |- text/plain
| \- text/html
\- image/png
</pre><p>The message itself would look like this: </p>
<pre class="fragment">From: Thomas McGuire <thomas@domain.com>
Subject: HTML message with an attachment
Date: Thu, 4 Mar 2010 15:20:26 +0100
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_qG8jLwWCwkUfJV1"
--Boundary-00=_qG8jLwWCwkUfJV1
Content-Type: multipart/alternative;
boundary="Boundary-01=_qG8jLfs1FRmlOhl"
Content-Transfer-Encoding: 7bit
--Boundary-01=_qG8jLfs1FRmlOhl
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hello World
--Boundary-01=_qG8jLfs1FRmlOhl
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head></head>
<body>
Hello <b>World</b>
</body>
</html>
--Boundary-01=_qG8jLfs1FRmlOhl--
--Boundary-00=_qG8jLwWCwkUfJV1
Content-Type: image/png;
name="test.png"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="test.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA8SAAAPEgEhm/IzAAAC
[SNIP]
eFkXsFgBMG4fJhYlx+iyB3cLpNZwYr/iP7teTwNYa7DZAAAAAElFTkSuQmCC
--Boundary-00=_qG8jLwWCwkUfJV1--</pre><h3><a class="anchor" id="multipart-related"></a>
HTML Messages with Inline Images</h3>
<p>HTML has support for showing images, with the <code>img</code> tag. Such an image is shown at the place where the <code>img</code> tag occurs, which is called an <b>inline image</b>. Note that inline images are different from images that are just normal attachments: Normal attachments are always shown at the beginning or at the end of the message, while inline images are shown in-place. In HTML, the <code>img</code> tag points to an image file that is either a file on disk or an URL to an image on the Internet. To make inline images work with MIME messages, a different mechanism is needed, since the image is not a file on disk or on the Internet, but a MIME part somewhere in the same message. As specified in <a href="http://tools.ietf.org/html/rfc2557">RFC 2557</a>, the way this can be done is by refering to a <b>Content-ID</b> in the <code>img</code> tag, and marking the MIME part that is the image with that content ID as well.</p>
<p>An example will probably be more clear than this explaination: </p>
<pre class="fragment">From: Thomas McGuire <thomas@domain.com>
Subject: Inine Image Test
Date: Thu, 4 Mar 2010 16:54:53 +0100
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="Boundary-02=_Nf9jLpJ2aGp5RQK"
Content-Transfer-Encoding: 7bit
--Boundary-02=_Nf9jLpJ2aGp5RQK
Content-Type: multipart/alternative;
boundary="Boundary-01=_Nf9jLZ6aPhm3WrN"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--Boundary-01=_Nf9jLZ6aPhm3WrN
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Text before image
Text after image
--Boundary-01=_Nf9jLZ6aPhm3WrN
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head></head>
<body>
Text before image<br>
<img src="cid:547730348@KDE" /><br>
Text after image
</body>
</html>
--Boundary-01=_Nf9jLZ6aPhm3WrN--
--Boundary-02=_Nf9jLpJ2aGp5RQK
Content-Type: image/png;
name="test.png"
Content-Transfer-Encoding: base64
Content-Id: <547730348@KDE>
iVBORw0KGgoAAAANSUhEUgAAAMgAAADICAIAAAAiOjnJAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAg
[SNIP]
AABJRU5ErkJggg==
--Boundary-02=_Nf9jLpJ2aGp5RQK--
</pre><p>The first thing you'll notice in this example probably is that it has a <b>multipart/related</b> node with the following structure: </p>
<pre class="fragment">multipart/related
|- multipart/alternative
| |- text/plain
| \- text/html
\- image/png
</pre><p>When the HTML part has inline image, the HTML part and its image part both have to be children of a multipart/related container, like in this example. In this case, the <code>img</code> tag has the source <code>cid:547730348</code> , which is a placeholder that refers to the Content-Id header of another part. The image part contains exactly that value in its <code>Content-Id</code> header, and therefore a message viewer application can connect both.</p>
<p>The plain text part can not have inline images, therefore its text might seem a bit confusing.</p>
<p>HTML messages with inline images can of course also have attachments, in which the message structure becomes a mix of multipart/related, multipart/alternative and multipart/mixed. The following example shows the structure of a message with two inline images and one <code></code>.tar.gz attachment: </p>
<pre class="fragment">multipart/mixed
|- multipart/related
| |- multipart/alternative
| | |- text/plain
| | \- text/html
| |- image/png
| \- image/png
\- application/x-compressed-tar
</pre><p>The structure of MIME messages can get arbitrarily complex, the above is just one relativley simply example. The nesting of multipart nodes can get much deeper, there is no restriction on nesting levels.</p>
<h3><a class="anchor" id="encapsulated"></a>
Encapsulated messages</h3>
<p>Encapsulated messages are messages which are attachments to another message. The most common example is a forwareded mail, like in this example: </p>
<pre class="fragment">From: Frank <frank@domain.com>
To: Bob <bob@domain.com>
Subject: Fwd: Blub
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_sX+jLVPkV1bLFdZ"
--Boundary-00=_sX+jLVPkV1bLFdZ
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi Bob,
hereby I forward you an interesting message from Greg.
--Boundary-00=_sX+jLVPkV1bLFdZ
Content-Type: message/rfc822;
name="forwarded message"
Content-Transfer-Encoding: 7bit
Content-Description: Forwarded Message
Content-Disposition: inline
From: Greg <greg@domain.com>
To: Frank <frank@domain.com>
Subject: Blub
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Bla Bla Bla
--Boundary-00=_sX+jLVPkV1bLFdZ--
</pre><pre class="fragment">multipart/mixed
|- text/plain
\- message/rfc822
\- text/plain
</pre><p>The attached message is treated like any other attachment, and therefore the top-level content type is multipart/mixed. The most interesting part is the <code>message/rfc822</code> MIME part. As usual, it has some MIME headers, like <code>Content-Type</code> or <code>Content-Disposition</code>, followed by the MIME body. The MIME body in this case is the attached message. Since it is a message, it consists of a header and a body itself. Therefore, the <code>message/rfc822</code> MIME part appears to have two headers; in reality, it is the normal MIME header and the message header of the encapsulated message. The message header and the message body are both in the MIME body of the <code>message/rfc822</code> MIME part.</p>
<h3><a class="anchor" id="crypto"></a>
Signed and Encryped Messages</h3>
<p>MIME messages can be cryptographically signed and/or encrypted. The format for those messages is defined in <a href="http://tools.ietf.org/html/rfc1847">RFC 1847</a>, which specifies two new multipart subtypes, <b>multipart/signed</b> and <b>multipart/encrypted</b>. The crypto format of these new security multiparts is defined in additional RFCs; the most common formats are <a href="http://tools.ietf.org/html/rfc3156">OpenPGP</a> and <a href="http://tools.ietf.org/html/rfc2633">S/MIME</a>. Both formats use the principle of <a href="http://en.wikipedia.org/wiki/Public-key_cryptography">public-key cryptography</a>. OpenPGP uses <b>keys</b>, and S/MIME uses <b>certificates</b>. For easier text flow, only the term <code>key</code> will be used for both keys and certificates in the text below.</p>
<p>Security multiparts only sign or encrypt a specifc MIME part. The consequence is that the message headers can not be signed or encrypted. Also this means that it is possible to sign or encrypt only some of the MIME parts of a message, while leaving other MIME parts unsigned or unencrypted. Furthermore, it is possible to sign or encrypt different MIME parts with different crypto formats. As you can see, security multiparts are very flexible.</p>
<p>Security multiparts are not supported by <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a>. However, it is possible for applications to use <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> when providing support for crypto messages. For example, the <a href="http://api.kde.org/4.x-api/kdepim-apidocs/messageviewer/html/index.html">messageviewer</a> component in KDEPIM supports signed and encrypted MIME parts, and the <a href="http://websvn.kde.org/trunk/KDE/kdepim/messagecomposer/">messagecomposer</a> library can create such messages.</p>
<p>Signed MIME parts are signed with the private key of the sender, everybody who has the public key of the sender can verifiy the signature. Encrypted MIME parts are encrypted with the public key of the receiver, and only the receiver, who is the sole person possessing the private key, can decrypt it. Sending an encrypted message to multiple recipients therefore means that the message has to be sent multiple times, once for each receiver, as each message needs to be encrypted with a different key.</p>
<dl class="section user"><dt>Signed MIME parts</dt><dd></dd></dl>
<p>A multipart/signed MIME part has exactly two children: The first child is the content that is signed, and the second child is the signature.</p>
<pre class="fragment">From: Thomas McGuire <thomas@domain.com>
Subject: My Subject
Date: Mon, 15 Mar 2010 12:20:16 +0100
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="nextPart2567247.O5e8xBmMpa";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
--nextPart2567247.O5e8xBmMpa
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Simple message
--nextPart2567247.O5e8xBmMpa
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEABECAAYFAkueF/UACgkQKglv3sO8a1MdTACgnBEP6ZUal931Vwu7PyiXT1bn
Zr0Anj4bAI9JhHEDiwA/iwrWGfSC+Nlz
=d2ol
-----END PGP SIGNATURE-----
--nextPart2567247.O5e8xBmMpa--
</pre><pre class="fragment">multipart/signed
|- text/plain
\- application/pgp-signature
</pre><p> The example here uses the OpenPGP format to sign a simply plain text message. Here, the text/plain MIME part is signed, and the application/pgp-signature MIME part contains the signature data, which in this case is ASCII-armored.</p>
<p>As said above, it is possible to sign only some MIME parts. A message which has a image/jpeg attachment that is signed, but a main text part is not signed, has the following MIME structure: </p>
<pre class="fragment">multipart/mixed
|- text/plain
\- multipart/signed
|- image/jpeg
\- application/pgp-signature
</pre><p>It is possible to sign multipart parts as well. Consider the above example that has a plain text part and an image attachment. Those two parts can be signed together, with the following structure: </p>
<pre class="fragment">multipart/signed
|- multipart/mixed
| |- text/plain
| \- image/jpeg
\- application/pgp-signature
</pre><p>Signed messages in the S/MIME format use a different content type for the signature data, like here: </p>
<pre class="fragment">multipart/signed
|- text/plain
\- application/x-pkcs7-signature
</pre><dl class="section user"><dt>Encrypted MIME parts</dt><dd></dd></dl>
<p>Multipart/encrypted MIME parts also have exactly two children: The first child contains metadata about the encrypted data, such as a version number. The second child then contains the actual encrypted data.</p>
<pre class="fragment">From: someone@domain.com
To: Thomas McGuire <thomas@domain.com>
Subject: Encrypted message
Date: Mon, 15 Mar 2010 12:50:16 +0100
MIME-Version: 1.0
Content-Type: multipart/encrypted;
boundary="nextPart2726747.j47xUGTWKg";
protocol="application/pgp-encrypted"
Content-Transfer-Encoding: 7bit
--nextPart2726747.j47xUGTWKg
Content-Type: application/pgp-encrypted
Content-Disposition: attachment
Version: 1
--nextPart2726747.j47xUGTWKg
Content-Type: application/octet-stream
Content-Disposition: inline; filename="msg.asc"
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.14 (GNU/Linux)
hQIOA8p5rdC5CBNfEAf+NZVzVq48C1r5opOOiWV96+FUzIWuMQ6u8fzFgI7YVyCn
[SNIP]
=reNr
--nextPart2726747.j47xUGTWKg--
-----END PGP MESSAGE-----
</pre><pre class="fragment">multipart/encrypted
|- application/pgp-encrypted
\- application/octet-stream
</pre><p>The encrypted data is contained in the <code>application/octet-stream</code> MIME part. Without decrypting the data, it is unknown what the original content type of the encrypted MIME data is! The encrypted data could be a simple text/plain MIME part, an image attachment, or a multipart part. The encrypted data contains both the MIME header and the MIME body of the original MIME part, as the header is needed to know the content type of the data. The data could as well by of content type multipart/signed, in which case the message would be both signed and encrypted.</p>
<dl class="section user"><dt>Inline cryto formats</dt><dd></dd></dl>
<p>Although using the security multiparts <code>multipart/signed</code> and <code>multipart/encrypted</code> is the recommended standard, there are other possibilities to sign or encrypt a message. The most common methods are <b>Inline OpenPGP</b> and <b>S/MIME Opaque</b>.</p>
<p>For inline OpenPGP messages, the crypto data is contained inlined in the actual MIME part. For example, a message with a signed text/plain part might look like this: </p>
<pre class="fragment">From: someone@domain.com
To: someoneelse@domain.com
Subject: Inline OpenPGP test
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Inline OpenPGP signed example.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAkueJ2EACgkQKglv3sO8a1MS3QCfcsYnJG7uYQxzxz6J5cPF7lHz
WIoAn3PjVPlWibu02dfdFObwd2eJ1jAW
=p3uO
-----END PGP SIGNATURE-----</pre><p>Encrypted inline OpenPGP works in a similar way. Opaque S/MIME messages are also similar: For signed MIME parts, both the signature and the signed data are contained in a single MIME part with a content type of <code>application/pkcs7-mime</code>.</p>
<p>As security multiparts are preferred over inline OpenPGP and over opaque S/MIME, I won't go into more detail here.</p>
<h3><a class="anchor" id="misc"></a>
Miscellaneous Points about Messages</h3>
<dl class="section user"><dt>Line Breaks</dt><dd></dd></dl>
<p>Each line in a MIME message has to end with a <b>CRLF</b>, which is a carriage return followed by a newline, which is the escape sequence<code>\r\n</code>. CR and LF may not appear in other places in a MIME message. Special care needs to be taken with encoded linebreaks in binary data, and with distinguishing soft and hard line breaks when converting between different content transfer encodings. For more details, have a look at the RFCs.</p>
<p>While the official format is to have a CRLF at the end of each line, <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> only expects a single LF for its in-memory storage. Therefore, when loading a message from disk or from a server into <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a>, the CRLFs need to be converted to LFs first, for example with <a class="el" href="namespaceKMime.html#af48813804c58b6ffdf18d2bf3dd22066" title="Converts all occurrences of "\r\n" (CRLF) in s to "\n" (LF).">KMime::CRLFtoLF()</a>. The opposite needs to be done when storing a <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> message somewhere.</p>
<p>Lines should not be longer than 78 characters and may not be longer than 998 characters.</p>
<dl class="section user"><dt>Header Folding and CFWS</dt><dd></dd></dl>
<p>Header fields can span multiple lines, which was already shown in some of the examples above where the parameters of the header field value were in the next line. The header field is said to be <b>folded</b> in this case. In general, header fields can be folded whenever whitespace (<b>WS</b>) occurs.</p>
<p>Header field values can contain <b>comments</b>; these comments are semantically invisible and have no meaning. Comments are surrouned by parentheses. </p>
<pre class="fragment">Date: Thu, 13
Feb 1969 23:32 -0330 (Newfoundland Time)
</pre><p>This example shows a folded header that also has a comment (<em>Newfoundland Time</em>). The date header is a structured header field, and therefore it has to obey to a defined syntax; however, adding comments and whitespace is allowed almost anywhere, and they are ignored when parsing the message. Comments and whitespace where folding is allowed is sometimes referred to as <b>CFWS</b>. Any occurence of CFWS is semantically regarded as a single space.</p>
<h1><a class="anchor" id="string-broken-down"></a>
The two in-memory representations of messages</h1>
<p>There are two representations of messages in memory. The first is called <b>string representation</b> and the other one is called <b>broken-down representation</b>.</p>
<p>String representation is somehow misnamed, a better term would be <code>byte array representation</code>. The string representation is just a big array of bytes in memory, and those bytes make up the encoded mail. The string representation is what is stored on disk or what is received from an IMAP server, for example.</p>
<p>With the broken-down representation, the mail is <em>broken down</em> into smaller structures. For example, instead of having a single byte array for all headers, the broken-down structure has a list of individual headers, and each header in that list is again broken down into a structure. While the string representation is just an array of 7 bit characters that might be encoded, the broken-down representations contain the decoded text strings.</p>
<p>As an example, conside the byte array </p>
<pre class="fragment">"Hugo Maier" <hugo.maier@mailer.domain>
</pre><p>Although this is just a bunch of 7 bit characters, a human immediatley recognizes the broken-down structure and sees that the display name is "Hugo Maier" and that the localpart of the email address is "hugo.maier". To illustrate, the broken-down structure could be stored in a structure like this: </p>
<pre class="fragment">struct Mailbox
{
QString displayName;
QByteArray addressSpec;
};
</pre><p> The address spec actually could be broken down further into a localpart and a domain. The process of converting the string representation to a broken-down representation is called <b>parsing</b>, and the reverse is called <b>assembling</b>. Parsing a message is necessary when wanting to access or modify the broken-down structure. For example, when sending a mail, the address spec of a mailbox needs to be passed to the SMTP server, which means that the recipient headers need to be parsed in order to access that information. Another example is the message list in an mail application, where the broken-down structure of a mail is needed to display information like subject, sender and date in the list. On the other hand, assembling a message is for example done in the composer of a mail application, where the mail information is available in a broken-down form in the composer window, and is then assembled into a final MIME message that is then sent with SMTP.</p>
<p>Parsing is often quite tricky, you should always use the methods from <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> instead of writing parsing routines yourself. Even the simple mailbox example above is in pratice difficult to parse, as many things like comments and escaped characters need to be taken into consideration. The same is true for assembling: In the above case, one could be tempted to assemble the mailbox by simply writting code like this: </p>
<pre class="fragment">QByteArray stringRepresentation = '"' + displayName + "\" <" + addressSpec + ">";
</pre><p> However, just like with parsing, you shouldn't be doing assembling yourself. In the above case, for example, the display name might contain non-ASCII characters, and RFC2047 encoding would need to be applied. So use <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> for assembling in all cases.</p>
<p>When parsing a message and assembling it afterwards, the result might not be the same as the original byte array. For example, comments in header fields are ignored during parsing and not stored in the broken-down structure, therefore the assembled message will also not contain comments.</p>
<p>Messages in memory are usually stored in a broken-down structure so that it is easy to to access and manipulate the message. On disk and on servers, messages are stored in string representation.</p>
<h1><a class="anchor" id="classes-overview"></a>
Overview of KMime classes</h1>
<p><a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> has basically two sets of classes: Classes for headers and classes for MIME parts. A MIME part is represented by <code><a class="el" href="classKMime_1_1Content.html" title="A class that encapsulates MIME encoded Content.">KMime::Content</a></code>. A Content can be parsed from a string representation and also be assembled from the broken-down representation again. If parsed, it has a list of sub-contents (in case of multipart contents) and a list of headers. If the Content is not parsed, it stores the headers and the body in a byte array, which can be accessed with head() and body(). There is also a class <code><a class="el" href="classKMime_1_1Message.html" title="Represents a (email) message.">KMime::Message</a></code>, which basically is a thin wrapper around Content for the top-level MIME part. Message also contains convenience methods to access the message headers.</p>
<p>For headers, there is a class hierachy, with <code><a class="el" href="classKMime_1_1Headers_1_1Base.html" title="Baseclass of all header-classes.">KMime::Headers::Base</a></code> as the base class, and <code><a class="el" href="classKMime_1_1Headers_1_1Generics_1_1Structured.html" title="Base class for structured header fields.">KMime::Headers::Generics::Structured</a></code> and <code><a class="el" href="classKMime_1_1Headers_1_1Generics_1_1Unstructured.html" title="Abstract base class for unstructured header fields (e.g.">KMime::Headers::Generics::Unstructured</a></code> in the next levels. Unstructured is for headers that don't have a defined structure, like Subject, whereas Structured headers have a specific structure, like Date. The header classes have methods to parse headers, like from7BitString(), and to assemble them, like as7BitString(). Once a header is parsed, the classes provide access to the broken-down structures, for example the Date header has a method dateTime(). The parsing in from7BitString() is usually handled by a protected parse() function, which in turn call parsing functions for different types, like parseAddressList() or parseAddrSpec() from the <code>KMime::HeaderParsing</code> namespace.</p>
<p>When modifing messages, the message is first parsed into a broken-down representation. This broken-down representation can then be accessed and modified with the appropriate functions. After changing the broken-down structure, it needs to be assembled again to get the modified string representation.</p>
<p><a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a> also comes with some codes for handling base64 and quoted-printable encoding, with <code><a class="el" href="classKMime_1_1Codec.html" title="An abstract base class of codecs for common mail transfer encodings.">KMime::Codec</a></code> as the base class.</p>
<h1><a class="anchor" id="rfcs"></a>
RFCs</h1>
<ul>
<li><a href="http://tools.ietf.org/html/rfc5322">RFC 5322</a>: Internet Message Format </li>
<li><a href="http://tools.ietf.org/html/rfc5536">RFC 5536</a>: Netnews Article Format </li>
<li><a href="http://tools.ietf.org/html/rfc2045">RFC 2045</a>: Multipurpose Internet Mail Extensions (MIME), Part 1: Format of Internet Message Bodies </li>
<li><a href="http://tools.ietf.org/html/rfc2046">RFC 2046</a>: Multipurpose Internet Mail Extensions (MIME), Part 2: Media Types </li>
<li><a href="http://tools.ietf.org/html/rfc2047">RFC 2047</a>: Multipurpose Internet Mail Extensions (MIME), Part 3: Message Header Extensions for Non-ASCII Text </li>
<li><a href="http://tools.ietf.org/html/rfc2048">RFC 2048</a>: Multipurpose Internet Mail Extensions (MIME), Part 4: Registration Procedures </li>
<li><a href="http://tools.ietf.org/html/rfc2049">RFC 2049</a>: Multipurpose Internet Mail Extensions (MIME), Part 5: Conformance Criteria and Examples </li>
<li><a href="http://tools.ietf.org/html/rfc2231">RFC 2231</a>: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations </li>
<li><a href="http://tools.ietf.org/html/rfc2183">RFC 2183</a>: Communicating Presentation Information in Internet Message: The Content-Disposition Header Field </li>
<li><a href="http://tools.ietf.org/html/rfc2557">RFC 2557</a>: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) </li>
<li><a href="http://tools.ietf.org/html/rfc1847">RFC 1847</a>: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted </li>
<li><a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a>: S/MIME Version 3 Message Specification </li>
<li><a href="http://tools.ietf.org/html/rfc3156">RFC 3156</a>: MIME Security with OpenPGP </li>
<li><a href="http://tools.ietf.org/html/rfc2298">RFC 2298</a>: An Extensible Message Format for Message Disposition Notifications </li>
<li><a href="http://tools.ietf.org/html/rfc2646">RFC 2646</a>: The Text/Plain Format Parameter (not supported by <a class="el" href="namespaceKMime.html" title="Contains all the KMIME library global classes, objects, and functions.">KMime</a>)</li>
</ul>
<h1><a class="anchor" id="links"></a>
Further Reading</h1>
<ul>
<li><a href="http://en.wikipedia.org/wiki/MIME">Wikipedia article on MIME</a><br/>
</li>
<li><a href="http://www.joelonsoftware.com/articles/Unicode.html">The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)</a> </li>
<li><a href="http://www.cs.tut.fi/~jkorpela/chars.html">A tutorial on character code issues</a> </li>
<li><a href="http://www.motobit.com/util/base64-decoder-encoder.asp">Online Base64 encoder and decoder</a> </li>
<li><a href="http://www.motobit.com/util/quoted-printable-encoder.asp">Online quoted-printable encoder</a> </li>
<li><a href="http://www.motobit.com/util/quoted-printable-decoder.asp">Online quoted-printable decoder</a> </li>
<li><a href="http://www.motobit.com/util/charset-codepage-conversion.asp">Online charset converter</a> </li>
<li><a href="http://en.wikipedia.org/wiki/Public-key_cryptography">Wikipedia article on public-key cryptography</a></li>
</ul>
<dl class="authors"><dt><b><a class="el" href="authors.html#_authors000025">Author(s):</a></b></dt><dd></dd></dl>
<p>The major authors of this library are: </p>
<ul>
<li>Christian Gebauer </li>
<li>Volker Krause <<a href="#" onclick="location.href='mai'+'lto:'+'vkr'+'au'+'se@'+'kd'+'e.o'+'rg'; return false;">vkrau<span style="display: none;">.nosp@m.</span>se@k<span style="display: none;">.nosp@m.</span>de.or<span style="display: none;">.nosp@m.</span>g</a>> </li>
<li>Marc Mutz <<a href="#" onclick="location.href='mai'+'lto:'+'mut'+'z@'+'kde'+'.o'+'rg'; return false;">mutz@<span style="display: none;">.nosp@m.</span>kde.<span style="display: none;">.nosp@m.</span>org</a>> </li>
<li>Christian Thurner <<a href="#" onclick="location.href='mai'+'lto:'+'cth'+'ur'+'ner'+'@f'+'ree'+'pa'+'ge.'+'de'; return false;">cthur<span style="display: none;">.nosp@m.</span>ner@<span style="display: none;">.nosp@m.</span>freep<span style="display: none;">.nosp@m.</span>age.<span style="display: none;">.nosp@m.</span>de</a>> </li>
<li>Tom Albers <<a href="#" onclick="location.href='mai'+'lto:'+'tom'+'al'+'ber'+'s@'+'kde'+'.n'+'l'; return false;">tomal<span style="display: none;">.nosp@m.</span>bers<span style="display: none;">.nosp@m.</span>@kde.<span style="display: none;">.nosp@m.</span>nl</a>> </li>
<li>Thomas McGuire <<a href="#" onclick="location.href='mai'+'lto:'+'mcg'+'ui'+'re@'+'kd'+'e.o'+'rg'; return false;">mcgui<span style="display: none;">.nosp@m.</span>re@k<span style="display: none;">.nosp@m.</span>de.or<span style="display: none;">.nosp@m.</span>g</a>></li>
</ul>
<p>This document was written by:<br/>
</p>
<ul>
<li>Thomas McGuire <<a href="#" onclick="location.href='mai'+'lto:'+'mcg'+'ui'+'re@'+'kd'+'e.o'+'rg'; return false;">mcgui<span style="display: none;">.nosp@m.</span>re@k<span style="display: none;">.nosp@m.</span>de.or<span style="display: none;">.nosp@m.</span>g</a>></li>
</ul>
<dl class="maintainers"><dt><b><a class="el" href="maintainers.html#_maintainers000001">Maintainer(s):</a></b></dt><dd></dd></dl>
<ul>
<li>Volker Krause <<a href="#" onclick="location.href='mai'+'lto:'+'vkr'+'au'+'se@'+'kd'+'e.o'+'rg'; return false;">vkrau<span style="display: none;">.nosp@m.</span>se@k<span style="display: none;">.nosp@m.</span>de.or<span style="display: none;">.nosp@m.</span>g</a>> </li>
<li>Marc Mutz <<a href="#" onclick="location.href='mai'+'lto:'+'mut'+'z@'+'kde'+'.o'+'rg'; return false;">mutz@<span style="display: none;">.nosp@m.</span>kde.<span style="display: none;">.nosp@m.</span>org</a>></li>
</ul>
<dl class="licenses"><dt><b><a class="el" href="licenses.html#_licenses000001">License(s):</a></b></dt><dd><a href="http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC1">LGPLv2</a></dd></dl>
</div></div><!-- contents -->
<div class="copyrights">
This file is part of the KDE documentation.<br/>
Documentation copyright © 1996-2013 The KDE developers.<br/>
Generated on Fri Jul 12 2013 16:48:20 by
<a href="http://www.doxygen.org/index.html">doxygen</a> 1.8.3.1 written
by <a href="mailto:dimitri@stack.nl">Dimitri van Heesch</a>, © 1997-2006
<p>
KDE's <a href="http://techbase.kde.org/Policies/Library_Documentation_Policy">Doxygen guidelines</a> are available online.
</p>
</div>
</div>
</div>
</div>
<div id="left">
<div class="menu_box">
<a name="cp-menu" /><div class="menutitle"><div>
<h2 id="cp-menu-project">KMIME Library</h2>
<a href="#cp-skip-project" class="cp-doNotDisplay">Skip menu "KMIME Library"</a>
</div></div>
<ul><li><a href="index.html">Main Page</a></li><li><a href="namespaces.html">Namespace List</a></li><li><a href="namespacemembers.html">Namespace Members</a></li><li><a href="classes.html">Alphabetical List</a></li><li><a href="annotated.html">Class List</a></li><li><a href="hierarchy.html">Class Hierarchy</a></li><li><a href="functions.html">Class Members</a></li><li><a href="files.html">File List</a></li><li><a href="pages.html">Related Pages</a></li></ul>
<!--
<h2>Class Picker</h2>
<div style="text-align: center;">
<form name="guideform">
<select name="guidelinks" style="width:100%;" onChange="window.location=document.guideform.guidelinks.options[document.guideform.guidelinks.selectedIndex].value">
<option value="annotated.html">-- Choose --</option>
<option value="classKMime_1_1Base64Codec.html">kmime::base64codec</option>, <option value="classKMime_1_1BinaryCodec.html">kmime::binarycodec</option>, <option value="classKMime_1_1BoolFlags.html">kmime::boolflags</option>, <option value="classKMime_1_1CharFreq.html">kmime::charfreq</option>, <option value="classKMime_1_1Codec.html">kmime::codec</option>, <option value="classKMime_1_1Content.html">kmime::content</option>, <option value="classKMime_1_1ContentIndex.html">kmime::contentindex</option>, <option value="classKMime_1_1DateFormatter.html">kmime::dateformatter</option>, <option value="classKMime_1_1Decoder.html">kmime::decoder</option>, <option value="classKMime_1_1EightBitCodec.html">kmime::eightbitcodec</option>, <option value="classKMime_1_1Encoder.html">kmime::encoder</option>, <option value="classKMime_1_1HeaderFactory.html">kmime::headerfactory</option>, <option value="classKMime_1_1Headers_1_1Base.html">kmime::headers::base</option>, <option value="classKMime_1_1Headers_1_1Bcc.html">kmime::headers::bcc</option>, <option value="classKMime_1_1Headers_1_1Cc.html">kmime::headers::cc</option>, <option value="classKMime_1_1Headers_1_1ContentDescription.html">kmime::headers::contentdescription</option>, <option value="classKMime_1_1Headers_1_1ContentDisposition.html">kmime::headers::contentdisposition</option>, <option value="classKMime_1_1Headers_1_1ContentID.html">kmime::headers::contentid</option>, <option value="classKMime_1_1Headers_1_1ContentLocation.html">kmime::headers::contentlocation</option>, <option value="classKMime_1_1Headers_1_1ContentTransferEncoding.html">kmime::headers::contenttransferencoding</option>, <option value="classKMime_1_1Headers_1_1ContentType.html">kmime::headers::contenttype</option>, <option value="classKMime_1_1Headers_1_1Control.html">kmime::headers::control</option>, <option value="classKMime_1_1Headers_1_1Date.html">kmime::headers::date</option>, <option value="classKMime_1_1Headers_1_1FollowUpTo.html">kmime::headers::followupto</option>, <option value="classKMime_1_1Headers_1_1From.html">kmime::headers::from</option>, <option value="classKMime_1_1Headers_1_1Generic.html">kmime::headers::generic</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1Address.html">kmime::headers::generics::address</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1AddressList.html">kmime::headers::generics::addresslist</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1DotAtom.html">kmime::headers::generics::dotatom</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1Ident.html">kmime::headers::generics::ident</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1MailboxList.html">kmime::headers::generics::mailboxlist</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1Parametrized.html">kmime::headers::generics::parametrized</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1PhraseList.html">kmime::headers::generics::phraselist</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1SingleIdent.html">kmime::headers::generics::singleident</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1SingleMailbox.html">kmime::headers::generics::singlemailbox</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1Structured.html">kmime::headers::generics::structured</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1Token.html">kmime::headers::generics::token</option>, <option value="classKMime_1_1Headers_1_1Generics_1_1Unstructured.html">kmime::headers::generics::unstructured</option>, <option value="classKMime_1_1Headers_1_1InReplyTo.html">kmime::headers::inreplyto</option>, <option value="classKMime_1_1Headers_1_1Keywords.html">kmime::headers::keywords</option>, <option value="classKMime_1_1Headers_1_1Lines.html">kmime::headers::lines</option>, <option value="classKMime_1_1Headers_1_1MailCopiesTo.html">kmime::headers::mailcopiesto</option>, <option value="classKMime_1_1Headers_1_1MessageID.html">kmime::headers::messageid</option>, <option value="classKMime_1_1Headers_1_1MIMEVersion.html">kmime::headers::mimeversion</option>, <option value="classKMime_1_1Headers_1_1Newsgroups.html">kmime::headers::newsgroups</option>, <option value="classKMime_1_1Headers_1_1Organization.html">kmime::headers::organization</option>, <option value="classKMime_1_1Headers_1_1References.html">kmime::headers::references</option>, <option value="classKMime_1_1Headers_1_1ReplyTo.html">kmime::headers::replyto</option>, <option value="classKMime_1_1Headers_1_1ReturnPath.html">kmime::headers::returnpath</option>, <option value="classKMime_1_1Headers_1_1Sender.html">kmime::headers::sender</option>, <option value="classKMime_1_1Headers_1_1Subject.html">kmime::headers::subject</option>, <option value="classKMime_1_1Headers_1_1Supersedes.html">kmime::headers::supersedes</option>, <option value="classKMime_1_1Headers_1_1To.html">kmime::headers::to</option>, <option value="classKMime_1_1Headers_1_1UserAgent.html">kmime::headers::useragent</option>, <option value="classKMime_1_1IdentityCodec.html">kmime::identitycodec</option>, <option value="classKMime_1_1KAutoDeleteHash.html">kmime::kautodeletehash</option>, <option value="classKMime_1_1Message.html">kmime::message</option>, <option value="classKMime_1_1Parser_1_1MultiPart.html">kmime::parser::multipart</option>, <option value="classKMime_1_1Parser_1_1NonMimeParser.html">kmime::parser::nonmimeparser</option>, <option value="classKMime_1_1Parser_1_1UUEncoded.html">kmime::parser::uuencoded</option>, <option value="classKMime_1_1Parser_1_1YENCEncoded.html">kmime::parser::yencencoded</option>, <option value="classKMime_1_1QuotedPrintableCodec.html">kmime::quotedprintablecodec</option>, <option value="classKMime_1_1Rfc2047BEncodingCodec.html">kmime::rfc2047bencodingcodec</option>, <option value="classKMime_1_1Rfc2047QEncodingCodec.html">kmime::rfc2047qencodingcodec</option>, <option value="classKMime_1_1Rfc2231EncodingCodec.html">kmime::rfc2231encodingcodec</option>, <option value="classKMime_1_1SevenBitCodec.html">kmime::sevenbitcodec</option>, <option value="classKMime_1_1Types_1_1Mailbox.html">kmime::types::mailbox</option>, <option value="classKMime_1_1UUCodec.html">kmime::uucodec</option>,
</select>
</form>
</div>
-->
<div class="menu_box">
<a name="cp-menu" /><div class="menutitle"><div>
<h2 id="cp-menu-project">kdepimlibs-4.10.5 API Reference</h2>
<a href="#cp-skip-project" class="cp-doNotDisplay">Skip menu "kdepimlibs-4.10.5 API Reference"</a>
</div></div>
<div class="nav_list">
<ul>
<li><a href="../../akonadi/html/index.html">akonadi</a></li><li> <a href="../../akonadi/contact/html/index.html">contact</a></li><li> <a href="../../akonadi/kmime/html/index.html">kmime</a></li><li> <a href="../../akonadi/socialutils/html/index.html">socialutils</a></li><li><a href="../../kabc/html/index.html">kabc</a></li><li><a href="../../kalarmcal/html/index.html">kalarmcal</a></li><li><a href="../../kblog/html/index.html">kblog</a></li><li><a href="../../kcal/html/index.html">kcal</a></li><li><a href="../../kcalcore/html/index.html">kcalcore</a></li><li><a href="../../kcalutils/html/index.html">kcalutils</a></li><li><a href="../../kholidays/html/index.html">kholidays</a></li><li><a href="../../kimap/html/index.html">kimap</a></li><li><a href="../../kioslave/html/index.html">kioslave</a></li><li> <a href="../../kioslave/imap4/html/index.html">imap4</a></li><li> <a href="../../kioslave/mbox/html/index.html">mbox</a></li><li> <a href="../../kioslave/nntp/html/index.html">nntp</a></li><li><a href="../../kldap/html/index.html">kldap</a></li><li><a href="../../kmbox/html/index.html">kmbox</a></li><li><a href="../../kmime/html/index.html">kmime</a></li><li><a href="../../kontactinterface/html/index.html">kontactinterface</a></li><li><a href="../../kpimidentities/html/index.html">kpimidentities</a></li><li><a href="../../kpimtextedit/html/index.html">kpimtextedit</a></li><li><a href="../../kpimutils/html/index.html">kpimutils</a></li><li><a href="../../kresources/html/index.html">kresources</a></li><li><a href="../../ktnef/html/index.html">ktnef</a></li><li><a href="../../kxmlrpcclient/html/index.html">kxmlrpcclient</a></li><li><a href="../../mailtransport/html/index.html">mailtransport</a></li><li><a href="../../microblog/html/index.html">microblog</a></li><li><a href="../../qgpgme/html/index.html">qgpgme</a></li><li><a href="../../syndication/html/index.html">syndication</a></li><li> <a href="../../syndication/atom/html/index.html">atom</a></li><li> <a href="../../syndication/rdf/html/index.html">rdf</a></li><li> <a href="../../syndication/rss2/html/index.html">rss2</a></li>
</ul></div></div>
<!-- api_searchbox -->
</div>
</div>
<div class="clearer"></div>
</div>
<div class="clearer"></div>
</div>
<div id="end_body"></div>
<div id="footer"><div id="footer_text">
Report problems with this website to <a href="https://bugs.kde.org/enter_sysadmin_request.cgi?component=api.kde.org">our bug tracking system</a>.<br>
Contact the specific authors with questions and comments about the page contents.<p>
KDE<sup>®</sup> and <a href="/media/images/kde_gear_black.png">the K Desktop Environment<sup>®</sup> logo</a> are registered trademarks of <a href="http://ev.kde.org/" title="Homepage of the KDE non-profit Organization">KDE e.V.</a> |
<a href="http://www.kde.org/contact/impressum.php">Legal</a></p>
</div></div>
</div>
<!--
WARNING: DO NOT SEND MAIL TO THE FOLLOWING EMAIL ADDRESS! YOU WILL
BE BLOCKED INSTANTLY AND PERMANENTLY!
<a href="mailto:aaaatrap-45abe0e0c3bebc77@kde.org">Block me</a>
WARNING END
-->
</body>
</html>
