Email Systems
Dr. Greg Bernstein
May 21st, 2021
Learning Objectives
- Understand the history and evolution of email systems including content types
- Understand the entities involved with modern email systems (MUA, MSA, MTA, MDA)
- Understand the protocols supporting email systems (SMTP, IMAP, POP3)
- Understand basic security mechanisms supported by email systems
- Not covered: proprietary mail systems and protocols
General Email References
Current Email Standards (partial)
- Simple Mail Transport Protocol RFC5321, October 2008 (Obsoletes RFC2821 which Obsoletes RFCs 821, 974, and 1869)
- Message Submission for Mail RFC6409, November 2011, (Obsoletes RFC4409 which Obsoletes RFC 2476)
- INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 RFC3501, March 2003 (Obsoletes RFC2060 which Obsoletes RFC1730)
Email Content Specifications
Internet Message Format RFC5322, October 2008 (Obsoletes RFC2822 which Obsoletes RFC822) text messages, IANA Header Fields for mail, MIME, http, etc…
Wikipedia: Multipurpose Internet Mail Extensions (MIME), IETF documents RFC2045-RFC2049 and more. Allows for many types of contents and multiple parts.
Wikipedia: Media Type formerly known as MIME Type, used to specify contents, e.g.,
text/plain,text/html,application/json, etc…IANA official list
Email History and Content
History
- 1960s saw email between users on the same time-shared computer
- 1970s saw email between users on different machines connected to the ARPANET
- 1981 saw the initial standardization of the Simple Mail Transfer Protocol (SMTP)
- Late 90s early 2000s saw wide spread individual adoption (the Web)
Basic Email Content
- Message consists of header fields followed (optionally) by a body
- Basic message is specified to use 7 bit ASCII, i.e., characters 1-127 interpreted as US-ASCII
- Mail systems may add header fields during processing
Sample Delivered Email 1
Sent from gregb@grotto-networking.com to greg.bernstein@csueastbay.edu with proprietary and “experimental” headers removed
Delivered-To: greg.bernstein@csueastbay.edu
Received: by 2002:a05:7110:3254:b029:c6:1b8a:7910 with SMTP id e20csp698391gec;
Fri, 21 May 2021 13:06:05 -0700 (PDT)
Return-Path: <gregb@grotto-networking.com>
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com. [136.143.188.12])
by mx.google.com with ESMTPS id g24si7568396pgm.120.2021.05.21.13.06.04
for <greg.bernstein@csueastbay.edu>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Fri, 21 May 2021 13:06:04 -0700 (PDT)
Received-SPF: pass (google.com: domain of gregb@grotto-networking.com designates 136.143.188.12 as permitted sender) client-ip=136.143.188.12;
Authentication-Results: mx.google.com;
dkim=pass header.i=@grotto-networking.com header.s=mail header.b=A0fB2Q4Y;
arc=pass (i=1 spf=pass spfdomain=grotto-networking.com dkim=pass dkdomain=grotto-networking.com dmarc=pass fromdomain=grotto-networking.com>);
spf=pass (google.com: domain of gregb@grotto-networking.com designates 136.143.188.12 as permitted sender) smtp.mailfrom=gregb@grotto-networking.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1621627561;
s=mail; d=grotto-networking.com; i=gregb@grotto-networking.com;
h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=7+dE6EebhY5k6ojWN30UYZCmT7lcsj6OmBRL3QCKu5Y=;
b=A0fB2Q4YLiFhATHIO5mVNq1SktCkpZ/L4kAOTri6nfz9aQ5og4xm7/Hz8+/arruF
Dofa+H2v8CZGG23AipkW58cdgiXvKdNk+27CssmV8GGwMGo8RR76yMtnhEP5AUQ440y
4GNmc9JtyiYt+W065Tz+GJQxveCBy1KDkkX7eWRQ=
Received: from [192.168.1.228] (c-73-92-198-50.hsd1.ca.comcast.net [73.92.198.50]) by mx.zohomail.com
with SMTPS id 1621627558841147.5789422464959; Fri, 21 May 2021 13:05:58 -0700 (PDT)
To: greg.bernstein@csueastbay.edu
From: Greg Bernstein <gregb@grotto-networking.com>
Subject: Demonstration Email
Message-ID: <eb7b0f1c-c624-e533-02ea-c14a821c3cd7@grotto-networking.com>
Date: Fri, 21 May 2021 13:05:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.10.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
This is a sample email.
Dr. B.Multipurpose Internet Mail Extensions (MIME)
From Wikipedia: MIME
Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs. Message bodies may consist of multiple parts, and header information may be specified in non-ASCII character sets.
Email with HTML
HTML in email sent from greg.bernstein@csueastbay.edu to gregb@grotto-networking.com
Sample Delivered HTML Email (raw)
Sent from greg.bernstein@csueastbay.edu to gregb@grotto-networking.com with proprietary and “experimental” headers removed
Delivered-To: gregb@grotto-networking.com
Received-SPF: permerror (zohomail.com: Error in processing SPF Record) client-ip=209.85.216.44; envelope-from=greg.bernstein@csueastbay.edu; helo=mail-pj1-f44.google.com;
Authentication-Results: mx.zohomail.com;
dkim=pass;
spf=permerror (zohomail.com: Error in processing SPF Record) smtp.mailfrom=greg.bernstein@csueastbay.edu
Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mx.zohomail.com
with SMTPS id 1621871503284414.06509634624547; Mon, 24 May 2021 08:51:43 -0700 (PDT)
Received: by mail-pj1-f44.google.com with SMTP id cu11-20020a17090afa8bb029015d5d5d2175so11462746pjb.3
for <gregb@grotto-networking.com>; Mon, 24 May 2021 08:51:43 -0700 (PDT)
Return-Path: <greg.bernstein@csueastbay.edu>
Return-Path: <greg.bernstein@csueastbay.edu>
Received: from ?IPv6:2601:641:380:26e7:18f8:8784:e605:75c1? ([2601:641:380:26e7:18f8:8784:e605:75c1])
by smtp.gmail.com with ESMTPSA id s123sm10773229pfb.78.2021.05.24.08.51.41
for <gregb@grotto-networking.com>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 24 May 2021 08:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=csueastbay.edu; s=google;
h=to:from:subject:message-id:date:user-agent:mime-version
:content-language;
bh=B94trKa4U5pq+Us6u7W+PXMn9Y7g0ilhSUyoDoZqXno=;
b=W5QnaGN86mUPOmGs0eYTwSEqEbpy0oyY9GLvb3t8YOUavAF/rZwrGsZcE+1/CtpgFT
TAqtQ5moFeQTYNZJoQg1F31ENjDWUSR+Ztnx8t7Vyy043XIi+ksKp2KfW7PYEu20X1Hc
LpZxX9BSAt8GAVhMBt4+iROAtrC4b5Jf7fH1E=
To: gregb@grotto-networking.com
From: "Dr. Greg M. Bernstein" <greg.bernstein@csueastbay.edu>
Subject: HTML in email
Message-ID: <297cba9d-e8d1-176c-4234-f9010d8d1152@csueastbay.edu>
Date: Mon, 24 May 2021 08:51:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.10.2
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="------------E73A7D0204519C6245943E5A"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------E73A7D0204519C6245943E5A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
HTML in Email
*Yes*. You can put /HTML/ in email.
--------------E73A7D0204519C6245943E5A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="markdown-here-wrapper" data-md-url="" style="">
<h1 id="html-in-email" style="margin: 1.3em 0px 1em; padding: 0px;
font-weight: bold;font-size: 1.6em; border-bottom: 2px solid
rgb(119, 119, 119);">HTML in Email</h1>
<p style="margin: 0px 0px 1.2em !important;"><strong>Yes</strong>.
You can put <em>HTML</em> in email.</p>
<div
title="MDH:PHA+IyBIVE1MIGluIEVtYWlsPC9wPjxwPioqWWVzKiouIFlvdSBjYW4gcHV0ICpIVE1MKiBpbiBlbWFpbC48YnI+PC9wPg=="
style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;"></div>
</div>
</body>
</html>
--------------E73A7D0204519C6245943E5A--Summary Email History and Content
- Email has been around for a long time, pre-dates the Web by two decades or more
- With MIME emails can contain just about any type of content
- Systems that process the email may restrict content types for security or other reasons
Email Systems Elements
Email System Diagram
From Wikipedia: Email
Email System Summary
Message/Mail User Agent (MUA): an application that a user uses to access, send, and manage emails
Message/Mail submission Agent (MSA): authenticates and receives messages from the MUA
Message Transfer Agent (MTA): Used for general transfer of mail messages across internet
Message Delivery Agent (MDA): Used to put messages received into individual users “mail boxes”.
IMAP or POP3 Server: Used to connect MUAs to their mailboxes across the internet
Message/Mail User Agent
Applications rather than web based mail clients. Example open source programs: Thunderbird, Claws Mail
Message/Mail Submission Agent 1
From Wikipedia: MSA
A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.
Message/Mail Submission Agent 2
From Wikipedia: MSA
Mail Transfer Agent
From DO
A Mail Transfer Agent (MTA), which handles Simple Mail Transfer Protocol (SMTP) traffic, has two responsibilities:
- To send mail from your users to an external MTA (another mail server)
- To receive mail from an external MTA
- Examples of MTA software: Postfix, Exim, and Sendmail.
Message/Mail Delivery Agent Definition
From Wikipedia
A message delivery agent (MDA), or mail delivery agent, is a computer software component that is responsible for the delivery of e-mail messages to a local recipient’s mailbox. It is also called a local delivery agent (LDA).
Mail Delivery Agent
From DO
There are a variety of mailbox formats, such as mbox and Maildir. Each MDA supports specific mailbox formats. The choice of mailbox format determines how the messages are actually stored on the mail server which, in turn, affects disk usage and mailbox access performance.
Examples of MDA software: Postfix and Dovecot.
IMAP and/or POP3 Server
From DO
IMAP and POP3 are protocols that are used by mail clients, i.e. any software that is used to read email, for mail retrieval.
IMAP is the more complex protocol that allows, among other things, multiple clients to connect to an individual mailbox simultaneously. The email messages are copied to the client, and the original message is left on the mail server.
POP3 is simpler, and moves email messages to the mail client’s computer, typically the user’s local computer, by default.
Example Email System Implementation
DO: How To Configure a Mail Server Using Postfix, Dovecot, MySQL, and SpamAssassin
- MSA, MTA, and MDA functionality provided by Postfix
- IMAP functionality provided by Dovecot
- Spam Filtering by Apache SpamAssassin
Email System Protocols
Simple Mail Transfer Protocol History
- November 1981, Jon Postel published RFC 788 “Simple Mail Transfer Protocol”.
- November 1995, RFC 1869 defined Extended Simple Mail Transfer Protocol (ESMTP)
- Message submission (RFC 2476) and SMTP-AUTH (RFC 2554) were introduced in 1998 and 1999
SMTP Evolution 1
Originally, SMTP servers were typically internal to an organization, receiving mail for the organization from the outside, and relaying messages from the organization to the outside. But as time went on, SMTP servers (mail transfer agents) were expanding their roles to become message submission agents for Mail user agents, some of which were now relaying mail from the outside of an organization. (e.g. a company executive wishes to send email while on a trip using the corporate SMTP server.)
SMTP Evolution 2
This issue, a consequence of the rapid expansion and popularity of the World Wide Web, meant that SMTP had to include specific rules and methods for relaying mail and authenticating users to prevent abuses such as relaying of unsolicited email (spam).
Simple Mail Transfer Protocol 1
Simple Mail Transfer Protocol 2
User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP and POP3 are standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.
Internet Message Access Protocol 1
In computing, the Internet Message Access Protocol (IMAP) is an Internet standard protocol used by email clients to retrieve email messages from a mail server over a TCP/IP connection. IMAP is defined by RFC 3501.
Internet Message Access Protocol 2
IMAP was designed with the goal of permitting complete management of an email box by multiple email clients, therefore clients generally leave messages on the server until the user explicitly deletes them. An IMAP server typically listens on port number 143. IMAP over SSL/TLS (IMAPS) is assigned the port number 993.
Internet Message Access Protocol 3
Virtually all modern e-mail clients and servers support IMAP, which along with the earlier POP3 (Post Office Protocol) are the two most prevalent standard protocols for email retrieval. Many webmail service providers such as Gmail and Outlook.com also provide support for both IMAP and POP3.
Email Processing Sequence I
From Wikipedia: Email
The following is a typical sequence of events that takes place when sender Alice transmits a message using a mail user agent (MUA) addressed to the email address of the recipient. Email operation
- The MUA formats the message in email format and uses the submission protocol, a profile of the Simple Mail Transfer Protocol (SMTP), to send the message content to the local mail submission agent (MSA), in this case smtp.a.org.
Email Processing Sequence II
From Wikipedia: Email
The MSA determines the destination address provided in the SMTP protocol (not from the message header) — in this case, bob@b.org. The part before the @ sign is the local part of the address, often the username of the recipient, and the part after the @ sign is a domain name. The MSA resolves a domain name via DNS.
The DNS server for the domain b.org (ns.b.org) responds with any MX records listing the mail exchange servers for that domain, in this case mx.b.org, a message transfer agent (MTA) server run by the recipient’s ISP.
Email Processing Sequence III
From Wikipedia: Email
smtp.a.org sends the message to mx.b.org using SMTP. This server may need to forward the message to other MTAs before the message reaches the final message delivery agent (MDA).
The MDA delivers it to the mailbox of user bob.
Bob’s MUA picks up the message using either the Post Office Protocol (POP3) or the Internet Message Access Protocol (IMAP).
Email Authentication
Email Authentication Issue
From Wikipedia: Sender Policy Framework
The Simple Mail Transfer Protocol permits any computer to send email claiming to be from any source address. This is exploited by spammers and scammers who often use forged email addresses, making it more difficult to trace a message back to its source, and easy for spammers to hide their identity in order to avoid responsibility. It is also used in phishing techniques, where users can be duped into disclosing private information in response to an email purportedly sent by an organization such as a bank.
Email Authentication References
Levels of Authentication/Integrity
- Verifying that the MTA allowed to send messages for a given domain (SPF)
- Verifying the allowed MTA for a given domain originated the message and it hasn’t been modified (DKIM)
- Verifying the actual message sender and that the message hasn’t been modified (S/MIME or OpenPGP)
Sender Policy Framework (SPF) 1
From SPF RFC7208
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the “MAIL FROM” of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.
Sender Policy Framework (SPF) 2
From Wikipedia: Sender Policy Framework
Sender Policy Framework (SPF) is an email authentication method designed to detect forging sender addresses during the delivery of the email. SPF alone, though, is limited to detecting a forged sender claim in the envelope of the email, which is used when the mail gets bounced.
Sender Policy Framework (SPF) 3
From Wikipedia: Sender Policy Framework
SPF allows the receiving mail server to check during mail delivery that a mail claiming to come from a specific domain is submitted by an IP address authorized by that domain’s administrators. The list of authorized sending hosts and IP addresses for a domain is published in the DNS records for that domain.
SPF Example Part 1
- I own
grotto-networking.com(Domain.com is my registrar) - I host my sites/apps at Digital Ocean which allows me to set up DNS records for my domains and sub-domains
- I use Zoho mail for secure business email
- In a DNS record for SPF I say that
zoho.comis allowed to send mail for me
SPF Example Part 2
Pointing DNS MX records to Zoho:
SPF Example Part 3
Zoho confirmation of SPF/TXT DNS record:
SPF Example Part 4
Sent from gregb@grotto-networking.com to greg.bernstein@csueastbay.edu with proprietary and “experimental” headers removed
Delivered-To: greg.bernstein@csueastbay.edu
Received: by 2002:a05:7110:3254:b029:c6:1b8a:7910 with SMTP id e20csp698391gec;
Fri, 21 May 2021 13:06:05 -0700 (PDT)
Return-Path: <gregb@grotto-networking.com>
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com. [136.143.188.12])
by mx.google.com with ESMTPS id g24si7568396pgm.120.2021.05.21.13.06.04
for <greg.bernstein@csueastbay.edu>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Fri, 21 May 2021 13:06:04 -0700 (PDT)
Received-SPF: pass (google.com: domain of gregb@grotto-networking.com designates 136.143.188.12 as permitted sender) client-ip=136.143.188.12;
Authentication-Results: mx.google.com;
dkim=pass header.i=@grotto-networking.com header.s=mail header.b=A0fB2Q4Y;
arc=pass (i=1 spf=pass spfdomain=grotto-networking.com dkim=pass dkdomain=grotto-networking.com dmarc=pass fromdomain=grotto-networking.com>);
spf=pass (google.com: domain of gregb@grotto-networking.com designates 136.143.188.12 as permitted sender) smtp.mailfrom=gregb@grotto-networking.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1621627561;
s=mail; d=grotto-networking.com; i=gregb@grotto-networking.com;
h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=7+dE6EebhY5k6ojWN30UYZCmT7lcsj6OmBRL3QCKu5Y=;
b=A0fB2Q4YLiFhATHIO5mVNq1SktCkpZ/L4kAOTri6nfz9aQ5og4xm7/Hz8+/arruF
Dofa+H2v8CZGG23AipkW58cdgiXvKdNk+27CssmV8GGwMGo8RR76yMtnhEP5AUQ440y
4GNmc9JtyiYt+W065Tz+GJQxveCBy1KDkkX7eWRQ=
Received: from [192.168.1.228] (c-73-92-198-50.hsd1.ca.comcast.net [73.92.198.50]) by mx.zohomail.com
with SMTPS id 1621627558841147.5789422464959; Fri, 21 May 2021 13:05:58 -0700 (PDT)
To: greg.bernstein@csueastbay.edu
From: Greg Bernstein <gregb@grotto-networking.com>
Subject: Demonstration Email
Message-ID: <eb7b0f1c-c624-e533-02ea-c14a821c3cd7@grotto-networking.com>
Date: Fri, 21 May 2021 13:05:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.10.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
This is a sample email.
Dr. B.DKIM Definition
From Wikipedia: DKIM
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email (email spoofing), a technique often used in phishing and email spam.
DKIM Approach
From Wikipedia: DKIM
DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender’s public key published in the DNS.
DKIM Example Part 1
- My email provider
zoho.comruns the MSA, MTA, MDA, and IMAP email components (as well as spam filtering, anti-virus, and webmail) - At
zoho.comI generate a public/private key pair. They give me the public key. - In my DNS settings at Digital Ocean I create a record with this public key.
DKIM Example Part 2
Configuration at zoho.com
DKIM Example Part 3
Configuration at Digital Ocean
DKIM Example Part 4
Sent from gregb@grotto-networking.com to greg.bernstein@csueastbay.edu with extra headers
Authentication-Results: mx.google.com;
dkim=pass header.i=@grotto-networking.com header.s=mail header.b=A0fB2Q4Y;
arc=pass (i=1 spf=pass spfdomain=grotto-networking.com dkim=pass dkdomain=grotto-networking.com dmarc=pass fromdomain=grotto-networking.com>);
spf=pass (google.com: domain of gregb@grotto-networking.com designates 136.143.188.12 as permitted sender) smtp.mailfrom=gregb@grotto-networking.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1621627561;
s=mail; d=grotto-networking.com; i=gregb@grotto-networking.com;
h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=7+dE6EebhY5k6ojWN30UYZCmT7lcsj6OmBRL3QCKu5Y=;
b=A0fB2Q4YLiFhATHIO5mVNq1SktCkpZ/L4kAOTri6nfz9aQ5og4xm7/Hz8+/arruF
Dofa+H2v8CZGG23AipkW58cdgiXvKdNk+27CssmV8GGwMGo8RR76yMtnhEP5AUQ440y
4GNmc9JtyiYt+W065Tz+GJQxveCBy1KDkkX7eWRQ=
Received: from [192.168.1.228] (c-73-92-198-50.hsd1.ca.comcast.net [73.92.198.50]) by mx.zohomail.com
with SMTPS id 1621627558841147.5789422464959; Fri, 21 May 2021 13:05:58 -0700 (PDT)
To: greg.bernstein@csueastbay.edu
From: Greg Bernstein <gregb@grotto-networking.com>
Subject: Demonstration Email
Message-ID: <eb7b0f1c-c624-e533-02ea-c14a821c3cd7@grotto-networking.com>
Date: Fri, 21 May 2021 13:05:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.10.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
This is a sample email.
Dr. B.Message Confidentiality
Email Confidentiality
- Confidentiality while in transit, e.g., MUA to MSA, MTA to MTA, etc…
- Confidentiality while at rest, e.g., while sitting in storage on a server somewhere
- Complete end to end confidentiality, integrity and more…
Encryption for Confidentiality and More
Need encryption and related technologies to provide data confidentiality while in transit and at rest
We will learn about public key cryptography and its use in providing integrity and verification (digital signatures)
We will learn about Transport Layer Security (TLS) and its use for securing data in transit
Encrypted Storage Implementation Example
From Dovecot: mail-crypt-plugin
Secure Email Services
From Zoho Secure Email, one of a number of secure email providers
