OpenDKIM
OpenDKIM copied to clipboard
trusteddomainproject
"unprotected header field"
Hello,
e-mails are being rejected as follows:
Jul 4 11:27:52 [servername] opendkim[37482]: F2BCE7E971: o4.hv30n.shared.sendgrid.net [167.89.100.125] not internal
Jul 4 11:27:52 [servername] opendkim[37482]: F2BCE7E971: not authenticated
Jul 4 11:27:53 [servername] opendkim[37482]: F2BCE7E971: signature=2pq1mzDc domain=example.com selector=s1 result="unprotected header field"
Jul 4 11:27:53 [servername] postfix/cleanup[87943]: F2BCE7E971: milter-reject: END-OF-MESSAGE from o4.hv30n.shared.sendgrid.net[167.89.100.125]: 4.7.0 DKIM signature processing failed; from=<bounces+16072861-25fe-[recipient]=[servername]@em285.example.com> to=<[recipient]@[servername]> proto=ESMTP helo=<o4.hv30n.shared.sendgrid.net>
To avoid the upfront rejection, I modified opendkim.conf from
On-BadSignature reject
On-SignatureError reject
to
On-BadSignature tempfail
On-SignatureError tempfail
and restarted the moving parts. As a result, the emails are still being rejected with the above message type.
Searching for "unprotected header field" here in github, I could only find one line of code, namely a definition of "DKIM_SIGERROR_MBSFAILED" in libopendkim/dkim-tables.c.
I then looked into the specification (rfc6541, rfc6376, rfc5672, rfc5518, rfc4871, rfc4870) and could not find any reference to "unprotected header field" and "DKIM_SIGERROR_MBSFAILED".
According to libopendkim/dkim.h, DKIM_SIGERROR_MBSFAILED means "must be signed" failure, that is "a header on the "must be signed" list was present but not covered by this signature".
# MustBeSigned (dataset)
# Specifies a set of header fields that, if present, must be cov-
# ered by the DKIM signature when verifying a message. If a
# header field in this set is present in the message and is not
# signed, the filter will treat even an otherwise valid signature
# as invalid. The default is an empty list.
ADDED TO CLARIFY
This scenario is about my opendkim server (example.com) verifying some one else's e-mail.
My understanding of the issue is that my opendkim server rejected an e-mail because its DKIM signature did not cover a header that had to be signed according to the sender's DKIM policy.
What I need from my opendkim server is to add a dkim=tempfail in the Authentication header and deliver the e-mail. I do not want it to reject the e-mail. I want to see the e-mail to inspect it myself.
The behaviour reported here completely matches what the documentation says is supposed to be the behaviour of MustBeSigned. The reporter is confused.
The signer specifies in their h= tag which headers the verifier needs to check the signature of. MustBeSigned is clearly a configuration option intended for if you want to require senders to include specific headers in their h=. If senders do not include those headers in their h= then the filter will treat even an otherwise-valid signature as invalid.
@hdatma obviously your senders were choosing not to sign all the headers you were wanting them to. RFC 6376 is very clear that the only header that senders "MUST" sign is From. So, of course you faced interoperability problems by requiring additional non-standard behaviour from senders.
That said, I think there is potentially still a bug here: namely that "the default is an empty list". IMO, the default should be From since the RFC says, "If the 'h=' tag does not include the From header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL".
your senders were choosing not to sign all the headers you were wanting them to
Now this is confusing, as each sender is free to set their own policy, and thus sign their chosen headers, for the recipient to verify. When I send you an e-mail, I do it according to my local policy, not yours. If my policy says, for example, sign From: and Subject:, then my server signs those headers and puts the signature in the mail. When you receive it, your server verifies those signatures. When you say that "your senders were choosing not to sign all the headers I want them to" you are making two mistakes: first, I do not want them to sign anything, as it is not up to me to decide their policy, and second, opendkim does not offer any such feature.
I do not want them to sign anything, as it is not up to me to decide their policy....
Wrong. You were wanting senders to sign Subject, From, Date, To and Message-ID. You explicitly stated, "in my opendkim.conf I have: 'MustBeSigned Subject,From,Date,To,Message-ID'."
But as you now say, it is not up to you. So, of course interoperability broke when you configured that.
When you set MustBeSigned, you are imposing requirements on which headers you require the signers to sign. But as you now seem to realize, this is not supposed to be up to you. You're supposed to leave it to the signer's local policy. So that's why interoperability broke when you did it.
I do not want them to sign anything, as it is not up to me to decide their policy....
Wrong.
Please RESET your thinking about this issue.
My Original Post, the first one in this issue, is the post where I describe the problem.
My second post is an attempt to find the answer.
The second post is where you are focusing. Don't do that. Focus on the first post please.
Indeed, it seems I am misunderstanding what it is you think the problem is. Sorry if I have confused things. Perhaps you could clarify what you think OpenDKIM's correct behaviour should have been with your configuration.
Indeed, it seems I am misunderstanding what it is you think the problem is. Sorry if I have confused things. Perhaps you could clarify what you think OpenDKIM's correct behaviour should have been with your configuration.
I am sorry then. I edited the OP and deleted the second post.