Set up new dkim milter #582

jchristgit · 2025-04-20T17:33:23Z

The existing opendkim milter is no longer maintained.
This commit introduces a role which deploys dkim-milter.
As-is, it is not a complete replacement, since the role does not (yet)
migrate keys of the old opendkim setup.

github-actions · 2025-04-20T17:34:00Z

OctoDNS Plan for `new-dkim-milter`

pythondiscord.com.

cloudflare

Operation	Name	Type	TTL	Value	Source
Delete	_acme-challenge	TXT	120	DpNMkDbvV6A8DYCi5m-qERyNTtO9E28w2fqc1P-COvA; NYdLAk9Q7_b9CbgybIhPXI6ZkAH7SwNOHV4uSKmX1ls
Delete	cf2024-1._domainkey	TXT	300	v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiweykoi+o48IOGuP7GR3X0MOExCUDY/BCRHoWBnh3rChl7WhdyCxW3jgq1daEjPPqoi7sJvdg5hEQVsgVRQP4DcnQDVjGMbASQtrY4WmB1VebF+RPJB2ECPsEDTpeiI5ZyUAwJaVX7r6bznU67g7LvFq35yIo4sdlmtZGV+i0H4cpYH9+3JJ78km4KXwaf9xUJCWF6nxeD+qG6Fyruw1Qlbds2r85U9dkNDVAS3gioCvELryh1TxKGiVTkg4wqHTyHfWsp7KD3WQHYJn0RyfJJu6YEmL77zonn7p2SRMvTMP3ZEXibnC9gz3nnhR6wcYL8Q7zXypKTMD58bTixDSJwIDAQAB

Summary: Creates=0, Updates=0, Deletes=2, Existing=34, Meta=False

pythondiscord.org.

cloudflare

Operation	Name	Type	TTL	Value	Source
Delete	cf2024-1._domainkey	TXT	300	v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiweykoi+o48IOGuP7GR3X0MOExCUDY/BCRHoWBnh3rChl7WhdyCxW3jgq1daEjPPqoi7sJvdg5hEQVsgVRQP4DcnQDVjGMbASQtrY4WmB1VebF+RPJB2ECPsEDTpeiI5ZyUAwJaVX7r6bznU67g7LvFq35yIo4sdlmtZGV+i0H4cpYH9+3JJ78km4KXwaf9xUJCWF6nxeD+qG6Fyruw1Qlbds2r85U9dkNDVAS3gioCvELryh1TxKGiVTkg4wqHTyHfWsp7KD3WQHYJn0RyfJJu6YEmL77zonn7p2SRMvTMP3ZEXibnC9gz3nnhR6wcYL8Q7zXypKTMD58bTixDSJwIDAQAB

Summary: Creates=0, Updates=0, Deletes=1, Existing=4, Meta=False

pydis.wtf.

cloudflare

Operation	Name	Type	TTL	Value	Source
Delete	_acme-challenge	TXT	120	bAMtYtCdS3WoIRItvSJ-J3JijCtFx-iUsyvd0jYTVdM
Delete	cf2024-1._domainkey	TXT	300	v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiweykoi+o48IOGuP7GR3X0MOExCUDY/BCRHoWBnh3rChl7WhdyCxW3jgq1daEjPPqoi7sJvdg5hEQVsgVRQP4DcnQDVjGMbASQtrY4WmB1VebF+RPJB2ECPsEDTpeiI5ZyUAwJaVX7r6bznU67g7LvFq35yIo4sdlmtZGV+i0H4cpYH9+3JJ78km4KXwaf9xUJCWF6nxeD+qG6Fyruw1Qlbds2r85U9dkNDVAS3gioCvELryh1TxKGiVTkg4wqHTyHfWsp7KD3WQHYJn0RyfJJu6YEmL77zonn7p2SRMvTMP3ZEXibnC9gz3nnhR6wcYL8Q7zXypKTMD58bTixDSJwIDAQAB

Summary: Creates=0, Updates=0, Deletes=2, Existing=45, Meta=False

jb3 · 2025-04-20T17:36:51Z

Remind me, does this replace the sending of DKIM reports to sender domains when we fail validation?

Can we still copy failing domains into a mailbox? Are we still performing validation of inbound email?

jchristgit · 2025-04-20T19:08:41Z

Hi!

Remind me, does this replace the sending of DKIM reports to sender domains when we fail validation?

I'm afraid not, no. But maybe we could 1. open an upstream issue and / or contribute it? -> https://codeberg.org/glts/dkim-milter

Can we still copy failing domains into a mailbox?

Could you clarify what you mean with "failing domains" - like anything failing validation? I don't think this supports that either, sorry. But again, we could ask upstream?

Are we still performing validation of inbound email?

Yes, anything failing validation is rejected at heaven's gate.

jb3 · 2025-04-20T19:37:18Z

I'm afraid not, no. But maybe we could 1. open an upstream issue and / or contribute it? -> https://codeberg.org/glts/dkim-milter

