Open agowa opened 9 months ago
Thanks for the suggestion, I will consider adding such a button in one of the next releases.
I do not know if it is currently possible to get a valid signature from the $sender domain AND an explicitly specified SDID
It is already possible to specify multiple allowed SDIDs in a sign rule by separating them with a space. See also https://github.com/lieser/dkim_verifier/wiki/Sign-rules#sdid.
So it should be already possible to add the kind of rule you want, just not with a convenient button in the header.
Hi, I'd like to have an additional option in the dropdown list of the "DKIM" button to acknowledge (and thereby hide in the future) the "Wrong signer (should be from-domain)" warning on a per sender and alternative-sender basis.
This happens for e.g. zendesk all the time. I haven't looke into it more closely if this is because zendesk is just signing as "zendesk.com" instead of the custom from domain of the tenant, or if the tenant failed to properly configure DKIM for zendesk (mostly because I'm not a zendesk customer myself, so I do not have access to the necessary administrative setting menus and resources). However this appears to be a common issue for at least 2 different companies that I've interacted with so far.
The option could be named e.g.
Trust signer ($signerDomain) for this sender ($senderMailAddress)
. Currently the dropdown only hasAdd must be signed exception
which is not exactly what I'm looking for, as this will disable the validation entirely and not just whitelist a specific signer for this specific sender.Tl;Dr
Currently when pressing
Add must be signed exception
(which is the only option without manually creating a rule) creates this signers rule:My suggested
Trust signer ($signerDomain) for this sender ($senderMailAddress)
option would instead harden this to in addition to the $senderDomain also show a valid signature from "zendesk.com" as valid for this specific From address. If I understand the rules correctly the only difference would be adding the SDID (and maybe also add an additional ruletype).Workaround
I do not know if it is currently possible to get a valid signature from the $sender domain AND an explicitly specified SDID from within a signers rule to be considered valid. However in order to only cause the alternate signer to be considered trusted a rule like this is enough. If this in fact does not cause a valid signature from the senderDomain to become invalid or not checked anymore it may be exactly what my suggested new option should add: