DKIM2 Is A Mess
Recently, there has been an increase in posts and discussions on the subject of DKIM2. Many of these posts emphasize the benefits DKIM2, despite the new standard’s ability to realize these benefits being anything but certain.
Current documents adopted by the DKIM Working Group fall short of providing a coherent, implementable standard that aligns with established SMTP behavior, ignoring both existing RFC requirements and the technical reality of deployment within the wider email ecosystem. The proposals also align poorly with the Working Group’s own Charter, focusing on delivering a replacement for ARC, at the expense of DKIM.
DKIM2 is, to put it simply, a mess.
In this post, I will discuss what the DKIM Working Group were tasked with delivering and compare what they are working on against what is technically feasible. In my next post, I will present a pragmatic migration path from DKIM that will deliver many of the claimed benefits of DKIM2 without introducing breaking changes.
Working Group Charter
As per their Charter, the DKIM Working Group were asked to consider several contemporary issues. The label ‘contemporary’ is quite misleading as the issues are neither contemporary, nor were they issues DKIM originally sought to address.
The Working Group were asked to consider the following issues:
Validation of a message’s signing identifier across common transit and forwarding modifications.
Replay to recipients to which the original email was not sent.
Using an unauthorized envelope address to create backscatter.
The lack of visibility of errors to service providers as the errors are sent to the entity (their customer), and not the service provider.
These issues appear to be summarized from a motivations document. The document itself is suggested as a starting point for the Working Group in the Charter.
Further direction is given, guiding the Working Group towards the following objectives:
Provide assurances against unauthorized use of the (envelope) sender, reducing the success of direct domain name misuse and improving the value of delivery status notifications.
Identify message mutations made by any handling agent that affect signature validity.
Attach annotations in transit of the intended chain of handling to assure accountability for each delivery, aiding in the mitigation of backscatter.
On the surface, addressing these issues seems quite reasonable. That’s not to say the Working Group must address each of these issues and there are reasons why addressing some is not realistic. The objectives to some extent reflect the practicality of addressing the issues by narrowing the scope to a more achievable set of potential outcomes.
DKIM2 is not DKIM
What the DKIM Working Group are currently working on would more accurately be called ARC 2.0. While DKIM2 has erroneously been described by its authors as a superset of DKIM and viewed as its eventual replacement, the emphasis of the DKIM Working Group has been on developing a replacement for ARC. ARC is not DKIM.
This isn’t outside the scope of what the Working Group was tasked with per se, as the Charter allows them to “determine that a technology which supersedes existing technologies such as DKIM, DMARC, and ARC, is a superior solution.”
Where the Working Group has significantly deviated from the Charter is prioritizing an ARC replacement ahead of and at the expense of DKIM. The current approach of the Working Group specifically goes against guidance given in the Charter to “prefer a result that is incremental to the deployed ecosystem”, and sees it abandoning DKIM functionality that is not only permitted by existing RFCs, but is explicitly documented in those standards and actively relied on in real-world situations.
The ARC “experiment”, as IETF refers to it, has been discontinued and the experiment described as an objective failure. DKIM on the other hand, is widely deployed. The Working Group has taken it upon themselves to repurpose the key infrastructure established for DKIM to replicate functionality of a standard few see any benefit in and even fewer have adopted, while at the same time breaking existing DKIM use cases and proposing to fundamentally alter established SMTP behavior.
Bron Gondwanda, author of an earlier document adopted by the Working Group and co-author of the currently adopted document, has confirmed that they are developing a replacement for ARC that is not interoperable with DKIM at the technical level, and that the DKIM branding (and its reputation) are being used because people are already familiar with it. He further stated that “The use of DKIM for branding purposes is based on ‘people have heard of DKIM and they can put keys in the DNS for DKIM now and get the benefits of DKIM2 when their MTA software is updated with no other effort’”, a claim that is demonstrably untrue — the correct function of DKIM2 as it stands now, is highly dependent on the correct configuration of MTAs and filters.
DKIM is the only sender-controlled mechanism that gives any control over how email delivery is handled, by allowing a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. Many, including those on the mailing list who should know better, view DKIM exclusively as a mechanism for verifying the integrity of email in transit and are dismissive of other use cases. In contrast, the Working Group charter actually encouraged work on novel uses for DKIM, not further limiting its utility.
DKIM verification is successful when a signature confirms the email is unaltered. This is often cited as a flaw, because some implementations consistently verify the signature that aligns with the from address, while others may validate the topmost signature for example. This behavior is by design, and the perceived issues this creates for users validating email in transit can easily be addressed by introducing more strict rules applicable to transit only. It does not necessitate a complete rewrite of the standard.
DKIM2 verification on the other hand, is successful when any and all changes to an email can be verified. These are entirely different concepts. So long as any changes are signed, the DKIM2 cryptography will pass, leaving it at the discretion of the receiving system to determine what it considers to be an acceptable change and how these changes will be brought to the attention of users, if at all. Essentially, DKIM2 throws the baby out with the bathwater, redefining DKIM as yet another tool for receivers to make policy-based decisions. Do you want sensitive email from financial institutions to remain verifiable as original as is the case with DKIM, or be at the mercy of reputation and heuristics to silently determine if any changes are safe?
While the question has been raised on the list, the Working Group shows no interest in making meaningful DKIM2 results a priority for recipients. DKIM2 will be treated as a black box and a pass or fail grade assigned, without explicitly notifying the recipient that something material may have been altered.
Rewriting SMTP
Proponents of current DKIM2 proposals assert their current test implementations, based on the milter protocol, are proof that changes to SMTP itself are not required.
Regardless of how they try to spin it, the intent of DKIM2 as it currently stands is to fundamentally change the way SMTP operates. It would, without a doubt, be the most significant change to SMTP since its inception. What we are witnessing is a revolution, not evolution; a revolution founded on a motivating document that does not begin to justify the level of upheaval necessary in support of its implementation.
Among the changes required in support of DKIM2:
Details of any changes made either to the email headers (with some exceptions) and the email body, must be recorded within the message headers and signed by the domain making alterations.
MAIL FROM must be rewritten at every hop.
Combined Bcc deliveries for all recipients of an email sent either to a common domain or upstream smart host will no longer be possible.
Signers must perform some verification before signing and on-sending email.
Each of these requirements significantly changes in email flow, moving from a Simple Mail Transfer Protocol to one with indirect email flow and additional state management, verification and signing requirements necessary at every hop or domain boundary.
For a change of this magnitude, it would be reasonable to assume the proposal would be implemented using an SMTP extension, if for no other reason than to provide guarantees around email handling when delivering to an upstream host. Members of the DKIM Working Group, however, express significant hostility towards the use of an STMP extension at all. They intend to just shove change data into headers, with no regard for the capabilities of upstream systems and provide no migration path for alternative submission scenarios.
Apparently, the discussion around use of an extension occurred some time ago, before the Working Group unilaterally decided it was within their purview to redefine the inner workings of SMTP. Given the extent of what is now proposed, the Working Group should, at a minimum, be revisiting that decision.
It’s unclear why there is resistance to using SMTP extensions. Proponents of DKIM2 are willing to make unsubstantiated claims regarding the difficulty of implementing a simple extension in support of their objectives, despite evidence to the contrary and the obvious benefits of their use. What is certain, however, is that RFC 5321 explicitly requires that “each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs”. That’s a high bar already, but if an SMTP extension requires such scrutiny, the surely the threshold necessary to change SMTP itself must be even higher?
Technical Reality
Change tracking simply isn’t feasible within the constraints of SMTP, an unstructured messaging format and without significant architectural changes across email infrastructure.
The DKIM2 proposal places change tracking information within the headers of the email itself. Many systems have size limits for headers, and according to some reports, some implementations are known to limit headers to as little as 32kB, while there are innumerable systems with unknown limitations. Email services are already known to write excessive amounts of data into the headers. Taking a random email ex-Microsoft as an example, the headers alone were >12kB, comprised mostly of proprietary headers, references to earlier emails, and of course, DKIM-Signature headers. This leaves little room for change tracking, which would itself be inefficient, taking the form of a base64-encoded JSON object. Changes needing tracking include all body modifications, along with header additions, deletions, substitutions, excluding X- headers and certain trace headers.
To partially mitigate issues created by ad hoc header placement and reordering, both of which are permissible and known to occur in real-world usage, a new canonicalization method is employed that first sorts all headers prior to signing. The proposal also allows for “null recipes”, a mechanism which effectively declares something has changed, but not what that change is, in order to accommodate larger changes such as edits in base64 bodies (which can change all subsequent lines) or attachment removal. The latest draft at the time of writing, draft-ietf-dkim-dkim2-spec-03, appears to remove this option for header modifications, requiring these to always be signed. None of this addresses the limitations of upstream hosts, which could very well be presented with “recipes” that already exceed their capabilities. Messages using null recipes, which omit the pertinent details the proposal seeks to include, means such messages are likely to be handled differently from those which include a full change history.
In order to be able to identify and sign changes, DKIM2 must have oversight of every change made to an email within a system. A system may be a single server, or a geographically distributed collection of SMTP servers and filters, including external scripts and processes.
Practically, this requires a DKIM2 implementation to store the original email and make this available, out of band, to the system that eventually records and signs the changes. This is necessary as neither the MTA or filters can collate changes as they occur and they must instead be calculated at the end of processing. This takes DKIM from being a single step within a linear process, which a server may implement at any convenient point in time, to one which is re-entrant with strict ingress and egress requirements, while adding database infrastructure and maintenance requirements to what is, intentionally, a simple transfer protocol.
While it is likely most changes would occur near creation or delivery, significant edits are not limited to gateways and may be performed by other systems. What DKIM2 views as significant is far-reaching by design, necessitating major architectural changes for many systems, including those that have traditionally been involved in transit only. If the MTAs or any filter in their chain inserts anything other than an X-header or specifically excluded header, or they might, the system must be capable of recording this fact and re-signing the email.
One argument for signing every header is that it’s unknown what headers may be seen as significant either to specific users or in the future. Despite claims to the contrary, few headers are truly significant and the emphasis should be on the social engineering aspect of email, protecting headers which could mislead a recipient. Some industries and military organizations may make it a requirement for specific headers to be cryptographically verifiable between senders and receivers, however, such requirements should be considered outside the scope of the IETF and managed by way of agreements between entities and auditing of systems operating in highly regulated environments.
It’s plain to see, even to those who are not technically inclined, that this level of change tracking isn’t achievable through a simple software upgrade as Gondwana claims.
Motivation, not justification
Surely, given the level of upheaval, the justification is sound?
The Charter identifies the issue of changes to an email breaking existing validation, but the objectives only go as far as identifying mutations, not necessarily recording what each of those mutations might be. Even if unwinding changes were practical, the justification simply isn’t there.
The motivations document refers to two cases in support of change tracking. These are mailing lists and forwarders (citing alumni forwarders as an example).
The use of the term “mailing lists” is highly misleading. What they are actually referring to are distributions lists. This distinction is important, because these are not common marketing or other materials a user has signed up to receive, nor are they emails sent directly to list of recipients (or a mailing list defined within the client or local MTA). The issue the Working Group is attempting to fix relates only to a very small amount of email that is sent to an email address and forwarded to a list of recipients, without creating a new email.
Technical users who subscribe to IETF mailing lists or similar services may see a disproportionately high number of emails forwarded from the original author, but in practice, they likely represent a tiny fraction of a percent of all email. It’s not a substantive issue that needs addressing, especially given this style of mailing list has already been forced to adapt, and what are contemporarily referred to as mailing lists are an entirely different type of email, with bulk senders already subject to requirements that make them fundamentally incompatible with the distribution list model.
In fairness to the authors, the use of the term “mailing list” in this way is consistent with historic usage, where it was used in defining the long-deprecated EXPN command. RFC 5321 still describes the basic operation of such lists, however, only when the operation of lists conform to the very limited set of modifications described within that specification is it permissible to treat list expansion as a continuation of email transit. Modern lists rarely conform to those requirements and the RFC is clear that further processing requires the mailing list software “to be viewed as full MUAs, which accept a delivery and post a new message.”
Unfortunately, RFC 5322, which defines the message format, is more vague in its definitions and while requiring a new message-id for new versions of a message, it leaves the determination of when it applies to the discretion of the sender. Nevertheless, there is no ambiguity, as the transport requirements for altered email, as per RFC 5321, require this to be a new email, which unequivocally requires a new message-id. The Working Group is therefore attempting to address an issue that only exists due to mailing list software (including the IETF’s own mailing list) not behaving in a way that complies with documented requirements.
Forwarding is a significantly more common scenario and legitimately worthy of consideration. In such instances, how the email is forwarded depends on the implementation – a new email may be created, but it’s often desirable to resend the original email without alteration. DKIM2 addresses the latter and a significant weakness in DMARC, where either DKIM or SPF is seen as a pass, by allowing subsequent changes to be unwound and the original signature verified.
This is arguably an improvement over the status quo, however, an alternative forwarding method already exists in the form of MIME encapsulation. Specifically, the 34+ year old message/rfc822 MIME type defined in RFC 1341, which is generally well supported by clients. Messages encapsulated in this way also have restrictions on transfer encoding that make it trivial for MTAs and filters to process, even without a full MIME implementation. A forwarder can simply encapsulate the original email within a new message, sign the new message and preserve the integrity of the original email, including its signatures, with no compromises.
Notwithstanding the above, even in the absence of encapsulation, such forwarding arrangements are a conscious decision of the receiving party and in doing so they should be applying some degree of trust to verification undertaken by and ideally recorded and signed, by the original receiving domain.
But wait! There’s more!
Beyond change tracking, DKIM2 seeks to address the issues of replay and backscatter, both of which are explicitly mentioned in the Charter.
The first and most important objective is signing the intent for an email to be delivered to a specific recipient. Currently, DKIM does not make any attempt to reconcile the recipient with the To or Cc fields of an email to determine if delivery to a specific address is intended, and if a recipient were sent using Bcc, no such intent can be verified. A valid DKIM-signed email can be replayed to recipients other than those to whom the original email was addressed. This is neither a flaw in DKIM, nor a contemporary issue, but this feature is highly beneficial to prevention of replay and backscatter and a worthy addition to any successor of DKIM.
In support of recipient signing, current DKIM2 proposals require implementations to create new instances of an email for each and every Bcc recipient. This is a departure from traditional SMTP functionality, where an email may be sent to multiple recipients on the same domain (Bcc or otherwise). The work necessary in support of this functionality will likely vary significantly between implementations.
This imposes a significant burden on systems that perform singing before relaying upstream to a smart host for delivery or which deliver directly as signing time, storage requirements and data usage increase proportionally with the number of Bcc recipients.
While some edge nodes sending email may have fast Internet connections, many will not. For those with fast connections, few come with guaranteed bandwidth. Add in various anti-spam techniques employed by upstream servers into the mix, such as graylisting and restrictions on the number of connections which will increase as a result of splitting email into multiple deliveries, and the ability to deliver email reliably and in a timely manner begins to suffer.
The resource requirements for a large email being distributed to a moderate number of recipients individually can be extensive, with signing time increasing from seconds to minutes, and a few tens of megabytes of storage or data ballooning to multiple gigabytes. A single email can bring an otherwise appropriately specced system to is knees.
Even without the additional complexities of DKIM2, it’s not unusual for email to be delayed significantly due to unforeseen issues. For several years, I oversaw the performance of commercial email systems. My priority was never avoiding a backlog, because the system architecture was such that they were always a possibility, but instead ensuring the rapid and reliable clearing for any backlogs should they occur.
In March, two service providers I used experienced issues with payment processing, resulting in unexpectedly large numbers of payment error messages being sent out to customers. One recovered gracefully, completing an automated transaction a few hours later. In the case of the second however, a service I have used reliably for in excess of eight years, the first I was aware of the issue was several days later when I received my third and final overdue invoice notice. Upon receiving this notice, I immediately completed payment, only to find that the uptime on my nodes had reset — the services had been restarted after suspension. Shortly after making payment, I received a notice of service suspension and subsequently the earlier late payment notices in reverse order, over a period of three days! Adding to the load is simply going to make such incidents more common and email less reliable.
A filter-based implementation, which the proponents of DKIM2 insist is possible, requires the filter to create and inject new email into the email system. This is a terrible approach, making DKIM2 highly prone to configuration errors, subject to silent failures and failures that are difficult to debug. When emails start randomly disappearing, is your first thought going to be that someone forgot to configure an interface specifically for DKIM2 to inject email that isn’t subject to rate or connection limits? Probably not!
During delivery, a receiving server will either accept or reject each recipient before accepting the email content. Once the email is handed over, however, it is assumed the server will take full responsibility for delivery from that point forward for all recipients the server indicated acceptance for.
What happens if the filter cannot create a new instance of an email due to a configuration error or resource constraint? A filter implementation may have already created and injected new instances of the email. One solution would be to retry, but that forces the DKIM filter to be a persistent process with background processing capabilities and retry logic – essentially making the filter an MTA because of an irrational desire to keep the necessary functionality out of the actual MTA.
After accepting the email, an SMTP server can no longer reject the recipient and the only way to inform the sender of a delivery issue is to send a bounce message. That’s possibly acceptable if the sender is a human with an actively monitored inbox who understands that the bounce is indicative of a temporary issue, but if it’s an automated message or system which normally sends only, you now have a mismatch between what the sender understands to have been sent and what was actually processed.
If you rely on bounces, where is it going to be generated? It appears to be the intention for the MTA to do so, but bounces may be disabled to avoid backscatter (the issue DKIM2 seeks to resolve), so the MTA may not even generate one. A MTA, with no DKIM-specific logic, likely has no way of knowing if a rejection from a particular filter should result in a bounce or not, and even if configurable, isn’t going to know if the bounce is due to DKIM failure or a submission error, because a filter only assigns a pass or fail grade. The filter itself could plausibly create a bounce, but that too would be subject to the same limitations that possibly caused the failure in the first place. Reliably handling email and ensuring the correct information is available during the SMTP session requires additional logic that can only be implemented within the MTA itself.
It is noteworthy that a repository of source code for DKIM2 interoperability testing, which continues regular updates along with changes to the proposed standards, makes no attempt whatsoever at handling Bcc recipients.
While preparing this text, Gondwana made a significant statement on the mailing list regarding the true feasibility of a purely filter-based approach. He noted the demo uses “a pipe(8) transport that shells out to the DKIM2 library and re-injects on a milter-free port. It’s convenient for the propagation case and for a demo, but you’re right that it’s fragile and per-MTA. It’s a stopgap, not the intended end state. The point of doing it with a pipe + a milter today is to prove the whole thing is implementable on an unmodified MTA and to let the implementations interoperate now. The expectation is absolutely that DKIM2 support lands natively in the MTAs (Postfix/Exim/Sendmail) — the same path DKIM1 took from milter to native — and that operators shouldn’t have to hand-roll a pipe per box.”
There we go. Admission that DKIM2 is intended to become part of the MTA, and therefore deeply integrated into SMTP itself. The statement about DKIM moving from milter to native is incorrect as many implementations still rely on filters and the specification does not necessitate core SMTP modifications (or filter hacks) the way DKIM2 does. This gives DKIM users a choice of implementation and the ability to use the wider feature set DKIM offers, catering to use cases that MTA implementations do not support.
If we ignore the impracticality and assume a filter could reliably create new email instances, an implementation would additionally need to be able to distinguish between not only multiple instances of an email it (or another server on the domain) has created, but also between those and subsequent copies of the same email that may be subsequently observed. These emails may be forwarded copies or even revised versions resent by a mailing list or forwarder. This greatly limits the potential for any cryptographic optimizations, because it cannot be assumed that a cached signature is valid based on what should be a unique identifier, the message-id.
DKIM2 proposes several flags, such as “donotexplode”, which is intended to inform MTAs that an instance of a message is intended for a single recipient. To make use of this or any similar flag, the DKIM2 implementation must track the recipients of incoming email. That creates a completely different set of problems, such as determining what to do if an email is subsequently forwarded through the same server to a new recipient, after having been explicitly informed of the intent to send to specific recipients.
Surely, the best approach is therefore to avoid re-entrant scenarios altogether? Not only is this possible, it’s a tidier and easier to implement solution than forcing MTA functionality into filters, preserving the linear processing that exists in DKIM today, with minimal added complexity.
Despite its impracticality, the proponents of DKIM2 continue to their approach as being implementable. Far from being a tidy filter-based solution, their approach actually pushes necessary logic outside the realm of SMTP altogether.
DKIM has several use cases that are not only valid, but explicitly documented in RFCs and actively used that DKIM2 simply abandons, leaving no forward migration path. Failure to cater to these use cases is highly concerning, given DKIM2 is seen as a replacement for DKIM and something that receivers will likely one day insist on.
Examples of several such configurations are provided in RFC 6376, Appendix B.1 “Alternative Submission Scenarios”. These include use cases where email is not sent via a domain’s normal email system, for practicality, policy or security reasons.
In an elevated risk environment such as a VPS on shared hardware for example, it is desirable to avoid exposing either SMTP credentials or the private key for other business functions. Such systems may instead opt to sign and deliver email using a unique private key, limiting the effects to email signed using that particular key if the system were compromised. This type of configuration may be used for a range of functions, such as Web form submissions or scripts sending notifications of system issues. Similar configurations may also be used for roaming users who routinely sent email via limited mobile or hotel Wi-Fi connections, relaying via another host for deliverability reasons, not signing purposes.
The requirement for special handling of some recipients at the time of signing means any system that wishes to include a recipient via Bcc will no longer be able to submit a single pre-signed email for distribution via an upstream MTA. This shifts delivery logic that would normally exist entirely within the scope of MTAs onto any applications or script that delivers via SMTP.
A script which sends notifications of system issues to multiple technicians for example, would no longer be able to send a single email, implementing minimal retry logic should the email fail, but instead would need to create multiple instances of an email and track the delivery status of each.
Again, this is added complexity for everyone, due to an inane desire to avoid a simple extension.
In response to concerns being raised regarding lack of a migration path for users with requirements outlined in Appendix B.1, and in particular the requirement for Bcc recipients to be split prior to signing, Gondwana’s advice was to ignore a compulsory requirement explicitly required by his own specification and place Bcc recipients within DKIM2 headers, exposing their identity for all to see.
The second mechanism said to be required for backscatter prevention is rewriting the MAIL FROM address at every hop. This is said to form a chain of custody, with bounces sent back along the chain.
Many ESPs already perform MAIL FROM rewriting to track bounces. They do so primarily for reputation reasons, blocking future attempts at sending to invalid addresses. While they usually make this information available to customers out of band, via their Web interface or API, they typically do not take the extra step of tracking the original MAIL FROM and sending a bounce to the originator of the email. While DKIM2 has a small benefit in theory, preserving the original MAIL FROM in the original signature of the sender, this would only apply if the email were pre-signed using DKIM2. The vast majority of ESPs do not cater to users who wish to sign their own email at all and DKIM2 provides no incentive for this practice to change.
MAIL FROM should only be set or updated when an email is created or forwarded to a new recipient, as is currently the case. Once the integrity of the email has been established, along with the intent for a specific entity to send to a specific recipient, a chain of custody ceases to be relevant. Recipient signing alone can achieve the objective of avoiding backscatter and would permit an MTA to safely send a bounce to the MAIL FROM address. The email could in theory still be replayed to the intended recipient, however, DKIM2 doesn’t directly address that issue either.
The requirement for rewriting MAIL FROM further complicates implementations, increases email volume and reduces bounce reliability, while offering no substantive benefit over simply signing recipients.
Balance
There are no novel issues mentioned here. All these concerns have been raised by a small group of participants on the mailing list, yet there is little appetite from Working Group members to resolve or even discuss these issues. Valid technical issues more often than not remain unaddressed, or countered with unsubstantiated opinions devoid of any technical argument.
Unsurprisingly, there has been little effort by proponents of the current DKIM2 proposals to offer any technical justification beyond weak arguments made in the motivations document, and the Chairs who should be ensuring technical issues are resolved, aren’t pushing for it. The Working Group is begging the question by accepting a motivations document, authored by the very people whose proposals they’re defending, as if it were authoritative. By doing so, they avoid examining whether the document’s claims are sound or what consequences its prescribed approaches would actually produce.
IETF Working Groups operate on the principle of rough consensus. You can’t please everyone, but the standard of evidence required is essentially zero – it’s entirely at the discretion of Working Group Chairs to determine when rough consensus has been reached on technical issues or the direction the Working Group is taking.
Following the failed ARC experiment, people with an interest in ARC are being directed towards the DKIM Working Group, based on the claim that the lessons learned with ARC would be incorporated into DKIM2. This is creating an echo chamber of people with an interest in ARC and its objectives, pushing aside the interest of those who wish to extend DKIM and preserve its integrity as the only sender-focused authentication mechanism in an environment which is heavily driven by the demands of a handful of operators.
The authors of the current proposals have been active in the IETF for a significant period of time. While this gives them credibility, it doesn’t make their approach correct, especially when you consider their preference for an ARC-like system and they interests they represent.
Richard Clayton, Yahoo!
Wei Chuang, Google
Bron Gondwana, Fastmail Pty Ltd
Gondwana has stated that “the people dealing with large volumes of incoming mail want attribution, because it lets them more accurately distinguish who the current bad actors are.” So what?
Standards exist to ensure interoperability, not to satisfy the demands of a few. Quantity of incoming email is also only single metric and volume alone does not mean their desires take precedence over the needs of the majority.
The current proposals unduly benefit larger providers such as Google, Microsoft and Fastmail, all of which provide email hosting services. While Fastmail may be small in comparison to Google and Microsoft, they are still one of the larger providers by some metrics. The additional cost and complexity of email hosting created by DKIM2 will drive more organizations away from self-hosted solutions and towards providers that offer complete hosting services. At the same time, smaller operators may no longer be able to compete due to their own hosting requirements increasing significantly with the additional demands not only in terms of system resources, but additional skill requirements to manage distributed database infrastructure which has no place in email transit.
What about the needs of senders? These are the group I work most with, sending primarily transactional email. These senders require reliable delivery and desperately need relief from the relentless demands of email receivers and their opaque handling of email. Senders are being forced down the path of using third parties and hosting services because companies like Google, Yahoo!, Microsoft and Fastmail are consciously making delivery difficult.
By addressing the ability for email to be replayed to recipients other than those to which it was intended, DKIM indeed can replace DMARC, SPF and many other filtering techniques, because the content and intent for a recipient to receive the email can be cryptographically verified as originating from a specific domain and selector. That is the only reputation that matters. Any filtering based on external factors such as IP range becomes largely irrelevant. DKIM with minor enhancements can therefore improve deliverability for those who had previously been forced to rely on a third party for delivery success. I don’t think it’s out of line to suggest that this is something the big players don’t want, because they profit from users being forced to use their systems. It is in their best interest to make email delivery as expensive and impractical as possible, so they can maintain their market dominance.
Working Group Chairs should be guiding conversation within the Charter and technical soundness, but have instead curtailed discussions of those who oppose the favored approach.
The most vocal opposition has come from Steffen Nurpmeso, who has published a competing proposal. I have not reviewed his proposal in full as unfortunately Nurpmeso is not a native English speaker and the document is difficult to read, however, the technical issues he has raised on the mailing list regarding the Clayton and Gondwana proposals have been on point. His comments have, however, twice lead to his posting on the list being subject to moderation. While I agree this action may have been appropriate, the Chairs never explicitly stated what his transgression was, so I am unable to state it here. What is clear, however, is IETF guidelines request participants make a sincere effort to understand and clarify what is meant when communicating with non-English speakers. Regardless of whether Nurpmeso’s comments were intentional or the result of the language barrier, I can certainly understand his frustration with a Working Group that does not wish to hear any criticism of their direction or favored proposals.
Perhaps more significant is not the action taken against Nurpmeso, but the discussion which lead to his second moderation. Vittorio Moccia recently published another proposal. While Moccia is also interested in ARC, his approach is more pragmatic and aimed to create a standard that could genuinely be implemented using filters, separating core DKIM2 functionality from change tracking. Like Nurpmeso, Moccia has cited specific implementation issues with Clayton and Gondwana. Moccia, however, has been been very persistent, following up on the replies he received, seeking technical justification and continuing to update his proposal.
During discussion of Moccia’s proposal, he asked if MTA developers had been consulted. R. Latimer responded indicating that no specific consultation had been carried out and recounting his discussions with MTA developers which primarily centered around an implementation detail, noted that he “would not characterise the feedback on the proposal itself as positive”. Chair, Pete Resnick responded to this warning Latimer not to talk on behalf of others, stating his comments were inappropriate.
Resnick then went on to cite the past participation of Philip Guenther and Trent Adams from Proofpoint as proof of the awareness of MTA developers, a statement which Philip Guenther, who had not been regularly active on the mailing list, later responded to. Guenther not only clarified that prior participation in an unrelated discussion did not imply a deep review of the proposal had been carried out, but also stated “reversibility of some those changes from the message received is the opposite of a goal for our customers and, therefore, for us”.
So, here we have a Chair speaking on behalf of named individuals, implying some degree of support and falsely claiming prior participation equated to something more than that, while at the same time admonishing a participant for merely giving their impression of how unnamed contacts of theirs viewed the proposal.
Resnick also posted to the list indicating he and co-chair Murray S. Kucherawy had been watching the discussion and were “willing to allow it to go on a bit longer”. Despite acknowledging the discussion had identified issues with the current proposals, he went on to state that “if people are not convinced that our approach needs to change, we’re going to close down this discussion soon.” Given the thread was otherwise civil and productive, it’s difficult to view this statement as anything other than an attempt to shut down dissenting discussion.
While such behavior is unbecoming of a Working Group Chair, Resnick is a former IETF Ombudsman and the author of the IETF Anti-Harassment Procedures. His behavior therefore should be irreproachable.
I had intended to continue this post, outlining my view of what DKIM2 should look like, however as this post is already significantly longer than intended, I will instead outline that in a new post. That will also keep the politics out of it and will allow me to focus on the technical merit of a DKIM-first approach, which is what the DKIM Working Group should be considering first and foremost.