Clean up the autocrypt doc a bit more.

diff --git a/doc/manual.xml.head b/doc/manual.xml.head
index b10ba697f900c466f5a5c5f38afe87f08e0a22ea..d1f7a0575385028f628b142c7e55ec663a596612 100644 (file)
--- a/doc/manual.xml.head
+++ b/doc/manual.xml.head
@@ -9915,24 +9915,19 @@ please have a look at the mixmaster documentation.
       be accomplished.  The <emphasis>recommended</emphasis> way is to
       set <link linkend="autocrypt-dir">$autocrypt_dir</link> to your
       normal keyring directory (e.g. <literal>~/.gnupg</literal>).
-      Alternatively you can copy the key over to the Autocrypt keyring
-      (using something along the lines of <literal>gpg --export
-      [keyid] | gpg --homedir=~/.mutt/autocrypt --import</literal>
-      followed by <literal>gpg --export-secret-keys [keyid] | gpg
-      --homedir=~/.mutt/autocrypt --import</literal>).  During account
-      creation, choosing <quote>(s)elect existing GPG key</quote> will
-      then list and allow selecting your existing key for the new
-      account.
+      During account creation, choosing <quote>(s)elect existing GPG
+      key</quote> will then list and allow selecting your existing key
+      for the new account.
     </para>
     <para>
-     Copying your key over keeps Autocrypt keys out of your normal
-     keyring, but there is a severe downside.  Mutt
-     <emphasis>first</emphasis> tries to decrypt messages using the
-     Autocrypt keyring, and if that fails tries the normal keyring
-     second.  This means all encrypted emails to that key will be
-     decrypted, and have signatures verified from, the Autocrypt
-     keyring.  Keys signatures and web of trust from your normal
-     keyring will no longer show up in signatures when decrypting.
+     An alternative is to copy your key over to the Autocrypt keyring,
+     but there is a severe downside.  Mutt <emphasis>first</emphasis>
+     tries to decrypt messages using the Autocrypt keyring, and if
+     that fails tries the normal keyring second.  This means all
+     encrypted emails to that key will be decrypted, and have
+     signatures verified from, the Autocrypt keyring.  Keys signatures
+     and web of trust from your normal keyring will no longer show up
+     in signatures when decrypting.
     </para>
     <para>
       For that reason, if you want to use an existing key from your
@@ -9951,10 +9946,10 @@ please have a look at the mixmaster documentation.
     <itemizedlist>
       <listitem>
         <para>
-          First, replying to an Autocrypt decrypted message by default
-          forces Autocrypt mode on.  By sharing the same key, all
-          replies will then start in Autocrypt mode, even if a message
-          wasn't sent by one of your Autocrypt peers.  <link
+          Replying to an Autocrypt decrypted message by default forces
+          Autocrypt mode on.  By sharing the same key, all replies
+          will then start in Autocrypt mode, even if a message wasn't
+          sent by one of your Autocrypt peers.  <link
           linkend="autocrypt-reply">$autocrypt_reply</link> can be
           <emphasis>unset</emphasis> to allow manual control of the
           mode when replying.
@@ -9962,13 +9957,13 @@ please have a look at the mixmaster documentation.
       </listitem>
       <listitem>
         <para>
-          Second, when Mutt creates an account from a gpg key, it
-          exports the public key, base64 encodes it, and stores that
-          value in the sqlite3 database.  The value is then used in
-          the Autocrypt header added to outgoing emails.  The ECC keys
-          Mutt creates don't change, but if you use external keys that
-          expire, when you resign to extend the expiration you will
-          need to recreate the Autocrypt account using the <link
+          When Mutt creates an account from a gpg key, it exports the
+          public key, base64 encodes it, and stores that value in the
+          sqlite3 database.  The value is then used in the Autocrypt
+          header added to outgoing emails.  The ECC keys Mutt creates
+          don't change, but if you use external keys that expire, when
+          you resign to extend the expiration you will need to
+          recreate the Autocrypt account using the <link
           linkend="autocryptdoc-acctmgmt">account menu</link>.
           Otherwise the Autocrypt header will contain the old expired
           exported keydata.