Fixed heading links to those with forward slash

1 files changed, 9 insertions, 9 deletions

diff --git a/src/blog/encrypted-email/index.md b/src/blog/encrypted-email/index.md
index f09f6ff..5399ee5 100644
--- a/src/blog/encrypted-email/index.md
+++ b/src/blog/encrypted-email/index.md
@@ -17,9 +17,9 @@ That's why, after a fairly lengthy research process, I've decided to do just tha
 
 1. [Encryption and signature](#encryption-and-signature)
 2. [OpenPGP](#openpgp)
-   1. [PGP/Inline](#pgp47inline)
-   2. [PGP/MIME](#pgp47mime)
-3. [S/MIME](#s47mime)
+   1. [PGP/Inline](#pgpinline)
+   2. [PGP/MIME](#pgpmime)
+3. [S/MIME](#smime)
 4. [reop](#reop)
 5. [Post-email systems](#post-email-systems)
 6. [Centralized non-email systems](#centralized-non-email-systems)
@@ -54,12 +54,12 @@ By far, the most popular way to encrypt your emails is with [OpenPGP](https://en
 
 By design, it relies on a [web of trust](https://en.wikipedia.org/wiki/Web_of_trust), the idea being, different people sign each others public keys (sometimes at [key signing parties](https://en.wikipedia.org/wiki/Key_signing_party)), and you know that a specific key corresponds to a specific person, only when a large amount of people have signed it.
 
-OpenPGP divides the security community quite a lot, some [abolish it](https://restoreprivacy.com/let-pgp-die/) while other still [defend it](https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/), but at the end of the day, it's very widespread and if someone encrypts their email, chances are it's with OpenPGP (unless they're in a business, where [S/MIME](#s47mime) rules).
+OpenPGP divides the security community quite a lot, some [abolish it](https://restoreprivacy.com/let-pgp-die/) while other still [defend it](https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/), but at the end of the day, it's very widespread and if someone encrypts their email, chances are it's with OpenPGP (unless they're in a business, where [S/MIME](#smime) rules).
 
 There are two main ways to encrypt an email with OpenPGP:
 
 ### PGP/Inline
-[![🔗](/img/link-tabler.svg)](#pgp47inline)
+[![🔗](/img/link-tabler.svg)](#pgpinline)
 
 The first is called "PGP/Inline", with which you encrypt only the message itself. That's it. And there are [other limitations](https://josefsson.org/inline-openpgp-considered-harmful.html) too, to name a few:
 
@@ -72,7 +72,7 @@ Though, it's not all bad. If you can survive only sending text to other people,
 2. The other option, PGP/MIME, is much harder to implement properly and there have been cases where [it's implementation is flawed](https://web.archive.org/web/20180625054201/https://www.whonix.org/blog/pgp-inline-vs-mime)
 
 ### PGP/MIME
-[![🔗](/img/link-tabler.svg)](#pgp47mime)
+[![🔗](/img/link-tabler.svg)](#pgpmime)
 
 "PGP/MIME" is the second option. As it's name suggests, you can encrypt [MIME](https://en.wikipedia.org/wiki/MIME) data with PGP, which by definition means it supports any content type. This includes:
 
@@ -89,7 +89,7 @@ PGP/MIME is capable of a lot more, and is [generally preferred](https://www.mail
 3. If your client doesn't support it, manual decryption takes a bit more work
 
 ## S/MIME
-[![🔗](/img/link-tabler.svg)](#s47mime)
+[![🔗](/img/link-tabler.svg)](#smime)
 
 [S/MIME](https://en.wikipedia.org/wiki/S/MIME), roughly said, combines and extends the [Cryptograhic Message Syntax](https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax) encryption scheme and [MIME](https://en.wikipedia.org/wiki/MIME) standard to create a singular, email-oriented standard.
 
@@ -99,7 +99,7 @@ So, already, it has a huge advantage, you don't need to exchange keys, since the
 
 On the other hand, you can browse [Google's](https://support.google.com/a/answer/7448393?hl=en&ref_topic=9061730) and [Microsoft's](https://docs.microsoft.com/en-us/security/trusted-root/participants-list) trusted (root) CAs all you want, but you'll find that there is only one place where you could register a certificate for free: [Actalis](https://www.actalis.com/s-mime-certificates.aspx). A good tutorial on the procedure can be found [here](https://www.dannyguo.com/blog/how-to-get-a-free-s-mime-certificate/), but beware, *they* generate the private key.
 
-Otherwise, it's email encryption capabilities are the same as those outlined in [PGP/MIME](#pgp47mime).
+Otherwise, it's email encryption capabilities are the same as those outlined in [PGP/MIME](#pgpmime).
 
 ## reop
 [![🔗](/img/link-tabler.svg)](#reop)
@@ -163,6 +163,6 @@ Finally, pricing. In general, they have a lot less features than [Protonmail](#p
 ## Conclusion
 [![🔗](/img/link-tabler.svg)](#conclusion)
 
-In brief, almost all email encryption systems use [public-key cryptography](#encryption-and-signature). The most popular of these systems for personal use is [OpenPGP](#openpgp), but in the business space, [S/MIME](#s47mime) is quite a bit more prominent. [reop](#reop) is a viable, but limited, very new and lightweight systems for encrypting your email messages.
+In brief, almost all email encryption systems use [public-key cryptography](#encryption-and-signature). The most popular of these systems for personal use is [OpenPGP](#openpgp), but in the business space, [S/MIME](#smime) is quite a bit more prominent. [reop](#reop) is a viable, but limited, very new and lightweight systems for encrypting your email messages.
 
 [Protonmail](#protonmail) is an email provider, which has [OpenPGP](#openpgp) built-in, enabling and supporting encryption by default, but their free tier leaves what to be desired. [Tutanota](#tutanota) is another provider, with their own entirely different system, where encrypted emails to non-tutanota users force the recipients to use their web client.