From A to B
Email, more exact internet mail, is an asynchronous technical system to transfer messages. Asynchronous means that the sender and the receiver of a message must not be on the internet at the same time. A synchronous proceeding is for instance the invocation of an internet page. This works because internet servers are available at all times.
Synchronous proceedings mean direct communication between computers, asynchronous proceedings always mean storing of information on servers at least until somebody requests them.
An email comes to life when it is created within a MUA (mail user agent) which may be your browser or a specialized email client (which is mostly mightier and more comfortable than browser based clients, concerning archiving and fashioning your texts or managing your partner's addresses).
How do MUAs work?
1. You author an email and name a receptor.
Your MUA will connect to a special internet server that was designed to transport emails (MTA mail transport agent). To transmit your message the MTA needs some information, at least the receptor's address. To avoid usage of MTAs by anybody your email program has to identify your(it)self as an authorized user who is permitted to send mails. Sending emails is ruled in SMTP (send mail transfer protocol). Accordingly a SMTP server is an internet server to send or transmit mails.
2. Your email client transfers your email to a SMTP server on the internet. You have to authenticate yourself to the server to ensure that you are a legal user (login and password).
Today it is usual to use transport security routines. You do not have to think about these things, it is mostly proceeded automatically between the servers involved. If transport security is not realizable between these servers the connections will proceed unsecured. Any connection between servers requires a new security agreement. Within the nodes (transmitting servers) of the internet the encryption must be dissolved and newly agreed upon between the servers.
Now your SMTP server will transmit your message. Sometimes this may happen directly, sometimes there have to be engaged more than one node. The way an email has to go is a task that is handled by routers. The router that is engaged at first, your SMTP server, decides about the next useful node on the internet to transmit your message. If you send an email from Germany to an US receptionist the first node will be a central relay in Germany and the next a central relay in the USA. These relays are already MTAs and their communication is ruled by SMTP.
The final destination of your mail is the server whose address you have stated afterwards the "@" of the mail address e.g. "lamprecht-software.de" or "gmx.de". The transport of mails to the final server will be proceeded by synchronous processes. The instances involved are permanently online.
3. Your mail will be transmitted to the server that keeps the recipient's email account.
The servers involved in transmission of your mail will add some information about the ways your mail goes to the header of the email. You will find them under the topic "Received: from …". Be aware: This information can be fake as criminals might have programmed their own MTA or they might have copied serious "Received: …"-entries into their phishing projects.
On the recipient's server or on the servers of an email provider works a MDA (Mail Delivery Agent). Its task is delivering incoming mails to the named addresses. In practice it stores the incoming mails within directories the recipient has access to. Any encryption up till now has been used to secure the transport of the mail will be dissolved in this moment. The email now waits to be fetched or deleted by the authorized recipient.
4. The final server keeps the mail.
To get your mails you can choose between two established protocols, IMAP (= Internet Mail Access Protocol) and POP3 (= Post Office Protocol).
If you use IMAP you will hold your mails on the server and access them if required. You may build archive structures on the server, so you can create folders and subfolders, delete emails from the server etc. Mail clients supporting IMAP just map the structure established on the server. Every command you initiate to your mail client will be forwarded to the IMAP server and will be proceeded by it. POP3 is a protocol just to deliver the emails that have come in to the client. Incoming mails are not structured on the server. There are few decisions you can make using POP3, you can either delete the mails from the server after you have fetched them or keep them on the server.
5. You fetch your mails (POP3) or manage them on the server (IMAP).
Structure of an email
An email is simply a text. Textual information consists of bytes (8 bits) which can represent 256 different conditions. To communicate a text in English this is sufficient. The first emails had a scope of 7 bits which was enough to map the American character set. To enable texts to be written in Chinese or to transport pictures, music or films these contents will be transformed to text by fixed rules. This proceeding is named coding. In opposite to encryption coding is transparent, there is no secret built in. Codes are published conventions how to encode and decode information. Nevertheless humans mostly cannot read encoded information.
An email should consist of two parts, a header to inform the recipient about the mail, and a body containing the message that has been sent.
The header does not necessarily contain true information. Most of it was created by the sender or his email client. The header is mostly used to make classification of incoming emails easy to the recipients. It enables lists of incoming emails showing things like "From", "To", "Subject" or "Date". Again! Email headers are not trustworthy. There is no instance that reliably validates email headers. The only way to protect against fake etc. is to trust only digital signed mails.
To realize communication on the internet several rules published in papers called RFC (Request for Comment) were created. If email senders follow these rules the recipient's email program will interpret these mails correctly.
The header is the part of the email from top of the text to the first blank line. A header item consists of its name followed by a colon and its value.
"Official" items (recognizable by a missing "X-"at the beginning of the item) are among others
- Return Path: (to which email address the mail should be sent back if it cannot be delivered)
Normally the SMTP server of the sender sets this entry. If there is one it will not be altered.
- Delivered-To: (an entry that takes the recipient's MTA)
- Received: (a tracking list)
Normally the MTAs involved set these entries. But: it is possible to fake them.
- Date: (date an email was sent)
This item will be filled in by the initial SMTP server or the sender of the mail
- From: (email address of the sender)
The sender sets this entry and it is not trustworthy. A "From:"-, "To:"-, "Sender:"- or "Reply-To:"-entry is formatted as "name<email address>". Often you will detect suspicious senders by their addressing emails like "Best Books Ltd<firstname.lastname@example.org>". It is not necessary for sending an email to build correct headers.
- Sender: (a device that has created the email)
This item is seldom used and is mostly filled with the "From:" value.
- Reply-To: (the email address an answer should be addressed to)
- To: (address(es) of the recipient(s))
This entry will be set by the sender but it does not have to be the same the email is sent to.
- CC: (list of addresses which will get copies of the mail)
It is used to inform the recipient(s) to whom copies of the mail were sent. Most email programs notify the CCs within the header.
- Subject: (of the message)
Header extensions are prefixed by a "X-" e.g.
- X-Mailer: (the email program which was used)
- X-WiSiKo-Kind: (kind of the mail used by ReSecCo/ WiSiKo)
A minimal email as an example:
Date: Sat, 3 Dec 2016 22:53:21 +0100 (CET)
this is my mail
To add attachments, alternative text formatting like html, integrated pictures or cryptological features to an email MIME (= Multipurpose Internet Mail Extensions) is used.
Two more header items are needed:
- MIME-Version: 1.0 and
- Content-Type: multipart/…
The "Content-Type" decides how the recipient's email program will interpret the text within the body.
The "Content-Type" specifies the type e.g. "Content-Type: multipart/mixed;…" and a boundary marker to differ the parts e.g. "boundary=“this_are_the_parts“").
The body of such a message contains various sections each distinguished by the boundary. Additionally each is equipped with its own small header that tells the "Content-Type" of the message part. It is possible to place parts with a "Content-Type" that is a "multipart/..." itself. This leads to
Cryptology and emails
This section partially anticipates the section "Cryptology" that follows.
Emails secured cryptologically use the "Content-Type" "multipart/encrypted". There are two MIME parts. The first part is a version information, the second part contains the encrypted message. The information needed to decrypt the message is placed within the encrypted message part. If the encryption has been dissolved possibly a "multipart/signed" content appears. There are two MIME parts again. The first part contains the text that was signed and the other part contains the digital signature. The first part is the original message as it has been before cryptological processes happened.
Using cryptology and MIME in conjunction means that every part of the email will be encrypted or signed. Separate proceedings will be unnecessary.
While MIME by default appears like a puzzle where parts are clustered, they are placed side by side or behind one another, the cryptological extensions of MIME are appearing like Russian dolls that are nested.
While digital signing is proceeding the main "Content-Type" is altered to "multipart/signed". The body of the message is altered to MIME part "signed message" and one more part "...signature" is added.
The original message including its "Content-Type" is now wrapped or enveloped in a MIME part "signed message" and this envelope has been sealed by "signature". It is possible to repeat this process e.g. to add a second signing: The "multipart/signed..." message will be altered from the main "Content-Type" to the first part of a new "multipart/signed..." message. The second part is the signature of the second actor. Be aware that the complete mail including the signature will be signed again. To encrypt a signed or multisigned message the main "Content-Type" will be altered to "multipart/encrypted...". The former main "Content-Type" and the complete body will be encrypted. A new MIME part "version" will be added.
To dissolve such a message you have to act conversely. The MIME part containing the encrypted message has to be decrypted. The main "Content-Type" of the message will be altered to the "Content-Type" of the decrypted MIME part. It is a "multipart/signed..." now. Correct proceeding now is to check the validity of the signature and your trust in the signer. If the signed message is a message that was multi signed the proceeding has to be repeated.
A message can be viewed if any encryption is dissolved. This technique also works if different cryptological systems (as openPGP and PKCS #7) have been. Signing has no influence to visibility of contents.
RFCs and literature recommend first to sign and then to encrypt a message. This is reasonable because it is impossible to forward a message and preserve the signature if the message was encrypted at first and then signed (the signature relates to the encrypted message and decryption is only possible by the person whose key was used). This sequence can nevertheless be reasonable if sender and recipient are unknown to each other. In this case the recipient can validate the signature first and then decide to decrypt and view the message.
You should be aware that most email clients are not adjustable to this variability. Mostly they accept only
- one openPGP signature
- openPGP encryption without signing
- openPGP encryption and combined signature
- one X.509 (PKCS#7) signature
- X.509 (PKCS#7) encryption without signing
- X.509 (PKCS#7) encryption of signed (X.509 (PKCS#7) signature) messages.
If both partners are using ReSecCo/ WiSiKo they can choose freely. Additional ReSecCo/ WiSiKo can proceed the outdated inline cryptology that is used by Enigmail but does not use itself. Encryption and combined signing as it is possible in openPGP has some disadvantages. But ReSecCo/ WiSiKo uses it if it is unknown which possibilities the partner has.