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 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.