The pgp.net email keyserver: commands and help files

Updated November 2026

In the 1990s you could publish or fetch a PGP key by sending an email to pgp-public-keys@keys.pgp.net with a command in the Subject line. That service no longer exists, and nothing processes mail sent to those addresses. This page explains how it worked and what each command did. It also gives the modern way to do the same job, and links the original help texts in 15 languages.

How it worked

The email keyserver was a robot that read incoming mail. You wrote the command in the Subject: line, not in the message body. The only command that used the body was ADD, where the body held your ASCII-armored public key block. The server mailed its answer back to the address in your From: line, so you had to wait for the reply to arrive. The pgp.net pages themselves called the email system "non-realtime".

A request to add a key looked like this:

To: pgp-public-keys@keys.pgp.net
From: alice@example.edu
Subject: ADD

-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----

The name keys.pgp.net was a set of equal-priority MX records in the DNS, one for each participating server. The pgp.net name servers rotated the order of that list on every lookup. So each message went to a more or less random server, and if one server was down the sending mail system simply tried the next one. Country names such as keys.de.pgp.net or keys.uk.pgp.net sent mail only to servers in that country. Those national servers could also answer in the local language.

The servers kept each other up to date by passing on every ADD request. That is why the help text told users that sending a key to one server was enough. A page from February 1998 lists national email domains for Austria, Australia, Croatia, the Czech Republic, Finland, Germany, Hungary, Korea, the Netherlands, Norway, Poland, Spain, Sweden, Taiwan, the UK and the US.

The service never vouched for a key. Anyone could upload a key with any name on it. Users had to check signatures and fingerprints themselves, and that is still true of keyservers today.

The commands

MGET took a real regular expression, not a shell wildcard. So MGET .* matched every key on the server, which is why the help text warned against it. Some servers also capped how many keys an MGET or LAST reply could hold.

The commands without an argument were the dangerous ones. The English help text of March 1997 gave the sizes as of February 28, 1997:

• 4 MBone INDEX reply
• 8 MBone VERBOSE INDEX reply
• 55,000+keys in the full ring
• 99 mailsto deliver the 18 MB ring with GET

Many mail systems of the time could not accept messages that large. Anyone who really needed the whole ring was sent to the FTP copy instead. That copy is still in the archive at /pub/pgp/keys/ as a 1997 snapshot (pubring.pgp, about 28 MB). It is only useful for history. Do not import it into a working keyring.

Why it disappeared

The archived pgp.net pages already pointed to the problems. Email lookups were slow and could not be automated well. The single replicated key ring kept growing, and PGP 2.x became very slow on large rings. A 1995 proposal in the archive, rem.html, says the replicated ring was "creaking" and that a distributed service was the way forward. Lookups moved to the web: first to the WWW interface, then to the HTTP Keyserver Protocol (HKP) on port 11371. The keyserver history page follows the story from there to today's servers.

What to use instead

For most people, keys.openpgp.org does the job of the old ADD and GET commands. It only lists an email address after the owner confirms it. To fetch a key when you already know its fingerprint:

gpg --keyserver hkps://keys.openpgp.org --recv-keys 0123456789ABCDEF0123456789ABCDEF01234567

Replace the example with the real 40-character fingerprint. To find a key by email address, set the keyserver once in ~/.gnupg/dirmngr.conf:

keyserver hkps://keys.openpgp.org

Then look the address up:

gpg --auto-key-locate keyserver --locate-keys user@example.net

To publish your own key (the old ADD), export it and upload it. keys.openpgp.org prints a link that starts the email confirmation:

gpg --export your_address@example.net | curl -T - https://keys.openpgp.org

If --recv-keys reports no user ID, the owner has not confirmed any address on keys.openpgp.org. GnuPG then skips the key. In that case, ask the owner for the key directly or try their Web Key Directory:

gpg --locate-external-keys user@example.org

A Web Key Directory serves keys from the mail domain's own web server. For older commands that name subkeys.pgp.net or wwwkeys.pgp.net, see Replacing subkeys.pgp.net. For the web lookup interface that replaced email, see HKP protocol.

The original help files

The translated help texts are kept unchanged in the archive. They are plain text from 1996 to 1998, so their addresses, URLs and FTP paths no longer work. The Korean file uses the EUC-KR character set and the Chinese file uses Big5. If they look garbled, change the text encoding in your browser or editor. Related period documents:

• email-key-server-info.html: how keys.pgp.net and the national domains were set up
• email-announce: the announcement of keys.pgp.net
• email-charter.html: the rules for servers that wanted to join (1996)
• email-list: the older list of independent email servers (1994)

Each section below says, in that language, what the help file explained, that the service has ended, and what to use now.

Sources

• PGP Public Email Keyservers, English help text (March 1997), pgp.net archive
• keys.pgp.net: the email based key server system (1998), pgp.net archive
• Announcement: keys.pgp.net, pgp.net archive
• keys.pgp.net charter (February 1996), pgp.net archive
• A proposed multi-protocol PGP key lookup client, pgp.net archive
• Usage: GnuPG, keys.openpgp.org
• Usage, keys.openpgp.org
• The OpenPGP HTTP Keyserver Protocol (HKP), draft-shaw-openpgp-hkp-00, IETF (March 2003)
• WKD, GnuPG wiki