Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mail::dkim reports valid even if h= tag missing message-id signed #35

Open
xpunkt opened this issue Nov 7, 2024 · 2 comments
Open

mail::dkim reports valid even if h= tag missing message-id signed #35

xpunkt opened this issue Nov 7, 2024 · 2 comments

Comments

@xpunkt
Copy link

xpunkt commented Nov 7, 2024

its simply a missing rfc compliance for minimal signed headers, hope this will be tested in dkim so all the paypal phish from onmicrosft can be rejected :)

@mnalis
Copy link

mnalis commented Nov 10, 2024

Can you clarify what you mean by "minimal signed headers"?

STD 76 AKA RFC 6736 - DomainKeys Identified Mail (DKIM) Signatures in section "5.4.1. Recommended Signature Content" says (among other things):

There are trade-offs in the decision of what constitutes the "core"
of the message, which for some fields is a subjective concept.
Including fields such as "Message-ID", for example, is useful if
one considers a mechanism for being able to distinguish separate
instances of the same message to be core content

But does not seem to indicate that signing Message-ID is required; to the contrary?

@marcbradshaw
Copy link
Member

Section 3.5 states that...

h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields do
not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MAY contain multiple instances of a header
field name, meaning multiple occurrences of the corresponding
header field are included in the header hash. The field MUST NOT
include the DKIM-Signature header field that is being created or
verified but may include others. Folding whitespace (FWS) MAY be
included on either side of the colon separator. Header field
names MUST be compared against actual header field names in a
case-insensitive manner. This list MUST NOT be empty. See
Section 5.4 for a discussion of choosing header fields to sign and
Section 5.4.2 for requirements when signing multiple instances of
a single field.

It does not state that any particular header must be included in the minimal set, that is a choice by the sender. While there could be an argument for requiring that given headers be DKIM signed that would be a local policy, and not something that is a part of Mail::DKIM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants