1 Beschreibung

Profis die gleich die Zusammenfassung sehen und die Beschreibung überspringen wollen, gehen gleich zum Abschnitt 2 unten.

1.1 - SPF

Das Sender Policy Framework (SPF; früher Sender Permitted From) ist ein Verfahren, das

das Fälschen der Absenderadresse einer E-Mail verhindern soll. Es entstand als Verfahren zur Abwehr von Spam. SPF überprüft die HELO Domain sowie Mail FROM Adresse gegen die in DNS veröffentlichten Einstellungen. Bei SPF trägt der Inhaber der Domain in einem TXT DNS Record die berechtigten Mail Server ein denen es erlaubt ist E-Mails der Domain zu senden. Ein Empfänger der auf SPF prüft verweigert die Zustellung von E-Mails von Servern die nicht in der Liste der Berechtigten Server steht. 

Ein SPF Eintrag ist ab eintragen des DNS Records aktiv. Wenn die Firewall bzw. der Mailfilter des Senders ebenfalls auf SPF prüft, ist dadurch auch aus interner Sicht der Schutz gegeben, dass eingehende Mails bei welchen der Absender aus der eigenen Domain zu sein scheint abgelehnt werden. Es wird somit auch der eigene Spam Filter verbessert. Typisch für diese Fälle wäre eingehenden Spam Mails in der Form „Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!“.

Im Falle von SPF ist es wichtig, dass eventuelle Fordwarder/Relay oder WebDienste (Beispiel Online Shops) die im Namen der eigenen Domäne Mail senden, diese ebenso im SPF Eintrag gelistet sind. SPF ist in RFC 4408 definiert.

1.1.1 Erstellen des SPF DNS Records

1. Neuen DNS Record erstellen für Domain beim Provider
2. Typ:       TXT
   Name: keiner (leer lassen)
   Inhalt: v=spf1 mx –all
3. Mit diesem Eintrag wird gewährleistet, dass nur Mailserver welche einen MX Eintrag in der DNS Domain besitzen zugelassene Mailserver sind (mx) und alles Andere hard-fail abgewiesen wird (-all).

1.1.2 Aktivieren des SPF Check auf Sophos SG UTM

1. Email Protection -> SMTP -> Register AntiSpam -> Bereich Advanced anti-spam features
2. Option Perform SPF check aktivieren und Apply zum Speichern.
   
   

1.1.3 Wichtige SPF Tags:

1.2 - DKIM

Mit DKIM werden E-Mail-Header und Body digital signiert um die Authentizität des Absenders zu garantieren. Mails werden nicht verschlüsselt oder deren Inhalt digital unterschieben, sondern es wird  im Header ein Hashwert  (DKIM-Signature) hinterlegt, welche die Firewall/Mailserver über seinen private Key generiert hat. Der vom Empfänger dekodiert die Signatur mit dem über DNS veröffentlichten Public Key. Dadurch wird die Echtheit des Senders (also des Smarthosts/Mailservers) und des Inhaltes (Manipulationsschutz) bestätigt.

Die Sophos SG Firewalls unterstützen das Verfahren DomainKeys Identified Mail (DKIM) und können bei ausgehenden Mails dem Header automatisch die digitale Signatur hinzufügen. Bei DKIM wird ein selbsterstellter Key verwendet welcher mit z.B. OpenSSL erstellt wird. Der private Key wird auf der Sophos Firewall im Mailfilter unter Advanced hinterlegt, der öffentliche Teil als DKIM Eintrag, ein TXT Eintrag beim DNS des Providers der Domain, eingetragen. Dieser TXT Eintrag besteht aus einem frei wählbaren Namen der Signatur (dem Selector) und dem Teil „_domainkey.domain.tld“. 

Beispiel: Gewählter Selector Name „selector1“ + „._domainkey.domain.at“ = selector1._domainkey.domain.at“
Der Selector wird verwendet um dem Empfänger mitzuteilen welcher Domainkey TXT Eintrag der verwendet werden soll.

DKIM ist definiert in den RFCs:
4686 - Analysis of Threats Motivating DKIM
5016 - Requirements for a DKIM Signing Practices Protocol
5585 - DKIM Service Overview
5617 - DKIM Author Domain Signing Practices (ADSP)
5863 - DKIM Development, Deployment and Operations
6376 - DKIM Signatures
6377 - DKIM Mailing Lists

Um einen DKIM Key Pärechen zu erstellen wie folgt vorgehen:

1.2.1 Erstellen der SSL RSA Keys mit Open SSL (Windows)

1. Open SSL (Light Version) für Windows herunterladen https://wiki.openssl.org/index.php/Binaries. 64 oder 32 Bit Version von https://slproweb.com/products/Win32OpenSSL.html und installieren.
2. In einer Command Prompt (Als Administrator) SETX OPENSSL_CONF "C:\OpenSSL-Win64\bin\openssl.cfg" /m  (Pfad ggf. anpassen) um die System-Umgebungsvariable zu setzen.
3. Mit Administrator CMD Konsole in den \bin Pfad des Open SSL Installationsverzeichnisses wechseln.
4. Privaten Key erzeugen: Mit openssl genrsa -out dkim_private.key 2048   Dadurch wird der private Key erstellt.
5. Public Key erzeugen: openssl rsa -in dkim_private.key -out dkim_public.key -pubout -outform PEM  Dadurch wird der public Key aus dem privaten Key erstellt.

1.2.2 Erstellen der SSL RSA Keys mit ssh-keygen (Cygwin, Linux)

1. In aktuellen Pfad die Key Dateien generieren:
   ssh-keygen -t rsa -b 2048 -f ./dkim -P ""
2. Es werden 2 Dateien erstellt:
   - dkim :: Text Datei mit private Key
   - pub :: Text Datei mit public Key
3. Die Dateien am besten umbenennen in dkim_private.key und dkim_public.key damit sie nie verwechselt werden:
   mv dkim dkim_private.key; mv dkim.pub dkim_public.key
4. Eine Datei erstellen/zusammenbauen, mit dem Inhalt der in den öffentlichen DNS Eintrag muss:
   echo "v=DKIM1; k=rsa; p=`cat dkim_public.key | sed -e "s/$USERNAME@$HOSTNAME//g" -e 's/ //g' -e 's/ssh-rsa//g'`" >dkim_public_dnsentry.txt

1.2.3 DNS TXT Eintrag veröffentlichen

Der public Teil des Keys (dkim_public.key) wird nun in einem DNS TXT Eintrag veröffentlicht. Der Key Teil der im TXT Eintrag verwendet wird darf in nur einer Zeile stehen, und zwar ohne den  ---Begin/---End Zeilen. Vorhandene Zeilenumbrüche müssen entfernt werden.

Zudem werden vor dem Key noch ein paar Werte addiert. Diese sind
v=DKIM1             - gibt die Version an (muss groß geschrieben werden)
k=rsa                    - es handelt sich um einen RSA Key
p=xyz                   - Der Key selbst

Hinweise:

• Zwischen den werten „v=DKIM1" und "k=rsa" und "p=xyz“ ist jeweils ein Punkt-Komma (; )und ein Leerraum.
  
• Beim DNS Eintrag die Leerräume an den Zeilenenden entfernen.
• Wurde die Variante 1.2.2 verwendet, so kann der Inhalt von dkim_public_dnsentry.txt verwendet werden.

Der TXT Eintrag wird im DNS Panel des Providers eingetragen. Als Name für die TXT Datei wird die Kombination aus frei wählbaren Namen, dem „Selector“ wie oben erwähnt und dem immer gleich bleibenden Namen „_domainkey“ gewählt. In diesem Beispiel wird selector1 als Selectorname verwendet.

Tipp: Ein FQDN schließt eigentlich mit einem „.“ ab. Bei manchen ISP DNS Panels muss dieser abschließende Punkt angegeben werden, manche fügen ihn automatisch hinzu.

Beispiel:

1.2.4 DKIM Private Key in Sophos SG UTM eintragen

1. Email Protection -> SMTP -> Register Advanced -> Abschnitt DomainKeys Identified Mail (DKIM)
2. Den Inhalt von key unverändert! (nur STRG+A , STRG+C) in das Feld Private RSA key: kopieren.
3. Bei Key selector: den gewählten Namen selector1
4. Im Folgeabschnitt DKIM Domains die eigene Domain eintragen. Beispiel domain.tld
   
   Hinweis: 
   Die Sophos SG UTM kann keine unterschiedlichen Selectoren für unterschiedliche Domains verwenden, sondern nur einen Selector für mehrere Domains. Für unterschiedliche Selectoren müsste der SMTP Filter auf Profilmodus geschalten sein.
   
5. Apply zum Speichen

1.3 - DMARC

Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF, Sender Policy Framework) bzw. dass diese Mail unverändert vom Absender stammt (DKIM, DomainKeys Identified Mail), kann der Absender mit der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht. Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität der E-Mails verbessert.

Der DMARC Syntax gibt an was mit einer Mail passiert, welche die Bestimmungen nicht erfüllt und nimmt somit in gewisser weise das SPF/DKIM Handling des Empfängers „ab“ und bestimmt das Vorgehen aber nur WENN der Empfänger DMARC konform ist. Ein Empfänger der nicht auf SPF/DKIM/DMARC prüft, ist nicht an diesem Policies interessiert und nimmt „alles“ entgegen.

• DMARC Syntax Nachlese: https://dmarc.org//draft-dmarc-base-00-01.html#iana_dmarc_tags
  
• DMARC darf/kann nur aktiviert werden wenn SPF und DKIM bereits funktionstüchtig konfiguriert wurde!
• DMARC ist in der RFC 7489 Definiert.

1.3.1 Aktivierung von DMARC:

1. Konfiguration von SPF und DKIM abschließen und sicherstellen.
2. Neuen DNS Eintrag erzeugen für Domain.
   Die folgende Einstellung verwirft alle Mails deren SPF oder DKIM Status ungültig ist.
   Typ:                     TXT
   Name:                 _dmarc
   FQDN Name:      domain.at
   Inhalt:                 v=DMARC1; p=reject; pct=100;
   
   
3. Mit folgenden Inhalt werden zusätzlich Reports an den Sender zugestellt betreffend Status und/oder Grund der ungültigkeit des Mails.
   Hinweis: Sollte ihr Mailsystem bereits selbst Übersichten/Reports bereitstellen ist dies ggf. nicht erwünscht bzw. kann auch zu vielen Mails führen.
   v=DMARC1; p=reject; pct=100; rua=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!; ruf=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!; ri=86400
   
   
4. Leicht abgeänderte Policy, ohne Forensic Mails, jedoch mit Reports 1x die Woche: 
   v=DMARC1; p=reject; pct=100; rua=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!; ri= 604800

1.3.2 DMARC Tags:

1.4 - Sender ID

Sender ID ist ein von Microsoft entwickeltes Verfahren zur Absenderprüfung welches auf Basis von SPF entwickelt wurde. Es versuchte SPF und Caller ID (Microsoft) zu vereinen.

Laut meiner Recherche ist der verwendete Tag „spf2.0“ eigentlich ein Unfall der damaligen IETF-Arbeitsgruppe die sich nicht auf Spezifizierungen einigen konnte und wurde bereits 2004 aufgelöst. Hintergrund waren Lizenz und Patent Problematiken technischer Verfahren von Microsoft. Daher konnte bis 2006 Sender ID nicht für freie Software verwendet werden mangels GNU Lizenz. Trotz Freigabe der technischen Verfahren in 2006 wird bei Anbietern von freier Software Sender ID immer noch vermieden. Sender ID ist in der „Microsoft Welt“ jedoch durchaus immer noch vertreten und ist daher bei Kunden die in dieser Welt zu Hause sind immer noch ein aktuelles Verfahren nebst SPF. Es ist auch im Exchange Server sowie Collaborativer Software von Microsoft verankert.

