use "e-mail" everywhere for consistency

doc/cleanup.rst

@@ -15,5 +15,3 @@ documentation, we need to settle internally on "agent" or "client" or
 "MUA" or "MUAA"
 
 glossary for technical documentation.
-
-we should use "email" or "e-mail" consistently in these docs

doc/contents.rst

@@ -7,7 +7,7 @@ and contributors, MUA developers and privacy enthusiasts.
 
 :doc:`index`
      introduction to why Autocrypt exists and why it is trying 
-     to achieve more email encryption.
+     to achieve more e-mail encryption.
 
 :doc:`features`
      discusses how the Autocrypt efforts is different from past 

doc/examples.rst

@@ -76,11 +76,11 @@ Bob's key and the fact that Bob sent an encrypted mail.  Subsequently
 both Alice and Bob will have their MUAs encrypt mails to each other.
 
 If ``prefer-encrypted`` is sent as 'yes' the MUA MUST default to encrypting
-the next email. If it is set as 'no' the MUA MUST default to plaintext.
+the next e-mail. If it is set as 'no' the MUA MUST default to plaintext.
 If ``prefer-encrypted`` is not sent the MUA should stick to what it was doing
 before. If the attribute has never been sent it's up to the MUA to decide. The
 save way to go about it is to default to plaintext to make sure the recipient
-can read the email.
+can read the e-mail.
 
 We encourage MUA developers to propose heuristics for handling the undirected
 case. We will document the best approaches to develop a shared understanding.
@@ -136,7 +136,7 @@ your mail") Bob's MUA will see the new key and subsequently use it.
 
     Unless we can get perfect recoverability (also for device loss etc.) we will
     always have to consider this "fatal" case of losing a secret key and how
-    users can deal with it.  Especially in the federated email context We do
+    users can deal with it.  Especially in the federated e-mail context We do
     not think perfect recoverability is feasible.
 
 

doc/faq.rst

@@ -62,14 +62,14 @@ yet will drop these headers and fall back to the one without priority.
 Why do you use the ``to=`` attribute rather than the uid from the key?
 ----------------------------------------------------------------------
 
-We need to store state about the key to use for a given email
+We need to store state about the key to use for a given e-mail
 address. Just importing the key into a keyring won't cut it.
 
 We want to be able to handle the header without having to parse the
 key first.  We believe that using the 'to' attribute will be more
 forward compatible. For example we discussed hashing the uid in the
-keys so in case they leak to pgp keyservers they do not leak the email
-address. This would not be compatible with requiring the email address
+keys so in case they leak to pgp keyservers they do not leak the e-mail
+address. This would not be compatible with requiring the e-mail address
 as the uid.
 
 How does Autocrypt interact with message signing?
@@ -206,13 +206,13 @@ Possibilities for uid we considered:
  Option  SC BC VO RvK SR
  ======= == == == === ==
  no uid            x  x
- email   x  x   x  x
+ e-mail  x  x   x  x
  fixed         x   x  x
  hash    x      x   x x
  ======= == == == === ==
 
 SC: self-claim. This was very important to us for usability
-reasons. This restricted us to either use the email directly or
+reasons. This restricted us to either use the e-mail directly or
 hashed.
 
 BC: backwards compatibility
@@ -221,13 +221,13 @@ VO: valid OpenPGP
 
 RvK: allows revocations using keyservers
 
-SR: Spam resistant/publicly list email addresses
+SR: Spam resistant/publicly list e-mail addresses
 
-Using a salted hash of the email address for the uid to not list them
+Using a salted hash of the e-mail address for the uid to not list them
 on keyservers would prevent the privacy issue of public mail addresses
 but the key should not be uploaded in the first place.
 
-Accidental or malicious uploading of keys with associated email
+Accidental or malicious uploading of keys with associated e-mail
 addresses should be prevented by introducing a flag at the keys that
 says that keyservers shouldn't accept it.  See `issue #1
 <https://github.com/autocrypt/autocrypt/issues/1>`_.

doc/glossary.rst

@@ -3,7 +3,7 @@ Glossary
 
 MUA
         Mail User Agent.
-        Any program/client/app that handles emails for the end user.
+        Any program/client/app that handles e-mails for the end user.
 
 MUAA
         Mail User Agent Account.

doc/index.rst

@@ -1,22 +1,22 @@
-Introducing Autocrypt: Email Encryption for Everyone
-====================================================
+Introducing Autocrypt: E-Mail Encryption for Everyone
+=====================================================
 
-**If users ask how they can secure their email the answer
+**If users ask how they can secure their e-mail the answer
 should be as simple as: use an Autocrypt-enabled mail app!**
 
-**Why improve email?** Email has been declared dead many times but 
+**Why improve e-mail?** E-Mail has been declared dead many times but 
 refuses to die. It remains the largest open federated identity and
 messaging eco-system, anchors the web, mobiles and continues to relay
 sensitive information between citizens and organisations. It has
 problems but do you prefer the proprietary, easy-to-track mobile phone 
 number system to become the single source of digital identification?
 
-**Why a new approach to email encryption?**  Encrypted email has been
+**Why a new approach to e-mail encryption?**  Encrypted e-mail has been
 around for decades, but has failed to see wide adoption outside of
 specialist communities, in large part because of difficulties with user
 experience and certification models.  Autocrypt first aims to provide 
 convenient encryption that is neither perfect nor as secure as 
-traditional email encryption, but is convenient enough for
+traditional e-mail encryption, but is convenient enough for
 much wider adoption.  
 
 The social Autocrypt approach
@@ -25,7 +25,7 @@ The social Autocrypt approach
 The Autocrypt project is driven by a diverse group mail of app developers, 
 hackers and researchers who are willing to take fresh approaches, learn from
 past mistakes, and collectively aim to increase the overall encryption
-of email in the net.  The group effort was born and named "Autocrypt"
+of e-mail in the net.  The group effort was born and named "Autocrypt"
 on December 17th 2016 by ~20 people during a 5-day meeting at the 
 OnionSpace in Berlin. It's a dynamic, fun process which is open to 
 new people, influences and contributions.  See :doc:`contact channels
@@ -36,9 +36,9 @@ and upcoming events <contact>` on how you may talk with us and who
 The technical Autocrypt approach
 --------------------------------------
 
-Autocrypt uses regular email messages between people to piggyback
+Autocrypt uses regular e-mail messages between people to piggyback
 necessary information to allow encrypting subsequent messages.  
-Under the hood, Autocrypt uses email headers for this information
+Under the hood, Autocrypt uses e-mail headers for this information
 transfer. By default, no key management is visible to users.
 See :doc:`features` for more technical and UI cornerstones.
 

doc/level0.rst

@@ -129,7 +129,7 @@ represents a specific subset of OpenPGP (see the the next section).
 ``key`` MUST be the last attribute.
 
 ``prefer-encrypted`` indicates that agents should default to
-encrypting when composing emails to this recipient.
+encrypting when composing e-mails to this recipient.
 If ``prefer-encrypted`` is not set,
 the value of ``prefer-encrypted`` is ``nopreference``.
 If ``prefer-encrypted`` is set, but neither ``yes`` nor ``no``,

doc/other-crypto-interop.rst

@@ -64,7 +64,7 @@ can I use someone's pgp key that i have for encrypting mail to that person?
 if i have for a person an non-Autocrypt pgp key and an Autocrypt key, which one do
 i use to encrypt mails for that person?
 
-- Look up email address in pgp keyring
+- Look up e-mail address in pgp keyring
 - if there is a key that has better user ID validity for the matching address than "unknown", use that one
 - else look up a key from the Autocrypt state (which is also in the keyring)