Aggregate Reports for DKIM Signers

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 February 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

With a growing emphasis on email security, the industry is rapidly adopting message authentication mechanisms such as DKIM and SPF. While many initiatives, including DMARC, aim to enhance message validation through their reporting features, they often fall short in meeting the diverse needs of all stakeholders in the email delivery process. Moreover, these mechanisms aren't always effective in identifying certain abuses, like DKIM replay.¶

A notable challenge arises with marketing and transactional messages, which often contain multiple valid DKIM signatures. While DMARC reports can provide information to the 5322.From Domain holder, some DKIM signers may not receive a copy of that information. This gap in information could result in a lack of understanding when there is an issue with authentication.¶

2. Glossary

• DKIM (DomainKeys Identified Mail): An email authentication method utiilizing a cryptographic signature.¶

• DMARC (Domain-based Message Authentication, Reporting & Conformance): An email authentication mechanism that uses SPF and DKIM to verify the use of the domain in an email's visible From: header.¶

• SPF (Sender Policy Framework): An email authentication method using an IP-based configuration.¶

• Replay Attack: A malicious technique where an attacker intercepts and retransmits a valid data transmission, often to impersonate another user or entity.¶

• Selector: A string used by the DKIM system to help identify the DKIM public key information.¶

• GUID (Globally Unique Identifier): A unique reference number used as an identifier in software.¶

• DNS (Domain Name System): A system for converting human-friendly domain names into IP addresses.¶

• 5322.From domain: The domain present in the "From:" field of an email, as defined in RFC 5322.¶

• Aggregate Report: Summarized feedback about messages purported to come from a specific domain during a specified period.¶

3. Enhanced Awareness For Validation Outcome

Visibility into DKIM signatures responsible for message authentication can be fairly important to system operators, perhaps more so when the signatures do not align with the 5322.From Domain. Allowing receivers to inform signers about potential validation errors could aid in resolving those issues, and allow for better authentication for the given message stream.¶

4. Decoding DKIM Reports: Insights and Implications

The essence of DKIM aggregate reports is to furnish Signing Domain Owners with a thorough understanding of the following:¶

• Authentication Results: The outcomes from various verification checks provide an indication of how receivers evaluate the messages. It's crucial for signing domain owners to comprehend the frequency of their successful authentications and pinpoint potential areas for improvement.¶

• Trust in Original Senders: Before applying signatures to future messages, signing domain owners need to evaluate the credibility and reliability of the submission entity. If issues or inconsistencies arise in reports, it might signal that the original sender's practices aren't aligned with the signing domain owner's standards, leading to reconsideration of the signing relationship.¶

OR¶

• Evaluation of Submitting Entity: Allowing the signing entity to understand if the signer would like to continue to sign on behalf of the submitter. If the submitter has questionable practices, the signing may not wish to continue signing on behalf of that submitter.¶

• Indications of DKIM Replay: DKIM replay involves the malicious reuse of a previously signed email by unauthorized entities. By identifying signs like SPF zone misalignment or unexpected volume discrepancies, signing domain owners can address potential threats and maintain the integrity of their emails.¶

5. Configuring DKIM Aggregate Reporting: A Guide to DNS Records

Email security necessitates clear and accurate configuration. As domains employ authentication mechanisms, they must follow technical specifications, as well as best common practices. Domain owners may choose to use their own resources for this, or utilize a third-party to assist them with various parts of the process or on-going operations.¶

6. DNS Entry Format

There are a number of methods by which a domain can declare the intention to receive reports:¶

v: This MUST be "RDKIM". If this is absent, the record is invalid.¶

tgt: The location(s) for reports. Methods can be requested as mailto. Be mindful that more than one can be requested but not all receivers will support all varieties. Each mechanism has more detail below. If a mistake in the record is found by the receiver, the entirety of the record should be ignored.¶

rfr: This is a pointer to another domain to use their data. May be used in conjunction with a tgt attribute. This should take the format of the FQDN, i.e., "v=RDKIM;rfr:_report.selector._domainkey.foo.com".¶

7. Dual (Or More) Signed Messages

When a message has multiple signatures which verify, the reporter SHOULD send reports to all signatories who have requested reports. In the case where two (or more) signatures have the same destination tgt, this should still generate as many reports as there are valid signatures.¶

NOTE, this needs to be expanded.¶

8. Feedback Mechanisms

9. Report Format

This format will be an XML file.¶

NOTE: There's no true reason to keep this as XML, JSON is an option.¶

A sample file:¶

<?xml version="1.0" encoding="UTF-8"?>
<feedback xmlns="urn:ietf:params:xml:ns:dkimaggreport-1.0">
    <report_metadata>
        <org_name>Reporter Company</org_name>
        <email>contact@receiver.net</email>
        <extra_contact_info>dest_domain: foo.net</extra_contact_info>
        <report_id>GUID_HERE</report_id>
        <date_range>
            <begin>151061515</begin>
            <end>151071241</end>
        </date_range>
    </report_metadata>
    <signature>
        <domain>example.org</domain>
        <selector>delegatedselector</selector>
    </signature>
    <record>
        <row>
            <source_ip>10.123.23.12</source_ip>
            <spf_domain>botnet.example</spf_domain>
            <spf_result>pass</spf_result>
            <spf_alignment>fail</spf_alignment>
            <dkim_passed>123</dkim_passed>
            <dkim_failed>1</dkim_failed>
            <dkim_alignment>true</dkim_alignment>
            <from_domain>example.org</from_domain>
            <extensions>
              <extension def="https://site.com/ext_def">
                ...
              </extension>
            </extensions>
        </row>
        <identifiers>
            <sample_msg_id>uuid@bounces.example.org</sample_msg_id>
        </identifiers>
    </record>
    <extensions>
      <extension def="https://site.com/ext2_def">
        ...
      </extension>
    </extensions>
</feedback>

10. Security Considerations

11. Contributors

12. Notes

13. References

1. RFC5322: "Internet Message Format". IETF.¶

2. RFC6376: "DomainKeys Identified Mail (DKIM) Signatures". IETF.¶

3. RFC7489: "Domain-based Message Authentication, Reporting, and Conformance (DMARC)". IETF.¶

4. RFC7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email". IETF.¶

Author's Address