DKIM Signing Domain Reliance Level

Restoring trust in email requires establishing rigorous practices that are not prone to exploitation. These practices must also provide visible affirmations that are not easily circumvented. Visible affirmations can be automated folder selection, or annotations similar to message priority. For DKIM , the signing domain can be affirmed when the domain of a verified signature is found within a list of trusted signing domains maintained by the recipient. Even a minimal amount of annotation conveying the list's affirmation, such as selectively indicating a reliance level, offers significant proactive protection from prevalent spoofing attempts. Even when the signing domain is not immediately visible, this protection is still achieved. When only the display-name is visible or when internationalization is employed, email-address recognition remains an area increasingly prone to exploitation. Even expections that a significant email-address is apparent to the recipient can be confounded by valid emails where a purported originating email-address is not typically visible, or where this email-address is not within the signing domain, or where there is more than one purported originating email-address. The normally displayed content of a message is simply not assured to provide a clear indication of the actual signing domain or even the originating email-address. Some advocate mechanisms that are based upon published use-profiles for email-addresses. These email-address use-profile mechanisms are nevertheless easily exploited. Protections based upon email-address use-profiles assume the recipient is able to recognize the email-address, and also recognize when requisite exceptions are being made. Use-profile protections still leave the recipient at risk when a deceptive email-address is mistakenly recognized as being from a trusted source. Use-profile acquisition can also greatly increase the overall overhead and convey information that is not verified by the DKIM signature. Email-address use-profiles are of little value when a list of trusted DKIM signing domains is maintained by or available to the recipient. The DKIM signature is far better leveraged when affirmed by a trusted signing domain list. A trusted signing domain list offers proactive protection by enabling safer message annotation and screening. A trusted signing domain list strategy does not depend upon the recipient's visual acuity, or upon reactive block lists of similar-looking domains held by bad actors. The trusted signing domain list could be compiled and maintained by the recipient or by a trusted community of users. When first subscribing to services from a reputable entity and then receiving a message containing their pass-phase, this method of introduction allows a recipient to safely add the signing domain to their list of trusted signing domains. Any signing entity may find that some messages being signed are from poorly-vetted sources. An inability of the recipient to distinguish well-vetted sources substantially reduces the trust that the signing domain may desire to retain for these specific sources. While signing domains could partition email-addresses into sub-domains in order to consolidate similarly vetted sources, this approach will likely confuse recipients with respect to what is to be trusted. The absence of a partitioning mechanism may actually induce a bad practice of using multiple domain names, which includes the use of sub-domains. Partitioning by changing the right hand side of the email-address is currently the only method available to signing domains wishing to retain trust for a specific category of messages. The added complexity induced by an increase in domain names may enable an increase in exploitations. Delegating trust differentially at the sub-domain is also disruptive with the need for email-address reassignment. To avoid this outcome, the signing domain must be provided a means to partition the vetting of message sources within a common domain at the outset of DKIM deployment. Partitioning by way of email-address use-profiles requires two additional sequential transactions, a separate use-profile for both the right and left hand side of the email-address. Email-address use-profiles of the left hand side, as a means to partition the domain, also represent a significant increase in the number of requisite transactions. The Reliance Level parameter as described below avoids this inordinate overhead. A simple Reliance Level parameter, added to the DKIM signature and the key, provides the signing domain a means to partition their sources. This partitioning reduces possible damage by being able to act as a warning for recipients. The reliance level warning thereby retains greater trust for messages at a higher reliance level. The application of this mechanism does not require additional overhead when assessing the message. The reliance mechanism can directly and immediately affect message handling and annotation. The Reliance Level parameter better ensures precautions are not inappropriately bypassed for specific messages, even for those from otherwise generally trusted domains.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The Reliance Level parameter allows the signing domain a means to partition internal sources into three categories. When the Reliance Level parameter is optionally omitted at either the key or the signature, the Reliance Level defaults to Normal. The Reliance Level indicated within the signature header field must not exceed the Reliance Level indicated within the key, or the signature SHOULD be considered invalid. An indication of a Low Reliance Level warns the recipient to be cautious, whereas a High Reliance Level offers added assurances by the signing domain. The Reliance Level uses the "r=" tag in both the signature and key, where the value is represented as a plain-text signed decimal integer. The Low Reliance Level has the negative value -1. The Normal Reliance Level has a value of 0, and the High Reliance Level has a positive value of 1. Values greater than 1 or less than -1 are undefined. For message handling, these undefined values SHOULD be considered equivalent to a value of 1 or -1 respectively to permit future enhancements. Level Description r=-1 Low Reliance (poorly-vetted) r=0 Normal Reliance (default) r=1 High Reliance (well-vetted)

The parameter prefix 'r=' used in both the DKIM signature and DKIM key will require registration by IANA.

This document describes an option for adding a DKIM signing domain assertion. The recipient is not expected to reliably recognize an email-address for many reasons, where the signing domain assertion improves upon the safe handling and annotation of DKIM signed messages. In general, special handling is required before DKIM offers the recipient any added protection, as the DKIM signature itself is intentionally transparent. This special handling may include annotation or content screening. When the recipient elects to trust the signing domain, the signing domain should also be able to directly offer their vetting assessments to better protect this trust. Without the signing domain's assessment, recipients are unable to discern any differences in the signing domain's vetting of the message source and would need to handle all messages in the same manner. DKIM does not require that an email-address be within the signing domain. Even when the DKIM signature references a specific email-address contained within the signing domain, there is no means to impart to the recipient the level of vetting that was achieved by the signing domain, without the reliance mechanism. While the recipient may attempt to make separate assessments of the referenced email-address, such assessments may further burden the recipient and would be based upon information not verified by the DKIM signature.