DomainKeys Identified Mail (DKIM) and Mailing Lists
DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). This memo documents an Internet Best Current Practice.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 0 must, 29 should, 7 may.
4.1 Author-Related Signing
- SHOULDFor domains that do publish strict ADSP policies, the originating site SHOULD use a separate message stream (see Section 2.5), such as a signing and Author subdomain, for the "personal" mail -- a subdomain that is different from domain(s) used for other mail streams.
- SHOULDTherefore, site administrators wishing to employ ADSP with a "discardable" setting SHOULD separate the controlled mail stream warranting this handling from other mail streams that are less controlled, such as personal mail that transits MLMs.
4.2 Verification Outcomes at Receivers
- SHOULDSites whose users subscribe to non- participating MLMs SHOULD ensure that such user mail streams are not subject to strict DKIM-related handling policies.
4.3 Handling Choices at Receivers
- SHOULDTherefore, participants SHOULD honor the policy and disallow the message.
5.1 General
- RECOMMENDEDIt is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy.
- RECOMMENDEDIt is also RECOMMENDED that standard header fields, rather than body changes, be used to express list operation parameters.
5.2 DKIM Author Domain Signing Practices
- SHOULDA resending MLM SHOULD reject outright any mail from an Author whose domain posts such a policy, as those messages are likely to be discarded or rejected by any ADSP-aware recipients.
- SHOULDWhere such rejection of "discardable" mail is not enforced, and such mail arrives to a Verifier that applies ADSP checks that fail, the message SHOULD be either discarded (i.e., accept the message at the [SMTP] level but discard it without delivery) or rejected by returning a 5xx error code.
5.3 Subscriptions
- SHOULDAt subscription time, an ADSP-aware MLM SHOULD check for a published ADSP record for the new subscriber's domain.
- SHOULDIf the policy specifies "discardable", the MLM SHOULD disallow the subscription or present a warning that the subscriber's submissions to the mailing list might not be deliverable to some recipients because of the published policy of the subscriber's ADMD.
- MAYAn MLM implementation MAY do periodic checks of its subscribers and issue warnings where such a policy is detected or simply check upon each submission.
5.5 Author-Related Signing
- SHOULDIn that case, Authors SHOULD create a mail stream specifically used for generating DKIM signatures when sending traffic to MLMs.
- SHOULDMail that is of a transactional or generally end-to-end nature, and not likely to be forwarded around by either MLMs or users, SHOULD be signed with a mail stream identifier different from that used for a stream that serves more varied uses.
5.6 Verification Outcomes at MLMs
- MAYA message that cannot be thus authenticated MAY be held for moderation or rejected outright.
- MAYIn particular, this improved authentication MAY apply to subscription, unsubscription, and/or changes to subscriber options that are sent via email rather than through an authenticated, interactive channel such as the web.
- SHOULDIn the case of verification of signatures on submissions, MLMs SHOULD add an [AUTH-RESULTS] header field to indicate the signature(s) observed on the submission as it arrived at the MLM and what the outcome of the evaluation was.
5.7 Signature Removal Issues
- RECOMMENDEDHowever, if the MLM is configured to make changes to the message prior to reposting that would invalidate the original signature(s), further action is RECOMMENDED to prevent invalidated signatures from arriving at final recipients, possibly triggering unwarranted filter actions.
- SHOULDThis can be generalized as follows: a Receiver SHOULD consider only [AUTH-RESULTS] fields bearing an authserv-id that appears in a list of sites the Receiver trusts and that is also included in the header hash of a [DKIM] signature added by a domain in the same trusted list.
5.8 MLM Signatures
- SHOULDDKIM-aware resending MLMs and authoring MLMs SHOULD affix their own signatures when distributing messages.
- NOT RECOMMENDEDHowever, selective signing is NOT RECOMMENDED; essentially that would create two message streams from the MLM, one signed and one not, which can confuse DKIM-aware Verifiers and Receivers.
- SHOULDA DKIM-aware resending MLM SHOULD sign the entire message after the message is prepared for distribution (i.e., the MLM Output from Section 3.2).
5.9 Verification Outcomes at Final Receiving Sites
- SHOULDIn general, Verifiers and Receivers SHOULD treat a signed message from an MLM like any other signed message; indeed, it would be difficult to discern any difference since specifications such as [LIST-URLS] and [LIST-ID] are not universally deployed and can be trivially spoofed.
5.10 Use with FBLs
- SHOULDSuch operators SHOULD send a report to each domain with a valid signature that has an FBL agreement established, as DKIM signatures are claims of some responsibility for that message.
- SHOULDMLM operators SHOULD register with FBLs from major service providers.
- SHOULDIn the context of DKIM, there SHOULD be an exchange of information with the FBL provider including what signing domain the MLM will use, if any.
- MAYWhere the FBL wishes to be more specific, it MAY act solely on a DKIM signature where the signing domain matches the DNS domain found in a List-Post: header field (or similar).
- SHOULDUse of FBLs in this way SHOULD be made explicit to list subscribers.
5.11 Handling Choices at Receivers
- MAYA recipient that explicitly trusts signatures from a particular MLM MAY wish to extend that trust to an [AUTH-RESULTS] header field signed by that MLM.
- MAYThe recipient MAY then do additional processing of the message, using the results recorded in the Authentication- Results header field instead of the original Author's DKIM signature.
- SHOULDReceivers SHOULD ignore or remove all unsigned externally applied Authentication-Results header fields and those not signed by an ADMD that can be trusted by the Receiver.
- MAYUpon DKIM and ADSP evaluation during an SMTP session (a common implementation), an agent MAY decide to reject a message during an SMTP session.
- SHOULDHowever, if the SMTP server supports [ENHANCED] status codes, a status code not normally used for "user unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be used.
- SHOULDIn particular, a policy rejection SHOULD be relayed using the above enhanced status code and some appropriate wording in the text part of the reply.
- SHOULDThose MLMs that automatically attempt to remove users with prolonged delivery problems (such as account deletion) SHOULD thus detect the difference between policy rejection and other delivery failures and act accordingly.
- SHOULDIn such cases where the submission fails that test, the Receiver or Verifier SHOULD discard the message but return an SMTP success code, i.e., accept the message but drop it without delivery.
6 DKIM Reporting
- SHOULDMLMs SHOULD apply DKIM failure-reporting mechanisms as a method for providing feedback to Signers about issues with DKIM infrastructure.