How exactly does "Reject DKIM failures" work?
In Exim Configuration Manager > Basic Editor > ACL Options I enabled:
☑️ Allow DKIM verification for incoming messages
☑️ Reject DKIM failures
But today yet another piece of spam landed in my inbox and it does not even have a DKIM signature in the headers.
The documentation does not state that SpamAssassin is required for these settings to work, so how do they actually work?
If it only blocks emails that contain an invalid DKIM signature, then they're useless because all a spammer has to do is simply not DKIM sign their spam, which they're already not doing.
So, is it ignoring emails that do not contain DKIM sig?
-
Hey there! I configured two WHM servers to test this. One server had an account with no DKIM record in place, and the second server was just used as the recipient, with both "Allow DKIM verification for incoming messages" and "Reject DKIM failures" enabled.
When I sent a test message to the recipient server, I encountered this in the Exim log file at /var/log/exim_mainlog:
2023-12-04 20:44:05 1rAKT8-0054fB-0N ** email@recipientdomain.com R=dkim_lookuphost T=dkim_remote_smtp H=recipientdomain.com [1.2.3.4] X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no: SMTP error from remote mail server after end of data: 550-DKIM: encountered the following problem validating senderdomain.com:\n550 pubkey_unavailable
That would seem to indicate it blocks it entirely, even when the DKIM isn't present.
If you aren't seeing this happening on your instance, could we convert this to a ticket so we can do some more investigation?
0 -
My experience is the exact opposite.
When I enabled both settings in WHM then attempted a test from my Gmail account (to be sure it's not a localhost issue), the Gmail account received the same rejection that you saw:
550 DKIM: encountered the following problem validating gmail.com: pubkey_unavailable
But the difference is that Gmail's DKIM signature existed and presumably was 100% valid.
Why is WHM looking for a pubkey_ DKIM signature?
That seems to be the root of the problem.
If my only option is to open a ticket, I'll have to do that through Hostek. I was hoping this was a known issue that would be easily resolved via the community, but apparently I'm the only one who's ever asked about it?
And there's no actual full documentation anywhere on how it's supposed to function? It's just surprising if we're only able to reverse engineer that via trial and error.
Would you mind trying to reproduce what I've reported with an equivalent attempt from Gmail to your test server with both settings enabled?
0 -
I actually did my initial testing with Gmail, as I knew that was an easy way to confirm the DKIM didn't exist on my test account, so in this case I think a ticket would be the best option.
0
Please sign in to leave a comment.
Comments
3 comments