The example below is an SMTP server for submitting (web)email. Its main task is to ensure that senders authenticate, and only use email sender addresses available to them. A smaller second example demonstrates a matching incoming SMTP server.
In the example below,
firstname.lastname@example.org will be sending an email to
email@example.com. What makes this special however, is that Madelin will not
use her own name as a sender, but instead send as a member of the group
So, here's the way our
mxout.example.net would be setup to fulfil this role in
the tighest, most spam-resistent manner possible.
mxout.example.net is the designated outgoing SMTP server for the
example.net, and we can stop spammers from abusing our email addresses
if we state clearly that this is the case. There are two mechanisms for this
purpose, namely DKIM and SPF.
For SPF, we specify in DNS that
example.net. IN SPF "v=spf1 a:mxout.example.net -all" example.net. IN TXT "v=spf1 a:mxout.example.net -all"
For DKIM, we setup a signing key on
mxout and signal its use in DNS with
_domainkey.example.net. IN TXT "t=y;o=~;" mxout._domainkey.example.net. IN TXT "k=rsa;p=MIIBIjANBgk...AQAB"
This assures sender authenticity in two ways:
- No server other than
mxout.example.netcan send on behalf of user
- No emails except those signed with the indicated key are valid for users
To help (web)mail applications easily derive the outgoing mail server from the domain part of an email address, we also announce its name in DNS, where we indicate that our outgoing SMTP server runs on port 587:
_submission._tcp.example.net. IN SRV 10 10 587 mxout.example.net
When all this information is signed under DNSSEC, our mail sender is in pretty good shape!
Setting up WebMail
The setup of webmail is highly trivial under ARPA2 principles; it can be setup without configuration at all! Consider the following:
- When using TLS-KDH or a client X.509 certificate, the client authenticates
over TLS; the TLS Pool can pickup on this and deliver a client identity
firstname.lastname@example.org the web server
- Based on this, the IMAP server for Madelin can probably be found as an
SRV record under
- When sending an email, the submission mail server can be found with the SRV record defined above
- Additional SRV records for IPP may even make a printer accessible
Based on this, there is no configuration required for having a flexible webmail solution! This is ideal for offering a mail hub on an internal network, or publicly. For constrained access over the Internet, the client identity can be subjected to authorisation as well -- but that is not our concern in this example.
This example does assume that the webmail solution will be able to pass on the credentials for the user. This work is under development, at least for TLS-KDH credentials, but not currently available. So, for now, we will continue our example and talk about desktop and mobile mail user agents.
Authentication of the Client
When Madelin wants to send her email, she connects to
on the right port, and starts an SMTP exchange. The first thing she does
is switch to an encrypted protocol using a
During the TLS negotiation, Madelin can authenticate her identity, for which
she uses her
email@example.com identity. She could use this over
an X.509 authentication (which is somewhat slow) but more likely she will
use TLS-KDH so she can use single sign-on based on a login earlier this day.
When the TLS handshake completes, the server knows that it is servicing
firstname.lastname@example.org -- if it uses the TLS Pool, then this authenticated
identity is neatly delivered along with a new connection that is shrouded
under a TLS cloak.
In this new connection, SMTP wants to authenticate, which Madelin already
took care of during the TLS handshake. In this second stage, she can
email@example.com or as
The method she would
use would be
SASL EXTERNAL, which refers to "contextual" authentication,
which in this case is the wrapping TLS connection. This is a point where the
poses an authorisation question
for the resource "sending mail on behalf of". The mail server may skip this
step for now if the
SASL EXTERNAL identity matches the one authenticated
by the TLS Pool.
The new email is being passed in, and includes the
MAIL FROM command to
indicate the envelope email sender. At this point, the
can pose (another) authorisation question for mail submission; this
is only needed when the address provided to
MAIL FROM differs from the
authorised email address, or when no authorisation for mail sending has
been done yet.
The remainder of the email submission follows, and it includes the
From: header that is passed in the email headers. This address is also
important, as it will be visible to the receiving mail user. This address
will therefore be verified to match the address provided in
There may however be reasons why these could differ, such as for mailing
lists; this means that the general authorisation inquiry to make is whether
MAIL FROM sender is permitted to use the given
This is not the resource "sending mail" but another, "sending mail on
There can be more actions, including even validating email signatures, but we will not get into the service that deeply.
Example 2: Incoming Mail Service
Now imagine an incoming mail server. In this case, the best authentication we can hope for is if the client's mail server provides a certificate for its host name, which usually is distinct from the sender's domain name. We could fall back to DANE records, but we don't have to.
Sender domains are gradually incorporating SPF and DKIM, as mentioned above, and this helps to test the mail server and the email itself.
When the envelope's
MAIL FROM command is issued, the immediate thing to do
is to initiate SPF checks on the remote end point address. And later, when
the email is provided, DKIM settings can be used to verify the email itself.
So, inasfar as incoming authentication goes, it usually takes a somewhat
different form than normal, but it does lead to a sender identity that is
An interesting aspect that remains however, is authorisation. The origin
mail server supplies a
MAIL FROM envelope sender address, as well as a
RCPT TO envelope recipient address. This can be used to validate the
rights to submit the email; after all, the InternetWide Architecture allows
you to place remote users on white and black lists; and to define a default
behaviour for those on neither list.
The authorisation for those mechanisms can work as follows. First, the
RCPT TO address is used to find the resource UUID for the recipient's
mailbox. Then, the authorisation question is posed whether the sender has
write access to this resource. This question will be answered based on the
black and white lists.
Other than this, gray listing may be used as a default policy; in that case,
there will be an extra interaction with the sender. It is useful that this
can be done already when the
RCPT TO is known, rather than when the email
has started to enter the incoming mail server. The gray listing method can
vary from service to service, but generally we intend to have it initiated
Why and How to Support ARPA2 in your Service
In general, the use of authorisation helps the service to decide what it may forward, and for whom. The backbone of the InternetWide Identity Framework is going to make this usable across realms in the future, but for now it is already possible to setup a service with the same mechanisms for use within a domain or realm.
Services that prepare themselves by already incorporating a TLS-KDH implementation such as the TLS Pool for authentication, and a Diameter or RADIUS backend for authorisation, are very likely to work with all the extensions that we are preparing withouth further changes.