Neben den bekannten "PGP/INLINE" signierten oder verschlüsselten Nachrichten, wo der Ciphertext, bzw. die Signatur immer den gesamten Body einer Nachricht darstellt, besteht die nach PGP/MIME signierte oder verschlüsselte Nachricht aus mehreren MIME Anteilen.
PGP/MIME sollte zum Versand verschlüsselter und/oder signierter E-Mails bevorzugt eingesetzt werden.

Beispiel: PGP/INLINE signierte Nachricht mit Anhang. Die Signatur wird um den Nachrichtenkörper gelegt im Nachrichtenkörper transportiert. Die angehängte Datei bleibt unsigniert, bzw. müsste vor der Beifügung gesondert mit GnuPG signiert werden.



Beispiel: PGP/MIME signierte Nachricht mit Anhang. Die Signatur wird getrennt vom Nachrichtenkörper in einem eigenen Anhang gespeichert. Angehängte Dateien werden automatisch mitsigniert, die Signatur ebenfalls in einem eigenen Anhang gespeichert.

PGP/MIME basiert auf drei IETF Standardentwürfen (sog. Drafts), bzw.Standards:

• RFC 4880 "OpenPGP Message Format" (ersetzt RFC 2440)
  beschreibt die Methoden und den Aufbau OpenPGP verschlüsselter, bzw. signierter Daten
• RFC 3156 "MIME Security with Pretty Good Privacy (PGP)" (löst RFC 2015 "MIME Security with Pretty Good Privacy (PGP)" ab),
  RFC 3156 "übersetzt" die im RFC 1847 "Security Multiparts for MIME Multipart/Signed and Multipart/Encrypted" definierten MIME Inhaltstypen in OpenPGP spezifische Inhaltstypen zur Verschlüsselung und Signierung und führt dadurch die drei Subtypen "application/pgp-encrypted", "application/pgp-signature" und "application/pgp-keys" ein.
  
  MIME steht für "Multipurpose Internet Mail Extensions" und definiert grundlegend das Format, das E-Mail Nachrichten zur Übertragung von textuellen und nicht-textuellen Bodyinhalten aufweisen.
  Nach RFC 822 Standard for the format of ARPA internet text messages besteht eine Nachricht nur aus Text, der aus 7-Bit Zeichen des US-ASCII Zeichensatzes besteht. Eine Nachricht enthält danach weder Umlaute, bzw. sprachspezifische Zeichen noch andere 8-Bit Zeichen, wie sie in multimedialen, binären Inhalten wie Audio- oder Videodaten vorkommen.
  Um diese Beschränkungen aufzuheben, wurden Codierungsanweisungen für verschiedene Nachrichteninhalte festgelegt, die im Header einer E-Mail in mehreren Feldern festgehalten werden:
  Ein Feld gibt die MIME-Version an, das Content-Type Feld die Art des Inhalts und das Content-Transfer-Encoding Feld das verwendete Kodierungsverfahren. Über den Content-Type: Multipart kann der Nachrichtenbody in mehrere Abschnitte verschiedenen Inhalts unterteilt werden. Es ist auch möglich, eigene Nachrichteninhaltstypen zu definieren.
  
  RFC 1847 definiert also, wie per MIME und E-Mail verschlüsselte und signierte Bodyinhalte formatiert werden, RFC 3156 wie das mittels OpenPGP geschieht.

Somit stellt PGP/MIME den eigentlichen Standard für die Übertragung von Nachrichten dar, die mit OpenPGP kompatiblen Programmen wie GnuPG oder PGP signiert und/oder verschlüsselt werden.
Neben der Standardkonformität und problemloseren Handhabung von Codierungen und Zeichensätzen bietet PGP/MIME den Vorteil der automatischen Mitverschlüsselung von Anhängen. Bei dem INLINE Verfahren müssen Anhänge gesondert verschlüsselt werden, wenn der E-Mail Client nicht einen eigenen Automatismus anbietet. Daneben erleichtert die "Auslagerung" der Signatur aus dem Mailbody das Lesen und Beantworten von E-Mails.

