Updated SPF how to (markdown)

SPF-how-to.md

@@ -6,11 +6,11 @@
 - [Outbound e-mail traffic (DNS records)](#outbound-e-mail-traffic--dns-records-)
 - [Inbound e-mail traffic](#inbound-e-mail-traffic)
   * [Implementing SPF in Postfix with SpamAssassin](#implementing-spf-in-postfix-with-spamassassin)
-  * [Configuring Postfix](#configuring-postfix)
-    + [Postfix configuration for Python SPF policy agent](#postfix-configuration-for-python-spf-policy-agent)
-    + [Postfix configuration for SpamAssassin](#postfix-configuration-for-spamassassin)
-  * [Configuring Python SPF policy agent](#configuring-python-spf-policy-agent)
-  * [Configuring SpamAssassin](#configuring-spamassassin)
+    + [Configuring Postfix](#configuring-postfix)
+      - [Postfix configuration for Python SPF policy agent](#postfix-configuration-for-python-spf-policy-agent)
+      - [Postfix configuration for SpamAssassin](#postfix-configuration-for-spamassassin)
+    + [Configuring Python SPF policy agent](#configuring-python-spf-policy-agent)
+    + [Configuring SpamAssassin](#configuring-spamassassin)
 
 # Introduction
 This how to is created by the Dutch Internet Standards Platform (the organization behind [internet.nl](https://internet.nl)) and is meant to provide practical information and guidance on implementing SPF.  
@@ -51,7 +51,7 @@ Ideally incoming e-mail is processed by making a **single decision** based on a
 * Mail server is operational
 * Software packages are already installed
 
-## Configuring Postfix
+### Configuring Postfix
 The [Postfix SMTP server](http://www.postfix.org/smtpd.8.html) seems to be processing e-mails in a sequential order by means of so-called [access restriction lists](http://www.postfix.org/SMTPD_ACCESS_README.html#lists). For each stage of the SMTP conversation Postfix can apply a specific set of restrictions. As repeatedly stated in the [main.cf man page](http://www.postfix.org/postconf.5.html) “Restrictions are applied in the order as specified; the first restriction that matches wins”. This should be taken into consideration when configuring your Postfix implementation. 
 
 The follow table provides a schematic overview of an SMTP conversation and relates specific stages to Postfix' access restriction lists. 
@@ -79,7 +79,7 @@ The follow table provides a schematic overview of an SMTP conversation and relat
 | 221 2.0.0 Bye | | |
 | Connection closed by foreign host. | | |
 
-### Postfix configuration for Python SPF policy agent  
+#### Postfix configuration for Python SPF policy agent  
 The implementation described in this how to uses an external application to perform SPF checking: Python SPF policy agent (postfix-policyd-spf-python). In order for Postfix to be able to use this application, the following needs to be added to **/etc/postfix/master.cf**: 
 
 `policy-spf unix - n n - - spawn user=nobody argv=/usr/bin/policyd-spf`
@@ -100,7 +100,7 @@ Now also add the following to **/etc/postfix/main.cf**, outside of any section.
 
 `policy-spf_time_limit = 3600s`
 
-### Postfix configuration for SpamAssassin
+#### Postfix configuration for SpamAssassin
 Because this implementation uses SpamAssassin for post-SMTP spam filtering, the following needs to be added to /etc/postfix/master.cf:
 
 ```
@@ -111,7 +111,7 @@ Finally, add the following to **/etc/postfix/main.cf** outside of any section to
 
 `spamassassin_destination_recipient_limit = 1`
 
-## Configuring Python SPF policy agent
+### Configuring Python SPF policy agent
 The next step is to tell the Python SPF policy agent how to behave when checking SPF records. This behavior is determined by adding [configuration parameters](https://manpages.debian.org/stretch/postfix-policyd-spf-python/policyd-spf.conf.5.en.html) to **/etc/postfix-policyd-spf-python/policyd-spf.conf**. 
 
 The default configuration of the Python SPF policy agent provides a binary "block" or "don't block" functionality. However, the implementation described in this how to uses SpamAssassin as a post-SMTP spam filter. This means that Postfix should not reject e-mails coming from e-mail servers that are not listed in the SPF record. Instead an SPF header is appended to the e-mail. The information in the header is used by SpamAssassin to weigh whether an incoming e-mail should be considered spam. This specific setup requires the following non-default configuration parameters in **/etc/postfix-policyd-spf-python/policyd-spf.conf**:
@@ -121,7 +121,7 @@ HELO_reject = False
 Mail_From_reject = False
 ```
 
-## Configuring SpamAssassin
+### Configuring SpamAssassin
 SpamAssassin uses a scoring mechanism in order to determine if an e-mail should be considered spam. By default SpamAssassin considers an e-mail to be spam if the score at least "5". An e-mail starts with a score of 0 and points are added based on the [tests](https://spamassassin.apache.org/old/tests_3_3_x.html) performed. The tests performed can be configured by adding specific [configuration parameters](https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html) in **/etc/spamassassin/local.cf**.
 
 Now here's the tricky part. The points added to the score of an incoming e-mail based on the results of a specific test, is at its core a custom job. Many variables can be taken into consideration when scoring an e-mail (which is considered the strength of a post-SMTP spam filter) and the detailed scoring depends on a domain owner's specific wishes. For the sake of this how to, the SPF scoring will be based on the assumption that the domain owner wants to consider an e-mail to be spam if the sending e-mail server's IP-address or host is not in the domain's SPF record.