Security

We do all we can to keep PhoenixDKIM secure. As an Internet-facing daemon that processes mail directly from external networks, security is a primary concern for this project. Even so, it is possible that you may spot a weakness we have missed. If you do, please let us know so we can address it quickly.

Reporting security problems is known as vulnerability disclosure (also known as coordinated vulnerability disclosure and responsible disclosure).

This is not an invitation to scan and test our infrastructure for weaknesses — we are doing that ourselves. We are interested specifically in weaknesses in the PhoenixDKIM source code and the libraries it depends on.

How we test PhoenixDKIM

PhoenixDKIM parses untrusted input from two directions on every message it handles: the DKIM-Signature header field, every byte of which is supplied by whoever sent the mail, and the public-key record retrieved from DNS, which is controlled by whoever operates the signing domain. We treat both as hostile and test accordingly. We publish what we do because a documented process is something you can verify — and because hiding a test list protects no one: it removes the chance for outside review without removing any attacker's ability to probe the code.

• Conformance and correctness. An automated suite of around two hundred tests, run on every change, exercises signing and verification against the RFC 6376 test vectors and a large body of hand-written conformance cases covering canonicalization, header selection, key formats, and algorithm handling.
• Memory safety. The code is built and the full test suite run under AddressSanitizer, UndefinedBehaviorSanitizer, and LeakSanitizer, and separately under Valgrind. A dedicated strict build compiles with aggressive warnings treated as errors, compiler hardening flags, and reproducible-build settings.
• Coverage-guided fuzzing. The signature and key-record tag-list parsers — the code most exposed to malicious input — are fuzzed with libFuzzer while instrumented with AddressSanitizer and UndefinedBehaviorSanitizer, so malformed, truncated, and adversarial inputs are explored automatically rather than only by hand.
• DNS failure handling. A dedicated test matrix confirms that every category of DNS failure is classified with the correct permanence: a missing key is treated as a permanent failure, while a timeout, server failure, or truncated reply is treated as transient and retried, so a momentary DNS problem can never be mistaken for a forged or absent signature.
• Independent cross-checks. Signatures produced by PhoenixDKIM are verified by an entirely separate DKIM implementation, so formatting or canonicalization divergences are caught by a second pair of eyes that shares none of our code.
• Defensive parsing. PhoenixDKIM enforces RFC 5322's single-occurrence rule for headers such as From and Subject, refusing to sign messages that carry duplicates — a known vector for display-name and double-header spoofing.

None of this makes any guarantee that PhoenixDKIM is free of defects, and we do not claim it is. It reflects the effort we put into finding problems before you do — and it is exactly why we welcome reports of anything we have missed.

How to report a problem

• Please e-mail details to security@phoenixdkim.org;
• Preferably encrypt your e-mail with our PGP key (fingerprint: 1061 6604 19FB D005 F207  E1E2 7435 EE87 9EFD 92D7);
• Include as much information as possible — a description of what you found, the version of PhoenixDKIM affected, steps to reproduce, and any relevant logs or proof-of-concept code. This helps us reproduce the problem and fix it;
• Please include your contact details (e-mail address or other means) so that we can follow up if we need more information.

Other important points

• Please do not disclose the vulnerability publicly until we have had a reasonable opportunity to investigate and release a fix.
• Do not go deeper into the affected system than is necessary to demonstrate the problem.
• Do not exploit a vulnerability beyond what is needed to verify it exists.
• Please delete any sensitive data you have inadvertently accessed in the course of your research.

What you do not need to report

• Social engineering.
• Resource exhaustion / (Distributed) Denial of Service.
• Physical access testing.
• Situations that cannot be reproduced, or exploits not validated by a second tool or method.
• Cosmetic issues in the PhoenixDKIM web pages.
• Situations where the problem lies at the user-awareness level (e.g. unattended workstations).
• Simple fingerprinting or version listings on OS, services, or ports.
• Publicly available files that contain only public information.
• Secure/HTTP-only flag missing on cookies that contain only public information.
• TLS misconfiguration without a proof of concept demonstrating exploitability.
• Services running at third-party providers — check their own responsible disclosure statement first.
• E-mail addresses found in a third-party data breach.
• Publicly disclosed vulnerabilities patched within the last two weeks.
• URL redirection to a valid web page.
• Missing security headers, options, and flags without a proof of concept showing real-world impact.
• Outdated dependency versions without a working proof of concept.

Known issues

Some issues are already known to us and are being worked on, or have been assessed and accepted as risks. Duplicate reports of these will not result in any action. Our security contact is aware of them.

What we will do

• We will e-mail you within one working day, confirming receipt of your report.
• Within five working days, we will respond with our assessment of the issue and tell you when we expect it to be resolved. We aim to fix confirmed vulnerabilities as promptly as possible, and certainly within three months.
• We will keep you updated on progress.
• With your agreement, we will credit you as the discoverer of the problem in our release notes or security advisories — but only if you want us to.

security.txt

RFC 9116 defines a straightforward mechanism for organisations to publish their vulnerability disclosure policy and contact details in a machine-readable format. We follow this internet standard. Our security.txt file is available at https://www.phoenixdkim.org/.well-known/security.txt.