Throughout the documentation we refer to the systems which will send email to Mailmin as 'client' systems, and to the system on which Mailmin runs as the 'Mailmin' or 'remote' system.
Mailmin normally uses at least two pairs of public / private keys. One is the Mailmin keypair; the private key is on the Mailmin system, in the keyring of the user who will be using Mailmin, and the public key is accesible to all client systems. The other is the authorized user (or restricted user) keypair; the private key is on the client system and the public key is accesible to Mailmin. There can be only one Mailmin key (per Mailmin invocation), while there can be multiple authorized (and / or restricted) keypairs, which might be useful if there are several client systems or authorized / restricted users.
If anonymous access is enabled, Mailmin can operate without any PGP keys, but see below.
On the Mailmin system, create a new keypair with the command gpg --gen-key. The defaults are mostly fine, but when asked for a passphrase hit enter without typing one; protecting the private key with a passphrase will prevent Mailmin from using the key. [You can use a passphrase if you use gpg-agent, but then Mailmin won't run until you load its key into the agent, which could be a problem if the system is rebooted and you have no other access.] The public key must then be made available to all client systems. The exact method of doing this depends on the clients' OpenPGP implementations, but in general the public key should be exported with the command gpg --export [-a | --armor] [-o | --output filename] keyid (where keyid is the key id of the key you just created), transported by any convenient method to the client systems and then imported into the clients' keyrings. Alternatively, you can send the public key to a keyserver with the command gpg --send-keys keyid. Consult the gpg documentation for more information about the gpg command, and the documentation of your clients' OpenPGP implentations for details on key import.
Technically, if Mailmin will not be signing outgoing mail, i.e. if only unsigned incoming mail is expected, then a Mailmin keypair is not required. If signed mail is received and a Mailmin keypair has not been defined, Mailmin will abort.
On each client system, create a new keypair and then export its public key; consult the appropriate documentation for details. Transfer the key to the Mailmin system by any convenient method, and then import it into your keyring with the command gpg --import keyfile (where keyfile is the file containing the key). The transfer can also be done via keyserver, as above. Mark the key as trusted with the command gpg --edit-key keyid (where keyid is the key id of the imported key), followed by the command (at the Command> prompt) trust, and then selecting menu option 5, ultimate trust.
Restricted user keypairs are created and used exactly like authorized user keypairs. The difference is in the access granted; a message signed by an authorized key has access to full Mailmin functionality ('normal mode'), while one signed by a restricted key is only granted access to a severely limited subset of that functionality ('restricted mode'). See here for a detailed explanation of restricted mode.
Edit the Mailmin configuration file (see the usage page for its location). Add the line mailmin_key = keyid (where keyid is the key id of the Mailmin keypair). For any authorized and restricted keypairs that you created, add the line authorized_key = keyid or restricted_key = keyid respectively (where keyid is the key id of the respective key).