Sicherer E-Mail Transport - Revision history

Vogel at 20:11, 22 October 2015

2015-10-22T20:11:39Z

← Older revision		Revision as of 20:11, 22 October 2015
Line 213:		Line 213:


	~~Das aktuelle~~ Postfix ~~unterstützt~~ DANE ~~bereits~~, ~~aber DANE~~ kann ~~entweder~~ ~~anstatt~~ ~~von~~ Opportunistic TLS konfiguriert werden, ~~oder~~ es ~~Alternativ~~ ~~jede~~ ~~Domain~~ ~~gepflegt~~ ~~werde~~, für die DANE ~~genutzt~~ werden soll. Da DANE noch ~~kein e~~ ~~Flächendeckende~~ Verbreitung hat, kommt zur Zeit eigentlich nur Möglichkeit in Frage DANE per ~~Domain~~ zu aktivieren, was aber doch sehr Pflegebedürftig ist. Wünschenswert wäre, dass wenn DANE konfiguriert ist als Fallback Opportunistic TLS genutzt werden würde.		Postfix hat eine DANE Unterstützung eingebaut, diese kann aber nur anstatt Opportunistic TLS konfiguriert werden. Alternativ wäre Liste mit Domains zu pflegen, für die DANE eingesetzt werden soll. Da DANE noch keine flächendeckende Verbreitung hat, kommt zur Zeit eigentlich nur Möglichkeit in Frage DANE per Liste zu aktivieren, was aber doch sehr Pflegebedürftig ist. Wünschenswert wäre, dass wenn DANE konfiguriert ist als Fallback Opportunistic TLS genutzt werden würde.

Vogel at 20:06, 22 October 2015

2015-10-22T20:06:57Z

← Older revision		Revision as of 20:06, 22 October 2015
Line 235:		Line 235:
	* [https://tools.ietf.org/html/rfc7218 RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)]		* [https://tools.ietf.org/html/rfc7218 RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)]


	==Wikipedia==
	* [https://en.wikipedia.org/wiki/Sender_Policy_Framework]		* [https://en.wikipedia.org/wiki/Sender_Policy_Framework Sender_Policy_Framework]
	* [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail]		* [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DomainKeys_Identified_Mail]
	* [https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions]		* [https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions Domain_Name_System_Security_Extensions]

	==Check Tools==		==Check Tools==

Vogel at 20:02, 22 October 2015

2015-10-22T20:02:02Z

← Older revision		Revision as of 20:02, 22 October 2015
Line 177:		Line 177:
	* [[DNSSec]]		* [[DNSSec]]
	* [[DANE_für_unseren_Mail-Server]]		* [[DANE_für_unseren_Mail-Server]]


	==DANE==		==DANE==

Vogel at 20:01, 22 October 2015

2015-10-22T20:01:36Z

← Older revision		Revision as of 20:01, 22 October 2015
Line 97:		Line 97:

	Ein gültiger SPF Record hilft häufig auch dabei, dass E-Mails am Greylistening vorbei kommen, sowie auch einen besseren SPAM Score erzielen.		Ein gültiger SPF Record hilft häufig auch dabei, dass E-Mails am Greylistening vorbei kommen, sowie auch einen besseren SPAM Score erzielen.


	==DKIM==		==DKIM==
Line 137:		Line 138:

	Da die DKIM Signatur auch von Spam Scannern mit einbezogen wird, kann mit einer gültigen DKIM Signatur ein besserer Spam Score erzielt werden.		Da die DKIM Signatur auch von Spam Scannern mit einbezogen wird, kann mit einer gültigen DKIM Signatur ein besserer Spam Score erzielt werden.


	==DNSSEC==		==DNSSEC==
Line 211:		Line 213:

	Das aktuelle Postfix unterstützt DANE bereits, aber DANE kann entweder anstatt von Opportunistic TLS konfiguriert werden, oder es Alternativ jede Domain gepflegt werde, für die DANE genutzt werden soll. Da DANE noch kein e Flächendeckende Verbreitung hat, kommt zur Zeit eigentlich nur Möglichkeit in Frage DANE per Domain zu aktivieren, was aber doch sehr Pflegebedürftig ist. Wünschenswert wäre, dass wenn DANE konfiguriert ist als Fallback Opportunistic TLS genutzt werden würde.		Das aktuelle Postfix unterstützt DANE bereits, aber DANE kann entweder anstatt von Opportunistic TLS konfiguriert werden, oder es Alternativ jede Domain gepflegt werde, für die DANE genutzt werden soll. Da DANE noch kein e Flächendeckende Verbreitung hat, kommt zur Zeit eigentlich nur Möglichkeit in Frage DANE per Domain zu aktivieren, was aber doch sehr Pflegebedürftig ist. Wünschenswert wäre, dass wenn DANE konfiguriert ist als Fallback Opportunistic TLS genutzt werden würde.


	=TestUmgebung=		=TestUmgebung=

Vogel: /* SPF */

2015-10-22T19:57:49Z

SPF

← Older revision		Revision as of 19:57, 22 October 2015
Line 71:		Line 71:
	Der Eintrag hat die folgende Syntax:		Der Eintrag hat die folgende Syntax:

	<b>v=versionsnummer <i>~~mechanism~~</i> <i>~~mechanism~~</i></b>		<b>v=versionsnummer <i>qualifier</i>mechanism <i>qualifier</i>mechanism</b>

	* Beispiel		* Beispiel
Line 89:		Line 89:
	** <b>?</b> für NEUTRAL. Wird intepretiert als wenn keine policy angegeben wäre.		** <b>?</b> für NEUTRAL. Wird intepretiert als wenn keine policy angegeben wäre.
	** <b>~ (tilde)</b> für SOFTFAIL. Eine Debugging Variante die zwischen NEUTRAL und FAIL angesiedelt ist. Üblicherweise wird eine E-Mail mit SOFTFAIL akzeptiert aber getagt.		** <b>~ (tilde)</b> für SOFTFAIL. Eine Debugging Variante die zwischen NEUTRAL und FAIL angesiedelt ist. Üblicherweise wird eine E-Mail mit SOFTFAIL akzeptiert aber getagt.
	** <b>- (minus</b> für FAIL. Die E-Mail sollte abgelehnt werden.		** <b>- (minus)</b> für FAIL. Die E-Mail sollte abgelehnt werden.

Vogel: /* SPF */

2015-10-22T19:55:43Z

SPF

@@ Line 67: / Line 67: @@
 itsec.vog3l.de.         291780  IN      TXT     "v=spf1 mx -all"</pre>
@@ Line 74: / Line 97: @@
 Ein gültiger SPF Record hilft häufig auch dabei, dass E-Mails am Greylistening vorbei kommen, sowie auch einen besseren SPAM Score erzielen.
 ==DKIM==

Vogel: /* DNSSEC */

2015-10-22T19:37:31Z

DNSSEC

← Older revision		Revision as of 19:37, 22 October 2015
Line 122:		Line 122:
	<pre>$ dig +dnssec mail.itsec.vog3l.de		<pre>$ dig +dnssec mail.itsec.vog3l.de

	mail.itsec.vog3l.de. 604800 IN A 5.9.27.~~206~~		mail.itsec.vog3l.de. 604800 IN A XX.XX.XX.XXX
	mail.itsec.vog3l.de. 604800 IN RRSIG A 5 4 604800 20151103185106 20151004185106 59235 itsec.vog3l.de. iJP8jqmXpUxSI+OXH+s7naTnLyAV9xqTqGRJmicJhQnzIfSWA/Hc+21k ZLwkL48NswboaGtM7aBMa5GyS3Ej3rA5TO		mail.itsec.vog3l.de. 604800 IN RRSIG A 5 4 604800 20151103185106 20151004185106 59235 itsec.vog3l.de. iJP8jqmXpUxSI+OXH+s7naTnLyAV9xqTqGRJmicJhQnzIfSWA/Hc+21k ZLwkL48NswboaGtM7aBMa5GyS3Ej3rA5TO
	mr6+97P46mdypI3iUhZunG MJrHRwkKeaFbeFvQJDRLdaTePxTpODuWnUv7gD62Rxu9MRRKoV2/Q6cy o4GpNHd3//Zr21GsAk9m99N9xETdEySlPImO3aemSymH579rsZ7CyqDX +eRlYJIeoXaECdJV0N/6DvtJmgS2OpC6XL8qPUbz/KzCk0Kh4WNVfRrh IrbsYEEAf0		mr6+97P46mdypI3iUhZunG MJrHRwkKeaFbeFvQJDRLdaTePxTpODuWnUv7gD62Rxu9MRRKoV2/Q6cy o4GpNHd3//Zr21GsAk9m99N9xETdEySlPImO3aemSymH579rsZ7CyqDX +eRlYJIeoXaECdJV0N/6DvtJmgS2OpC6XL8qPUbz/KzCk0Kh4WNVfRrh IrbsYEEAf0

Vogel: /* DNSSEC */

2015-10-22T19:34:29Z

DNSSEC

← Older revision		Revision as of 19:34, 22 October 2015
Line 143:		Line 143:


	Jede DNS Zone hat zwei Arten von Keys zum signieren. Der Zone Signing Key (ZSK) wird zum signieren der Ressource Records verwendet und der zugehörige Public Key im DNSKEY Record hinterlegt. Der DNSKEY Record selber wird mit einem Key Signing Key (KSK) signiert. Der Public Key des KSK wird in der übergeordneten DNS Zone bekannt gemacht, indem dieser in einem DS Record veröffentlicht und mit dem ZSK der übergeordneten Zone signiert wird. Dies wird bis zur Root Zone entsprechend fortgeführt und dadurch ~~ein~~ Trust ~~Anchor~~ aufgebaut.		Jede DNS Zone hat zwei Arten von Keys zum signieren. Der Zone Signing Key (ZSK) wird zum signieren der Ressource Records verwendet und der zugehörige Public Key im DNSKEY Record hinterlegt. Der DNSKEY Record selber wird mit einem Key Signing Key (KSK) signiert. Der Public Key des KSK wird in der übergeordneten DNS Zone bekannt gemacht, indem dieser in einem DS Record veröffentlicht und mit dem ZSK der übergeordneten Zone signiert wird. Dies wird bis zur Root Zone entsprechend fortgeführt und dadurch eine Trust Chain aufgebaut.


Line 153:		Line 153:
	* [[DNSSec]]		* [[DNSSec]]
	* [[DANE_für_unseren_Mail-Server]]		* [[DANE_für_unseren_Mail-Server]]


	==DANE==		==DANE==

Vogel: /* DKIM */

2015-10-22T19:27:48Z

DKIM

← Older revision		Revision as of 19:27, 22 October 2015
Line 77:		Line 77:

	==DKIM==		==DKIM==
	DomainKeys Identified Mail (DKIM) ist eine Anti Spoofing und Anti Phishing Technik.		DomainKeys Identified Mail (DKIM) ist eine Anti-Spoofing und Anti-Phishing Technik.

	Die E-Mail wird hierfür vom versendenden MTA mit einer Signatur versehen ~~und~~ der Public Key in der DNS Zone in einem TXT Record hinterlegt.		Die E-Mail wird hierfür vom versendenden MTA mit einer Signatur versehen. Vorher wird der Public Key in der DNS Zone in einem TXT Record hinterlegt.
	Damit kann der empfangenden MTA sicherstellen, dass der Versand für diese Domain authorisiert ist und die E-Mail beim Transport nicht modifiziert worden ist.		Damit kann der empfangenden MTA sicherstellen, dass der Versand für diese Domain authorisiert ist und die E-Mail beim Transport nicht modifiziert worden ist.

Line 115:		Line 115:

	Da die DKIM Signatur auch von Spam Scannern mit einbezogen wird, kann mit einer gültigen DKIM Signatur ein besserer Spam Score erzielt werden.		Da die DKIM Signatur auch von Spam Scannern mit einbezogen wird, kann mit einer gültigen DKIM Signatur ein besserer Spam Score erzielt werden.


	==DNSSEC==		==DNSSEC==

Vogel: /* DANE */

2015-10-22T19:16:05Z

DANE

← Older revision		Revision as of 19:16, 22 October 2015
Line 171:		Line 171:
	<b>Certificate Usage \| Selector \| Matching Type</b>		<b>Certificate Usage \| Selector \| Matching Type</b>

	* ~~Certifcate~~ Usage Feld		* Certificate Usage Feld
			**0 <i>CA Constraint:</i> Nur die CA im TLSA Record darf als Trust Anchor verwendet werden und es wird eine Prüfung der Vertrauenshierarchie durchgeführt.
	**0 <i>CA Constraint:</i>
	**1 <i>Service Certificate Constraints:</i> Dem Zertifikat im TLSA Record soll vertraut und eine Prüfung der Vertrauenshierarchie durchgeführt ~~werden~~.		**1 <i>Service Certificate Constraints:</i> Dem Zertifikat im TLSA Record soll vertraut werden und es wird eine Prüfung der Vertrauenshierarchie durchgeführt.
	**2 <i>Trust Anchor Assertion:</i> Das Zertifikat ~~muss von der CA~~ im TLSA Record als Trust Anchor ~~ausgestellt~~ ~~worden~~ ~~sein~~.		**2 <i>Trust Anchor Assertion:</i> Das Zertifikat im TLSA Record soll als Trust Anchor verwendet werden und es wird eine Prüfung der Vertrauenshierarchie durchgeführt.
	**3 <i>Domain-Issued Certificate:</i> Dem Zertifikat im TLSA Record soll vertraut und keine Prüfung der Vertrauenshierarchie durchgeführt ~~werden~~.		**3 <i>Domain-Issued Certificate:</i> Dem Zertifikat im TLSA Record soll vertraut werden und es wird keine Prüfung der Vertrauenshierarchie durchgeführt.

	* Selector Feld:		* Selector Feld: