Dipl.-Inform. Carsten Eilers

PGP/INLINE wird von PGP/GnuPG verwendet und im OpenPGP Message Format Standard in RFC 4880 standardisiert. Der Text der E-Mail (nur reiner Text, HTML wird nicht unterstützt) wird als sog, "ASCII Armor" kodiert und im Body der Mail übertragen.

Bei PGP/INLINE ist eine Kodierung verschlüsselter E-Mail-Anhänge in einer Nachricht nicht vorgesehen. Die Anhänge können jedoch einzeln verschlüsselt und als ASCII-Armor kodiert werden. Da es möglich ist, mehrere PGP/INLINE-kodierte Nachrichten in einem E-Mail-Body zu übertragen, können die Anhänge auf diesem Weg gesendet werden. Der Empfänger muss die Nachrichten dann einzeln dekodieren.

Unverschlüsselte Anhänge können nach MIME-Standard mit einer PGP/INLINE-Nachricht kombiniert werden. Ein Beispiel für eine PGP/INLINE-kodierte E-Mail sehen Sie in Listing 1.

Listing 1: Eine PGP/INLINE-kodierte E-Mail

Return-Path: <absender@absender-domain.example>
Delivered-To: empfaenger@empfaenger-domain.example
Received: from mail.absender-domain.example (mail.absender-domain.example [1.2.3.4])
    by mail.empfaenger-domain.example (Postfix) with ESMTPS id 9C3271AC8D10
    for <empfaenger@empfaenger-domain.example.com>; Wed, 20 Jun 2018 14:03:13 +0200 (CEST)
Message-ID: <602F47E5-81C0-4981-9729-354A32783CC7@absender-domain.example>
Date: Wed, 20 Jun 2018 14:03:12 +0200
From: Absender <absender@absender-domain.example>
Subject: PGP/INLINE-Testmail
To: Empfaenger <empfaenger@empfaenger-domain.example>
User-Agent: SupertollerMailClient 1.23
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
 
-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1
Version: GnuPG v1.5.0 (GNU/Hurd)

s0mUqvi4eM3IyLmXvKp7zVTTwEU6SbwXwqNTuBwcn/aNQe6lTj+u26Bd7+kmEH02
Lj0tgPf/I08z12LUJjyVXw4M/rSsP6+4A5b7RzbzJkrcpLN24iB/IcT0g1+HdLJF
[...]
64GCZ+4m0cSvQnGqQbYRqMiaIF9WOhSQDXR4KndYSc8/jiV2D+Ru5JH8j8Zgih9R
OV9stlO90PPvd01fhaOPhfrRs/Awt61Av9ZTqO/dozl33FMW
=1xPs
-----END PGP MESSAGE-----

MIME

Der ursprüngliche E-Mail-Standard RFC 822 legte fest, dass eine E-Mail nur aus Text aus den 7-Bit-Zeichen des US-ASCII Zeichensatzes besteht. Eine E-Mail-Nachricht darf demnach keine 8-Bit-Zeichen enthalten, also weder sprachspezifische Zeichen wie z.B. Umlaute noch Binärdaten wie Grafiken, Audio- oder Videodaten. Anfangs reichte das, aber nicht lange. Daher musste das Nachrichtenformat erweitert werden. Diese Erweiterung sind die "Multipurpose Internet Mail Extensions", kurz MIME. Darin wird in mehreren RFCs definiert, wie Texte und Binärdaten für die Übertragung per E-Mail kodiert werden müssen. Es wurden Kodierungsanweisungen für verschiedene Nachrichteninhalte festgelegt, die im Kopf einer E-Mail in mehreren Headern festgehalten werden:

• Ein MIME-Version Header gibt die MIME-Version an,
• der Content-Type Header die Art des Inhalts und
• der Content-Transfer-Encoding Header das verwendete Kodierungsverfahren.

Über den Content-Type: Multipart kann der Body der Mail in mehrere Abschnitte mit verschiedenen Inhalten unterteilt werden. Es ist auch möglich, eigene Nachrichteninhaltstypen zu definieren. Hier relevant ist vor allem RFC 1847 ("Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"). Darin wird allgemein definiert, wie signierte und/oder verschlüsselte Daten im MIME-Format kodiert werden müssen.

In den nächsten beiden Folgen werden zwei konkrete Umsetzung davon vorgestellt: PGP/MIME und S/MIME.

Carsten Eilers