ARC test website
The MailerQ team has implemented the new ARC technology in MailerQ. This means (in short) that you can now modify emails that already had a digital signature (like a DKIM signature), and let MailerQ add an ARC signature to the message. The mail can then be forwarded to the recipient with this extra ARC signature.
The receiver of the mail recognizes that the mail was modified (because the original signature is no longer valid), but she can also see that an extra ARC signature was added. This extra signature tells her who broke the original signature, and it tells her that the original signature was still valid before the mail was modified. The rationale behind this technology is that receivers can now decide to accept mails with broken DKIM signatures if they trust the party that modified the mail and broke the signature.
Testing the new technology
ARC is a completely new technology that has not yet been standardized and is not yet in use on the internet. MailerQ's implementation is one of the first (if not the very first) working implementation in the world. Because of this, it is rather pointless to use it in production (but this could change in the future), and it can not be guaranteed that we've implemented it in the same way as other parties (are going to do). To test and demonstrate our implementation we created a small website where you can see our algorithm in action.
The test website allows you to paste the MIME source of an email into a form, and add ARC signatures to the message.
Because we are one of the first parties to have implemented ARC, we are also one of the first parties to share our experiences with it. And to be honest: we dislike ARC. There are a couple of things that we especially do not like about it:
- It is based on DKIM technology
- It is difficult to deploy
- It makes email headers ugly
- It does not introduce new features
- Simpler, more elegant and more powerful solutions are possible
Let's explain out criticism. ARC uses the same signing technology as DKIM. The current signing and validation algorithm of DKIM is very strict. DKIM signatures (and therefore also ARC signatures) are easy to break. Even if you make a small irrelevant change to an email (like changing the character set, the timezone or the content-transfer-encoding), you cause DKIM signatures to break.
This is a shortcoming of DKIM. Such small changes do not at all change the content of an email, but just the technical representation. For a human being such messages are identical, and for computer programs this can be easy to recognize too. But despite of this, a DKIM signature simply breaks if you make such a trivial technical change to a message. This is a problem that could easily be solved by bringing out an improved DKIM standard.
One of the reasons why ARC was introduced was to solve DKIM's shortcomings. In that light we think it is wrong for ARC to use exactly the same (flawed) signing technology as DKIM. DKIM signatures are too easy to break, and therefore ARC signatures will be too. The time spent on this new ARC standard would be better spent on improving DKIM.
ARC is difficult to deploy
For an ARC chain to work, it must be signed by every MTA along the way that modifies the message. If there is only one MTA that fails to do this, the ARC chain can not be validated.
This requires ARC to be deployed on many computers - not only on the machines of the sender and the receiver, but also on all sort of nodes in the middle. It will take years to get to this point. An alternative technology that does not rely so heavily on deployment on all these hubs would be much easier to get rolling.
Ugly mail headers
If you play around with our demonstration website, you can see that the message header literally explodes if you add a couple of ARC signatures to your message.
Technology should be simple. The easier a technology is, the more likely it is to be adopted. ARC is not easy. A mail that has passed a couple of hubs becomes next to unreadable and is almost impossible to recognize as a mail message. A simple, elegant solution is preferred over this complex ARC technology.
No new features are introduced
It is going to be a hell of a job to get ARC deployed. And what does it bring us? What are the benefits? What is the point of spending so much time and energy on it? Can we suddenly do things that were not possible before?
This is a missed opportunity. If we are going to introduce a new technology, and if we are going to require this to be installed on so many hosts, why not grab this opportunity to make email cooler at the same time? We could for example allow receivers to track exactly what was changed. This could be a very useful feature.
The ARC technology is available in MailerQ, and can already be seen in action on our demonstration website. We do support the technology, but think that a simpler, more elegant and more powerful solution is possible - and preferrable.