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, madelin@example.net will be sending an email to jason@client.example.org. 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 support@example.net.

So, here's the way our mxout.example.net would be setup to fulfil this role in the tighest, most spam-resistent manner possible.

DNS configuration

The server mxout.example.net is the designated outgoing SMTP server for the domain 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.net can send on behalf of user @example.net
• No emails except those signed with the indicated key are valid for users @example.net

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 as madelin@example.net to the web server
• Based on this, the IMAP server for Madelin can probably be found as an SRV record under example.net
• 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 mxout.example.net on the right port, and starts an SMTP exchange. The first thing she does is switch to an encrypted protocol using a STARTTLS exchange.

During the TLS negotiation, Madelin can authenticate her identity, for which she uses her madelin@example.net 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 madelin@example.net -- 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 authenticate as madelin@example.net or as support@example.net. 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 mxout service 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 mxout server 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 MAIL FROM. 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 the MAIL FROM sender is permitted to use the given From: header. This is not the resource "sending mail" but another, "sending mail on behalf of".

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 more-or-less authenticated.

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 from Diameter.

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.