-
Notifications
You must be signed in to change notification settings - Fork 32
Standards (RFCs)
Here are all the standards that Scramble aims to implement.
SMTP - RFC 2821
SMTP Email - RFC 5322
MIME - RFC 2045
MIME Types - RFC 2046
MIME Non-Ascii Encoding - RFC 2047
To illustrate how they all fit together, here's what it looks like to receive a single plaintext email. We start with a Scramble server, listening for SMTP connections on port 25. Someone connects.
The SMTP protocol is defined by RFC 2821:
HELO
MAIL-FROM:<sender@sender.org>
RCPT-TO:<alice@scramble.io>
RCPT-TO:<bob@scramble.io>
DATA
The entire email comes next, in a format described by RFC 5322:
From: "El Sendero" <sender@sender.org>
To: "Alice" <alice@scramble.io>, "Bob" <bob@scramble.io>
Subject: Sup?
Content-Type: text/plain
The after the last email header, there's a blank line, followed by the email body. When the Content-Type is text/plain, interpreting the body is straightforward. In the real world, it's often multipart/alternative, so you'll need RFC 2045 and RFC 2046 to parse it.
Occasionally, you get email where the subject is not ASCII, for example
Subject: =?UTF-8?Q?Can_you_make_[Special_Event]?= _DevBeat_2013_�_Nov_12-13th?
You'll need RFC 2047 to parse those.
Finally, we've received and decoded the email.
OpenPGP - RFC 4880
OpenPGP S/MIME - RFC 3156
For the S/MIME extensions (for example, Content-Type: application/pgp-encrypted) see RFC 3156. Note that most PGP email is sent with Content-Type: text/plain. You cannot rely on Content-Type to determine whether incoming email is encrypted or not.
Either the email arrives in plain text--in which case we encrypt it with each recipient's public key before we store it--or it is already PGP-encrypted. Either way, the client later downloads the decrypts all new mail. To understand how PGP works--encrypting, signing, verifying, decrypting, and ASCII armoring--see RFC 4880.