Wer viel in der MS-Welt zu tun hat, sollte dieses Verfahren zusätzlich zu SPF aktivieren für den Fall dass der Partner auf Sender ID prüft oder möchte. Im Gegensatz zu SPF welches HELO und Mail FROM validiert, verwendet Sender ID nebst MAIL FROM alle Header Adressen zur Überprüfung. Das geschieht mit Hilfe einer PRA (Purported Responsible Address) Identität. Diese Identität hat den Ansatz, aus den vielen Header Adressen den „höchstwahrscheinlichen ursprünglichen Absender“ einer Nachricht zu ermitteln und wird PRA genannt.

Durch den Aufbau auf SPF sind die verwendeten Optionen (Syntax) gleich wie jene unter SPF. Unterschied ist nur der einleitende Tag „spf2.0“ und die nachkommende Definition ob MailFrom und PRA oder nur MailFrom oder PRA zur Überprüfung herangezogen wird. Wie auch bei SPF ist es wichtig, sollten Forwarder/Relay Server im Einsatz sein, dass diese ebenso in der Policy angegeben werden.

Sender ID ist in der RFC 4406 definiert. Man sollte hingegen auch die Community Positionierung zu diesen Thema beachten. Zudem verletzt Sender ID RFC 4406 die SPF RFC 4408 was zusätzlich zu Kontroversen führt.
spf2.o/pra                     :: Verwendet den PRA Algorithmus.
spf2.o/mfrom               :: Verwendet die MFrom Überprüfung (wie SPF).
spf2.0/mfrom,pra     :: Verwendet PRA und MFROM zur Überprüfung.

Eine Starke Schwäche von Sender ID (von PRA) sind Mailing Lists. hierbei gibt es eine 10% False-Positive Rate bis hin zu angeblich Faktor 1:1000 im Vergleich zu SPF. Da es den Anscheind hat, dass Sender ID immer weniger eine Rolle spielen wird, ist es höchstwahrscheinlich eine gute Idee, wenn überhaupt, dann nur spf2.0/mfrom mx -all zu verwenden oder eine leere Policy, sprich nur spf2.0/pra ohne Angabe von Optionen.

2 - Zusammenfassungen

2.1 DNS TXT Einträge beim Provider:

2.2 Einträge vom DNS Server abfragen:

3 - Weiterführende Links:

DKIM/DMARC
https://dkimcore.org/c/keycheck
https://dkimcore.org/tools/keycheck.html
https://dkimvalidator.com/
https://dmarcian.com/dmarc-inspector/
https://dmarc.org//draft-dmarc-base-00-01.html#iana_dmarc_tags
https://dmarc.org/resources/deployment-tools/
https://elasticemail.com/dmarc
https://www.unlocktheinbox.com/dmarcwizard/
https://mxtoolbox.com/dmarc/details/dmarc-tags
https://help.returnpath.com/hc/en-us/articles/222437867-What-are-the-different-tags-of-a-DMARC-record-
https://mxtoolbox.com/DMARC/knowledgebase

SPF
http://www.spf-record.de/spf-lookup
http://www.spf-record.de/generator
https://www.emailquestions.com/spf-wizard/
https://de.wikipedia.org/wiki/Sender_Policy_Framework
https://dmarcian.com/spf-syntax-table/

Diverse Tester
https://www.mail-tester.com/
https://www.mail-tester.com/spf-dkim-check
https://mxtoolbox.com/dkim.aspx

Sender ID Policy
https://de.wikipedia.org/wiki/Sender_Policy_Framework
http://www.open-spf.org/SPF_vs_Sender_ID/