gnupg/dirmngr does not surface 429 and other unexpected error code responses from keyserver
Which of our tools is giving you problems?
gnupg/dirmngr/gpg keychain
Attach a screenshot of the version info for all installed components (how to: https://gpgtools.tenderapp.com/kb/faq/where-can-i-find-version-info...):
Nightly 3604n
Describe your problem. Add as much detail as possible.
I recently got blocked/rate limited by a keyserver that began returning "Error code: 429 Too Many Requests" to all my requests. I didn't realize this for some time though because keyserver commands sent via gpg CLI and GPG Keychain were responding "No keys found" and not surfacing the error to let me know the query had been blocked. I have confirmed the same behavior for other error codes as well, such as internal server errors in the 5xx range.
What did you expect instead
I would expect the error code would be surfaced so the user is aware the command failed and not believe it successfully queried a keyserver and found no keys for the query. Likely it would be easiest to look for the "expected" errors codes like 200 (and maybe 301/302 redirects if gpg can follow those?) and 404 for not found and surface others as errors vs. having to keep up with the full (and possibly changing) list of all "error" codes
Describe steps leading to the problem.
Get blocked/rate limited by a keyserver to the point it responds with Error code: 429 Too Many Requests for all queries & then attempt to perform a keyserver action such as --search or --recv-keys
Are you using any other Mail.app plugins?
n/a
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by gpg_dude on 23 Jul, 2026 07:39 PM
Hi guys - I just wanted to check if you had any thoughts on this one. I haven't seen it in a while but just re-tested with the latest nightly and the issue still persists. Than
2 Posted by gpg_dude on 24 Aug, 2026 03:05 PM
Bumping this issue as I ran into it again today
Support Staff 3 Posted by Luke Le on 03 Sep, 2026 07:25 PM
Hi!
thanks for your patience. I've had another look into this issue and the main problem at the moment is, that GnuPG itself doesn't surface that info. While of course we could patch that into it, I'm yet not entirely sure what the best approach would be without introducing side-effects or breaking other stuff.
4 Posted by gpg_dude on 03 Sep, 2026 08:05 PM
I would think it would be in their (and really everyone's) best interest to surface errors accurately. In the event the request doesn't yield the the expected result (e.g. key details in --search-keys, key data in --recv-keys, confirmation of key acceptance in --send-key, etc) throwing a unique error would seem to be a better behavior/experience than falsely claiming no data was found (at least in the case of --search-keys). I can't conceive of any side-effects or (additional) breakage and IMO it's already broken in its current state, but I get wanting to be sure. I can socialize the idea the GnuPG team if that's helpful. If that's where the behavior is rooted I do think it would be best to have it fixed upstream there so it would find it's way to all platforms that are using it.
Support Staff 5 Posted by Luke Le on 03 Sep, 2026 08:30 PM
I absolutely agree and don't understand why this hasn't been reported or addressed in the past. It would certainly be best to bring it up with the GnuPG team itself, since we try to stick as close as possible to upstream.
6 Posted by gpg_dude on 04 Sep, 2026 07:56 PM
I'll see what I can manage. Apparently they've made their bug tracker to thwart AI scrapers so you have to use the mailing list now :(