Sounds good, I'm not super fussed over this one.

Could you clarify what you mean with "failing domains" - like anything failing validation? I don't think this supports that either, sorry. But again, we could ask upstream?

Also sounds good for asking upstream. My concern is that we risk creating an invisible delivery problem here. For example, this sounds like it would instantly auto-reject your mailing list mails without it being visible (copied into an inbox like it currently is, though this might be OpenDMARC?). We should probably configure some DKIM rejection alerts if we don't have the visibility from mail being copied. Our OpenDMARC deployment does handle some of this (maybe more than I think?) so I will go away and check what OpenDKIM handles and what OpenDMARC handles. Basically, as long as instead of rejecting we put stuff into mailq (which might be the behaviour, I was unsure where "heaven's gate" is in this instance.

…

On 4/20/25 20:09, jchristgit wrote: jchristgit left a comment (python-discord/infra#582) Hi! > Remind me, does this replace the sending of DKIM reports to sender domains when we fail validation? I'm afraid not, no. But maybe we could 1. open an upstream issue and / or contribute it? -> https://codeberg.org/glts/dkim-milter > Can we still copy failing domains into a mailbox? Could you clarify what you mean with "failing domains" - like anything failing validation? I don't think this supports that either, sorry. But again, we could ask upstream? > Are we still performing validation of inbound email? Yes, anything failing validation is rejected at heaven's gate.

jchristgit · 2025-04-21T11:11:39Z

On Sun, Apr 20, 2025 at 12:37:41PM -0700, Joe Banks wrote: jb3 left a comment (python-discord/infra#582) > I'm afraid not, no. But maybe we could 1. open an upstream issue and / or contribute it? > -> https://codeberg.org/glts/dkim-milter Sounds good, I'm not super fussed over this one. > Could you clarify what you mean with "failing domains" - like anything failing validation? > I don't think this supports that either, sorry. But again, we could ask upstream? Also sounds good for asking upstream. My concern is that we risk creating an invisible delivery problem here. For example, this sounds like it would instantly auto-reject your mailing list mails without it being visible (copied into an inbox like it currently is, though this might be OpenDMARC?).

I read a bit through OpenDMARC docs and tutorials together with OpenDKIM. I understand that this might be handled by OpenDMARC. In other news, OpenDMARC is not maintained anymore either. https://github.com/trusteddomainproject/OpenDMARC Can you feel the pillars of our creation crumbling, Joe? Can you feel how it all ceases to matter? Can you feel the floor you are standing on vanishing beneath your feet? Can you feel how you are slowly sucked into the void? Can you feel how we will all suffocate? Anyways, maybe, if you're interested, we could also build our own mail authentication daemon. I have a local thing that uses https://github.com/stalwartlabs/mail-auth. It's not very complicated. I think Rust is a good pick for this, as much as I like Erlang and Python. It needs to be fast. C scares me a bit. What do you think?

Copilot

Pull Request Overview

This PR replaces the deprecated opendkim milter with a new dkim-milter role for managing DKIM key generation and service configuration. Key changes include:

Addition of variables and configuration files for dkim-milter.
Implementation of tasks to install dependencies, generate keys, and set up service templates.
Updates to handlers and playbook to integrate the new dkim-milter role.

Reviewed Changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 1 comment.

File	Description
ansible/roles/dkim-milter/vars/main.yml	Introduces configuration variables for domains, signings, and selector.
ansible/roles/dkim-milter/tasks/main.yml	Implements tasks to install packages, create users/directories, generate keys, and configure services.
ansible/roles/dkim-milter/handlers/main.yml	Defines handlers for service reload/restart of dkim-milter.
ansible/playbook.yml	Updates playbook to replace opendkim with dkim-milter.

Files not reviewed (2)

ansible/roles/dkim-milter/templates/dkim-milter.conf.j2: Language not supported
ansible/roles/dkim-milter/templates/dkim-milter.service.j2: Language not supported

Copilot · 2025-04-27T00:16:54Z

ansible/roles/dkim-milter/tasks/main.yml

+  with_items:
+    - "{{ dkim_milter_domains }}"
+  args:
+    creates: /etc/dkimkeys/{{ item }}/{{ dkim_milter_selector }}.pem


The 'creates' path appears inconsistent with the key generation location in the command (which is /etc/dkim-milter/keys). Consider updating the path to match the expected directory.

Suggested change

creates: /etc/dkimkeys/{{ item }}/{{ dkim_milter_selector }}.pem

creates: /etc/dkim-milter/keys/{{ item }}/{{ dkim_milter_selector }}.pem

Unfortunately, I think it's right.

Yes, in its screenful of absolutely pointless fluff, it manages to produce something of value. This is roughly similar to talking to a Microsoft representative.

The existing `opendkim` milter is no longer maintained. This commit introduces a role which deploys `dkim-milter`. As-is, it is not a complete replacement, since the role does not (yet) migrate keys of the old `opendkim` setup.

Copilot

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Copilot · 2025-09-27T20:43:02Z

ansible/roles/dkim-milter/templates/dkim-milter.service.j2

+ExecReload=/bin/kill -HUP $MAINPID
+Restart=on-failure
+
+# schizophrenia


The comment 'schizophrenia' is inappropriate and unprofessional. Consider removing it or replacing it with a clear explanation of why system protection is being configured.

Suggested change

# schizophrenia

# Restrict access to the system for security

Copilot · 2025-09-27T20:43:02Z

ansible/roles/dkim-milter/tasks/main.yml

+      {{ keyname }} < /etc/dkim-milter/keys/{{ keyname }}.pem
+      {% endfor %}
+      {% for item in dkim_milter_extra_signings %}
+      {% set keyname = (item['domain'] | replace(".", "_")) %}
+      {{ keyname }} < /etc/dkim-milter/keys/{{ keyname }}.pem


The key file path references {{ keyname }}.pem but the key generation task creates files in subdirectories like /etc/dkim-milter/keys/{{ item }}/{{ dkim_milter_selector }}.private. The path structure is inconsistent and will cause the milter to fail finding the keys.

Suggested change

{{ keyname }} < /etc/dkim-milter/keys/{{ keyname }}.pem

{% endfor %}

{% for item in dkim_milter_extra_signings %}

{% set keyname = (item['domain'] | replace(".", "_")) %}

{{ keyname }} < /etc/dkim-milter/keys/{{ keyname }}.pem

{{ keyname }} < /etc/dkim-milter/keys/{{ keyname }}/{{ dkim_milter_selector }}.private

{% endfor %}

{% for item in dkim_milter_extra_signings %}

{% set keyname = (item['domain'] | replace(".", "_")) %}

{{ keyname }} < /etc/dkim-milter/keys/{{ keyname }}/{{ dkim_milter_selector }}.private

Copilot · 2025-09-27T20:43:03Z

ansible/roles/dkim-milter/tasks/main.yml

+    group: root
+    mode: 0o755
+  vars:
+    dkim_milter_version: 0.2.0-alpha.1


Using an alpha version in production deployment could lead to instability issues. If Rust was used for this milter implementation, you'd benefit from memory safety guarantees and better error handling that could make alpha versions more reliable. Consider evaluating the stability of this alpha release or pinning to a stable version when available.

github-project-automation bot added this to Infrastructure Apr 20, 2025

github-project-automation bot moved this to Up next in Infrastructure Apr 20, 2025

github-actions bot added the group: ansible Issues and pull requests related to the Ansible setup label Apr 20, 2025

jb3 requested a review from Copilot April 27, 2025 00:16

Copilot AI reviewed Apr 27, 2025

View reviewed changes

Set up new dkim milter

fed57b4

The existing `opendkim` milter is no longer maintained. This commit introduces a role which deploys `dkim-milter`. As-is, it is not a complete replacement, since the role does not (yet) migrate keys of the old `opendkim` setup.

jchristgit force-pushed the new-dkim-milter branch from 6098411 to fed57b4 Compare April 27, 2025 08:22

jb3 force-pushed the main branch from a82dd18 to 97933ee Compare September 10, 2025 21:21

ChrisLovering force-pushed the main branch 2 times, most recently from 6c2d3f4 to 637c5d0 Compare September 10, 2025 21:27

jb3 force-pushed the main branch from 637c5d0 to 97933ee Compare September 10, 2025 21:27

ChrisLovering force-pushed the main branch from 97933ee to 015fe9a Compare September 10, 2025 21:28

jb3 requested a review from Copilot September 27, 2025 20:42

Copilot AI reviewed Sep 27, 2025

View reviewed changes

	creates: /etc/dkimkeys/{{ item }}/{{ dkim_milter_selector }}.pem
	creates: /etc/dkim-milter/keys/{{ item }}/{{ dkim_milter_selector }}.pem

Uh oh!

Set up new dkim milter #582

Are you sure you want to change the base?

Set up new dkim milter #582

Uh oh!

Conversation

jchristgit commented Apr 20, 2025

Uh oh!

github-actions bot commented Apr 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

OctoDNS Plan for new-dkim-milter

pythondiscord.com.

cloudflare

pythondiscord.org.

cloudflare

pydis.wtf.

cloudflare

Uh oh!

jb3 commented Apr 20, 2025

Uh oh!

jchristgit commented Apr 20, 2025 via email

Uh oh!

jb3 commented Apr 20, 2025 via email

Uh oh!

jchristgit commented Apr 21, 2025 via email

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Apr 27, 2025

Choose a reason for hiding this comment

Uh oh!

jb3 Apr 27, 2025

Choose a reason for hiding this comment

Uh oh!

jchristgit Apr 27, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Copilot AI Sep 27, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 27, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 27, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions bot commented Apr 20, 2025 •

edited

Loading

OctoDNS Plan for `new-dkim-milter`