Leider ist die Unterstützung und die Bekanntheit von PGP/MIME abhängig davon, ob die Hersteller von E-Mail Clients PGP/MIME implementieren.
Wird PGP/MIME bei den Linux Mailclients weitestgehend abgedeckt, steht dies bei einigen Mail Clients unter Windows noch aus. Das ist auch der Grund, warum viele User derartiger Mail Clients mit PGP/MIME konformen Nachrichten zuerst nichts anfangen können.
Auf folgenden Sites finden sich Übersichten zum Grad der PGP/MIME Unterstützung bei verschiedenen E-Mail Clients:

• Mail readers with PGP/MIME RFC 2015 / RFC 3156 support
• Secure email-clients with PGP/MIME

Einige E-Mail Clients setzen RFC 3156 nicht korrekt um, was die Behandlung von Leerraum an Zeilenenden betrifft.
RFC 3156 schreibt vor, dass dieser Leerraum von Anwendungen bei der Signierung mit PGP/MIME erhalten, bzw. geschützt werden muss. Die fehlerhaften E-Mail Clients entfernen im Gegensatz dazu während der Signierung den Leerraum, was wiederum bei der Signaturprüfung auf der Gegenseite die Angabe einer falschen, d. h. nicht als echt zu prüfenden Signatur bei den E-Mail Clients erzeugt, die RFC 3156 korrekt umsetzen.

Um mit den E-Mail Clients korrekt zu verifizierende Signaturen zu erzeugen, bis die Entwickler ihren E-Mail Client gefixt haben, kann man in der GnuPG Konfigurationsdatei gpg.conf die Option rfc2440-text setzen.

Um den eigenen E-Mail Client auf die korrekte Anwendung von RFC 3156 zu überprüfen, geht man wie folgt vor:

1. Setzen der Option no-rfc2440-text in der gpg.conf
2. An sich selbst adressierte E-Mail verfassen, die Zeilen mit Lerrräumen an Zeilenenden enthält.
3. Ersetzen der obigen Option durch rfc2440-text in der gpg.conf
4. Verifizierung der Signatur. Wenn die Signatur bei der Prüfung als falsch deklariert wird, muss der E-Mail Client gefixt und bis dahin die Option rfc2440-text verwendet werden.

Die Daten, die per PGP/MIME verschlüsselt werden, bzw. die mittels PGP/MIME erzeugten Signaturen liegen zuerst als 8-bit binärer Output vor.
Um eine Beschädigung der Signatur durch Mail Gateways zu verhindern, werden die Daten mittels quoted-printable oder Base64 nachträglich in 7-bit umcodiert.

eine OpenPGP PGP/MIME verschlüsselte Nachricht besteht aus einem speziellen Header und zwei Body Anteilen:

1. im Header der Nachricht wird in der Headerzeile
   Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
   boundary="string"
   der MIME Inhaltstyp nach RFC 1847 bestimmt und über den Protokoll Parameter der Subtyp, der auf den ersten Teil des Bodys verweist. Die boundary Angabe verweist auf, bzw. begrenzt mit einer beliebigen Zeichenkette den Bereich der E-Mail Nachricht, der die verschlüsselten Anteile enthält.
2. Der erste Body Anteil [application/pgp-encrypted] enthält die Kontrollinformationen, bzw. -anweisungen, die eigentlich nur aus der "Version: 1" Angabe bestehen, da alle weiteren Informationen in den Paketen der OpenPGP Verschlüsselung gespeichert sind .
3. Der zweite Body Anteil [application/octet-stream] enthält die eigentlichen Daten, die verschlüsselt wurden.

1. Im Header der Nachricht wird in der Headerzeile
   Content-Type: multipart/signed; protocol="application/pgp-signature";
   micalg="pgp-ripemd160"; boundary="string"
   der MIME Inhaltstyp nach RFC 1847 bestimmt, über den Protokoll Parameter der Subtyp der auf den Body Anteil verweist und über den micalg (Message Integrity Check Algorithm) Parameter der verwendete Digest Algorithmus (in diesem Beispiel RIPEMD160)
2. Der erste Body Anteil besteht aus der Nachricht in Klarform, die signiert wurde
3. Der zweite Body Anteil [application/pgp-signature] enthält die eigentliche Signatur.

Bei einer Kombination aus Verschlüsselung und Signierung wird die Nachricht entweder zuerst signiert und danach die Nachricht mit der Signatur in eine Verschlüsselung eingekapselt, so dass nach der Entschlüsselung eine nachträgliche Verifizierung vorgenommen wird oder Signierung und Verschlüsselung werden in einer Nachricht parallel durch- und zusammengeführt.