Closed rvd0167 closed 3 months ago
could you provide me the domain in question? or at the very least the DKIM TXT entry name and value of that domain?
Sorry. Should have seen this question coming. Screenshot mailhardener.com
the reason this fails is because the selector name is mail
and not default
.
it is completely valid to do so its just I cant guess the correct selector name.
because it only checks for default
is will fail as that record is not there.
please leave this issue open for me to find a solution for this.
Will do.
You can get it from the latest incoming report and check that one? If the selector changes, it will fail. Then just wait for a report with the new selector....
no need, I can check this with one of my own domains.
Probably, but there are also selectors with cryptic names. And they change eg once a year. Have some clients that have this setup. They can not be guessed I'm afraid.
thats interesting is that a scripted or manual process?
Scripted. Just like ours (comprax.nl). Old selectors and keys remain in DNS (for a few years) and a new one is created once a year or every 2 years. eg. I use at the moment gyeehs2022
For the short term I think a configurable option in the web interface seems like a good option.
for the long term I could add an api to the mix. That way you could just do a post request with the new selector in your script. But since that requires a architectural change it won’t been soon
In my opinion it is much easier to just get it from the database. After a single report all the info is there.
I don't think people like updating the info by hand or API. The API must be build into the sofware managing the DNS and mailserver. By hand is easily forgotten.
I disagree, Yes i can get it from a report but whats to say that the selector in there is the only one? DKIM keys can be set per sender so a domain can contain multiple valid keys. should i just blindly update it every time a report comes in? what if a user wants to check against a specific selector?
i agree that by hand its easily forgotten so this is just a first step in the right direction. using an REST API is pretty much industry standard for managing data across systems.
But there should only be a single selector using the right domain. Mailservers do normally not double sign the same message. It is irrelevant if a middleman server also signs the message. It is not part of Viesti-reports domains requested to test.
It's already a problem if reports come in about the wrong DKIM. But that (DKIM tested agains domains not in Viesti users domain list) is also something that is not checked in Viesti reports. (for as far as I can see)
Definitely not true. the standard is designed so that multiple services, servers and entities can all make use of the same domain using their own keys.
Viesti reports currently does no checking it just displays the reports instead of having to read the raw file manually
Unknown domains are automatically added by the way. Just not assigned to a user.
In that case Viesti reports should probably (cumulatively) save all seen selectors ending with the reported domain. Verify all and mark the selectors ok or failed. And perhaps let the user delete selectors from the list? It's getting pretty messy. Not just a "Hey my DKIM should not fail" anymore. Sorry ;-)
Since the check page has just recently been created, it should do more than just fail or ok it. if you wish to contribute you are very welcome.
improved implementation a bit in v1.20.0 further improvements will be put on the long term roadmap
When checking a domain with a valid DKIM it always shows "DKIM Failure" Checking DKIM with any online tool reports no errors.