In order to send out s/mime encrypted emails (from any system, this is not unique to PRPC) - you will need one Certificate for every recipient you wish to send a message to.

The Certificate has to be provided by the recipient ; and the recipient keeps hold of the corresponding Private Key (which is needed to *decrypt* any incoming emails).

So in PRPC; you will need to load a PRPC keystore with all the Certificates from all the recipients you wish to send encrypted emails to the decision table.

The main thing to note here: It is the Recipient *owns* the Private Key, and provides the Sender with a Public Certificate. Just to emphasize this:

You as the sender are *unable* to decrypt a message you encrypted; *only* the receiver (the owner of the corresponding private key) can do this. 

In your brief description of a 'pool' of users (which changes over time); you will need to get each of these users to generate / provide their Certificates to you; rather than you providing the Certificates.

If you (as the Sender) want to control the Certificates and hand out the Private key to multiple users - defeats the purpose of encrypting the emails in the first place. (I would say).

Note: don't confuse email encryption (which encrypts the *contents* of the email) with end-to-end encryption (which encrypts the message *in-transit*).

If your goal is to keep the emails secret from anybody sniffing the network - then just make sure you are using a secure protocol (SMTP over SSL) to do this.

If your goal is to keep the email secret with the user on the other side; then handing out a single Private Key to a big group of changing user population isn't going to work. (You lose control over the Private key for one - so if a user leaves the pool - you have no way of revoking this key for instance).

I hope this helps?