Answers.Body: <p>Not yet!</p>
  
  <p>This could potentially be done from an extension in a hook like <a href="https://docs.civicrm.org/dev/en/master/hooks/hook_civicrm_alterMailParams/" rel="nofollow noreferrer"><code>hook_civicrm_alterMailParams()</code></a>, alongside a scheduled task to fetch GPG keys from keyservers (to avoid slowing down delivery with HKP lookups).</p>
  
  <p>Another approach might be to handle this at MTA level with something like <a href="https://github.com/infertux/zeyple" rel="nofollow noreferrer">Zeyple</a> (a PGP filter for Postfix).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-24T18:27:02.913Z
Answers.Text: Think carefully about what it means to have GPG automated - there's a layer of trust with GPG that comes from the expectation that the sender was present to enter their GPG key on sending, for example ... Automating GPG encryption would sidestep this, but might still be beneficial in providing a layer of encryption to protect message content in transit.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-24T23:43:05.667Z
Answers.Text: That would be the point - to protect messages in transit, and in Inboxes that can be hacked. I don't understand about trust. If someone puts their public key on a key server, doesn't that imply that they are willing to accept encrypted incoming mail ?
Answers.UserDisplayName: InterestedGuy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-25T10:13:58.850Z
Answers.Text: I mean that typically if you receive an encrypted email, you can trust that the sender was present to sign it on sending. But with a CRM plugin, presumably the CRM can sign the messages "unattended". What we can trust about the sender is reduced from "was present to sign key at send" to "had access to CRM at some point".
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-24T18:26:24.060Z
Answers.LastActivityDate: 2017-03-24T18:26:24.060Z
Answers.UserDisplayName: Chris Burgess
Body: <p>There are many stories of leaked e-mails making news, and we know that repressive governments read emails to suppress dissent. </p>
  
  <p>It would probably be possible to have CiviMail check a public PGP server for each outgoing email address, and if it found a public key, use it to encrypt the outgoing message by default. Perhaps there could be also be a user-requested preference to NOT encrypt as an exception. </p>
  
  <p>Is this on the wish list ? </p>
  
Tags: <civimail>
Title: Does CiviMail support PGP encryption ?
ThreadText: # Does CiviMail support PGP encryption ?
  
  (Asked by: username_0 on 2017-03-24)
  
  There are many stories of leaked e-mails making news, and we know that repressive governments read emails to suppress dissent.
  
  It would probably be possible to have CiviMail check a public PGP server for each outgoing email address, and if it found a public key, use it to encrypt the outgoing message by default. Perhaps there could be also be a user-requested preference to NOT encrypt as an exception.
  
  Is this on the wish list ?
  
  **Tags:** civimail
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-03-24. Score: 1
  
  Not yet!
  
  This could potentially be done from an extension in a hook like [`hook_civicrm_alterMailParams()`](https://docs.civicrm.org/dev/en/master/hooks/hook_civicrm_alterMailParams/), alongside a scheduled task to fetch GPG keys from keyservers (to avoid slowing down delivery with HKP lookups).
  
  Another approach might be to handle this at MTA level with something like [Zeyple](https://github.com/infertux/zeyple) (a PGP filter for Postfix).
  
  > **Comments:**
  > **username_1**: Think carefully about what it means to have GPG automated - there's a layer of trust with GPG that comes from the expectation that the sender was present to enter their GPG key on sending, for example ... Automating GPG encryption would sidestep this, but might still be beneficial in providing a layer of encryption to protect message content in transit.  
  > **username_0**: That would be the point - to protect messages in transit, and in Inboxes that can be hacked. I don't understand about trust. If someone puts their public key on a key server, doesn't that imply that they are willing to accept encrypted incoming mail ?  
  > **username_1**: I mean that typically if you receive an encrypted email, you can trust that the sender was present to sign it on sending. But with a CRM plugin, presumably the CRM can sign the messages "unattended". What we can trust about the sender is reduced from "was present to sign key at send" to "had access to CRM at some point".  
  
  ---
  
  