it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

Option #1 is good from a descriptional POV, but in most cases both the main key and the subkeys will be expired, so it would end up not updating any subkey.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

It may be preferable to get that under 4.0 or later, so you don't need to contact every contributor again if in some years there is intention to switch to a newer version released by Creative Commons.

Maybe have gpg-wks-client(or also --export-filter) print a warning if the filtered result has a key expiration different than the original key? That seems the simplest way tp approach the problem.

I would add "Provide a verbose message of why the key cannot be imported".

Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)