Mein Datenhaufen zu IT und Elektronik Themen.

Schlagwort: E-Mail (Seite 1 von 2)

RSPAMD automatisch SPAM / HAM lernen mit Dovecot und IMAPSieve

Bei jedem Spamfilter kann es vorkommen, dass Spam durchrutscht oder eine echte Nachricht fälschlicherweise als Spam eingestuft wird. Rspamd bietet über das Webinterface die Möglichkeit, trainiert zu werden. Hier kann man einfach den Quellcode jeder E-Mail kopieren und Rspamd mitteilen, ob es sich dabei um Spam (SPAM) oder um eine legitime Nachricht (HAM) handelt. Dieses Vorgehen ist jedoch ungeeignet, um den Spamfilter effektiv zu trainieren.

Wünschenswert wäre folgende Lösung: Immer wenn ein Benutzer eine E-Mail in den Ordner „Junk“ verschiebt, sollte diese E-Mail automatisch von Rspamd als Spam gelernt werden. Zusätzlich sollte jede E-Mail, die der Benutzer aus dem „Junk“-Ordner herausholt, als Ham gelernt werden.

Genau dieses Szenario möchte ich hier kurz beschreiben. Das Hostsystem ist ein FreeBSD; Linux-User müssen daher bei den Pfaden wie /usr/local aufpassen! Ebenfalls lauscht mein Rspamd-Worker nicht auf einem Unix-Socket, sondern auf der IP 127.0.0.3, da er in einer Jail-Umgebung läuft.

Beginnen wir mit der Konfiguration für Dovecot.

20-imap.conf:

protocol imap {
  mail_plugins = $mail_plugins sieve
}

90-plugin.conf:

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # From elsewhere to Spam folder or flag changed in Spam folder
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY FLAG
  imapsieve_mailbox1_before = file:/usr/local/etc/dovecot/sieve/report-spam.sieve

  # From Spam folder to elsewhere
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/local/etc/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/local/libexec/dovecot

  sieve_global_extensions = +vnd.dovecot.pipe
}

/usr/local/etc/dovecot/sieve/report-spam.sieve:

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "imap4flags"];

if environment :is "imap.cause" "COPY" {
    pipe :copy "sa-learn-spam.sh";
}

# Catch replied or forwarded spam
elsif anyof (allof (hasflag "\\Answered",
                    environment :contains "imap.changedflags" "\\Answered"),
             allof (hasflag "$Forwarded",
                    environment :contains "imap.changedflags" "$Forwarded")) {
    pipe :copy "sa-learn-spam.sh";
}

/usr/local/etc/dovecot/sieve/report-ham.sieve:

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {
  set "mailbox" "${1}";
}

if string "${mailbox}" [ "Trash", "train_ham", "train_prob", "train_spam" ] {
  stop;
}

pipe :copy "sa-learn-ham.sh";

Natürlich nicht vergessen, die beiden neuen Sieve-Skripte für Sieve zu kompilieren:

# sievec /usr/local/etc/dovecot/sieve/report-spam.sieve
# sievec /usr/local/etc/dovecot/sieve/report-ham.sieve

Es fehlen nur noch die beiden Shell-Skripte, um die Mails an Rspamd weiterleiten zu können.

/usr/local/libexec/dovecot/sa-learn-spam.sh:

#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_spam

/usr/local/libexec/dovecot/sa-learn-ham.sh:

#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_ham

Beide müssen ausführbar sein:

# chmod +x /usr/local/libexec/dovecot/sa-learn-spam.sh /usr/local/libexec/dovecot/sa-learn-ham.sh

Wenn ich nun eine E-Mail in den Ordner „Junk“ verschiebe, lernt Rspamd diese automatisch als Spam:

2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_message_parse: loaded message; id: <FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net>; queue-id: <undef>; size: 49053; checksum: <f5e2fc59515e1da33d532c6f03f6f6f0>
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) <b91225>; csession; rspamd_controller_learn_fin_task: <127.0.0.3> learned message as spam: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net

Verschiebe ich eine E-Mail aus dem Ordner „Junk“ heraus, wird sie, wie gewünscht, als Ham gelernt:

2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_message_parse: loaded message; id: <FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net>; queue-id: <undef>; size: 49053; checksum: <f5e2fc59515e1da33d532c6f03f6f6f0>
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) <a7fe42>; csession; rspamd_controller_learn_fin_task: <127.0.0.3> learned message as ham: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net

Fragen? Einfach fragen!

Ach, und was man nicht mehr verwenden sollte: das Antispam-Plugin – das ist „tot“.

Automatische E-Mail Archivierung mit Dovecot IMAP

Um etwas mehr Ordnung in meinem IMAP Postfach zu halten nutzen ich ein kleines Python Skript cleanup-maildir https://www.freshports.org/mail/cleanup-maildir/. Dieses Skript läuft jede Nacht und sortiert automatisch alle E-Mails die älter sind als 365 Tage aus meinem Posteingang (inbox) sowie meinen Gesendeten E-Mails ins Archive. Dabei sortiert es die Mails automatisch in Unterordner mit dem Jahres und Monatsnamen, damit ich die E-Mails schneller finden kann.

Zum Beginn lief es nur als cronjob auf meinem Postfach, inzwischen sammelt es sich die Benutzer, den MailBox Pfad sowie die Option ob es laufen soll oder nicht (autoarchive=0|1) aus dem LDAP Server.

Den grundlegenden Aufruf des Skriptes möchte ich kurz mit euch teilen!

sudo -u vmboxuser cleanup-maildir --age=365 --archive-folder='Archive.Inbox' --maildir-root='/var/mail/vhosts/kernel-error.com/kernel-error' archive ''
sudo -u vmboxuser cleanup-maildir --age=365 --archive-folder='Archive.Sent' --maildir-root='/var/mail/vhosts/kernel-error.com/kernel-error' archive 'Sent/'

sudo -u vmboxuser lässt den Befehl als der Nutzer laufen, welcher bei mir übergreifen Zugriff auf die Postfächer hat.
–age=365 sagt, dass nur E-Mails älter 365 Tage angefasst werden sollen.
–archive-folder=’Archive.Inbox/Sent‘ gibt die Zielordner im Postfach an.
–maildir-root='[…]‘ das Postfach (Domain und Postfachname kommen normalerweise als Variable aus dem LDAP).
archive sagt dem Skript, dass archiviert werden soll. Man könnte auch löschen oder ähnliches.
ist der Default also die Inbox
‚Sent/‘ sind die gesendeten E-Mail.

 Die entstehende Ordnerstruktur im Postfach ist dann:

Tjo… Läuft seit Jahren sehr gut und räumt die Postfächer automatisch auf.

Outlook autodiscover für imap und smtp

Vor einigen Jahren habe ich bereits etwas zu Microsoft Outlook und dessen Autodiscover geschrieben. Microsoft Office Outlook Autodiscover

Ich setze es noch immer in recht ähnlicher Form ein und möchte den aktuellen Stand kurz beschreiben.

Primär habe ich eine Autodiscoverdomain https://autodiscover.kernel-error.de hinter dieser steht ein nginx und er liefert unter diesem Pfad https://autodiscover.kernel-error.de/Autodiscover/Autodiscover.xml die Konfigurationsinformationen für verschiedene Maildomains für smtps und imaps aus.

Die Konfiguration vom nginx ist recht überschaubar. Klar, https und der spannende Teil der Konfiguration ist folgender:

        location ~ /(?:a|A)utodiscover/(?:a|A)utodiscover.xml {
        root /usr/local/www/autodiscover.kernel-error.de;
        try_files /autodiscover/autodiscover.php =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        include fastcgi_params;
        fastcgi_cache MYAPP;
        fastcgi_cache_valid 200 60m;
    }

Wie man gut sehen kann wird einfach jede Anfrage nach /autodiscover/autodiscover.xml (egal ob am Anfang groß oder klein geschrieben), im Hintergrund weitergeleitet an das php file autodisvocer.php:

<?php

/********************************
 * Autodiscover responder
 ********************************
 * This PHP script is intended to respond to any request to http(s)://mydomain.com/autodiscover/autodiscover.xml.
 * If configured properly, it will send a spec-complient autodiscover XML response, pointing mail clients to the
 * appropriate mail services.
 * If you use MAPI or ActiveSync, stick with the Autodiscover service your mail server provides for you. But if 
 * you use POP/IMAP servers, this will provide autoconfiguration to Outlook, Apple Mail and mobile devices.
 *
 * To work properly, you'll need to set the service (sub)domains below in the settings section to the correct 
 * domain names, adjust ports and SSL.
 */

//get raw POST data so we can extract the email address
$request = file_get_contents("php://input");

// optional debug log
# file_put_contents( 'request.log', $request, FILE_APPEND );

// retrieve email address from client request
preg_match( "/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email );

// check for invalid mail, to prevent XSS
if (filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
	throw new Exception('Invalid E-Mail provided');
}

/**************************************
 *   Port and server settings below   *
 **************************************/

// IMAP settings
$imapServer = 'imap.kernel-error.de'; // imap.example.com
$imapPort   = 993;
$imapSSL    = true;

// SMTP settings
$smtpServer = 'smtp.kernel-error.de'; // smtp.example.com
$smtpPort   = 465;
$smtpSSL    = true;

//set Content-Type
header( 'Content-Type: application/xml' );
?>
<?php echo '<?xml version="1.0" encoding="utf-8" ?>'; ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
	<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
		<Account>
			<AccountType>email</AccountType>
			<Action>settings</Action>
			<Protocol>
				<Type>IMAP</Type>
				<Server><?php echo $imapServer; ?></Server>
				<Port><?php echo $imapPort; ?></Port>
				<DomainRequired>off</DomainRequired>
				<LoginName><?php echo $email[1]; ?></LoginName>
				<SPA>off</SPA>
				<SSL><?php echo $imapSSL ? 'on' : 'off'; ?></SSL>
				<AuthRequired>on</AuthRequired>
			</Protocol>
			<Protocol>
				<Type>SMTP</Type>
				<Server><?php echo $smtpServer; ?></Server>
				<Port><?php echo $smtpPort; ?></Port>
				<DomainRequired>off</DomainRequired>
				<AuthRequired>on</AuthRequired>
				<LoginName><?php echo $email[1]; ?></LoginName>
				<SPA>off</SPA>
				<SSL><?php echo $imapSSL ? 'on' : 'off'; ?></SSL>
				<AuthRequired>on</AuthRequired>
				<SMTPLast>off</SMTPLast>
				<UsePOPAuth>off</UsePOPAuth>
			</Protocol>
		</Account>
	</Response>
</Autodiscover>

Das kleine php script macht auch nicht viel mehr als die im Post übermittelte E-Mail Adresse in eine Variable zu schieben, zu prüfen ob es wirklich eine E-Mail Adresse ist und dann am Ende einfach das fertige xml zurück zu liefern.

Besonders wichtig dabei ist:

<AuthRequired>on</AuthRequired>
<SMTPLast>off</SMTPLast>
<UsePOPAuth>off</UsePOPAuth>

Sonst darf man für den Postausgangsserver nämlich immer manuell den Haken setzen bei: „Gleiche Einstellungen wie für den Posteingangsserver verwenden“ Welches sicher einige Anwender vor einer nur schwer zu überwindenden Hürde stell.

Damit dieses nicht nur für E-Mail Adresse der Domain kernel-error.de funktioniert gibt es in den anderen DNS Zonen SRV RRs welche auf diese Autodiscoverdomain verweisen:

➜  ~ dig _autodiscover._tcp.kernel-error.com IN SRV +short
0 0 443 autodiscover.kernel-error.de.

Nun sorgt dieses bei Outlook für eine kleine Warnmeldung bei der Konfiguration, ob man diesem Verweis wirklich folgen möchte.

Outlook autodiscover

Dieses kommt nur einmalig und man könnte es zudem mit deinem Registierungsschlüssel unterbinden aber naja das sollte für jeden klickbar sein, oder?!?! Im Anschluss ist die Konfiguration vom E-Mail Client schon abgeschlossen.

Outlook autodiscover

Wie man sieht ist es sehr simpel und sollte von nahezu jedem erledigt werden können, der es schafft seine E-Mail Adresse und sein Kennwort nach dem Outlookstart einzugeben.

Postfix client-initiated renegotiation deaktivieren

client-initiated renegotiation beim SMTPD Server kann für DDoS Angriffe ausgenutzt werden. Die einzelnen TLS/SSL Optionen lassen sich über die recht gleichnamige Option im Postfix ein und ausschalten. Gibt es noch keinen mappenden Namen kann die jeweilige Option auch ein/ausgeschaltet werden mit dem jeweiligen Hexwert. Genau Infos findet man hier: http://www.postfix.org/postconf.5.html#tls_ssl_options

If the value of the parameter is a hexadecimal long integer starting with "0x", the options corresponding to the bits specified in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3))

Für ein Postfix  3.3 und einem OpenSSL ab Version 1.1.1 ist der passende Hexwert 0x40000000.

Die Option setzt man wie so oft in der main.cf:

root@smtp:/ # postconf  tls_ssl_options
tls_ssl_options = 0x40000000

Ab Postfix >=3.4 gibt es: NO_RENEGOTIATION

Fragen? Dann fragen 🙂

Postfix soll verschleiern…

Um sich vor Angreifern zu schützen ist ein ganz gutes Mittel, dem Angreifer nicht direkt zu erzählen welche Software genau und in welcher Version man diese einsetzte. Bei Webservern ist dieses fast überall gängige Praxis, meist bekommt man nur noch das Produkt angezeigt. Oder wie bei einem Kollegen nur YOUR MUM. Warum ist das nun ggf. hilfreich? Ganz simples Beispiel. Man setzt einen verwundbaren Mailclient auf seinem Desktop ein, oder hat einen phpmailer (*würk*) in seiner Webseite eingebaut. Versendet man über diesen nun eine E-Mail schreibt er meist seinen eigenen Namen mit der eingesetzten Version in die E-Mail Header. Copy & Paste fertig für einen möglichen Angreifer, damit er die „Bugzilla Page“ nach den brauchbarsten Löchern durchwühlen kann. Dann muss er nur noch eine passende präparierte E-Mail schreiben und der Client wird leiden.

Ähnlich ist es mit den IP Adressen. Die IP Adresse des Clients landet ebenfalls in den Mail Headern. So hat der Angreifer schon mal eine Idee über die Netztopologie oder es gibt ihm ggf. eine Möglichkeit den Benutzer durch verschiedene Netze zu „tracken“.

Beides lässt sich über die smtp_header_checks etwas entschärfen. Über diesen Weg kann man per RegEx bestimmte Mail Header heraussuchen und löschen oder nach eigenem Ermessen ersetzten.

Hier der Eintrag für die main.cf:

root@smtp:/usr/local/etc/postfix # postconf smtp_header_checks
smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Hier das Beispiel für die /usr/local/etc/postfix/header_cleanup:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Im Ergebnis sieht es dann wie folgt aus:

[...]
Received: from ::88 (YOUR MOM [::88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.kernel-error.de (Postfix) with ESMTPSA id 7458E7B802
	for <wurst@example.com>; Wed, 27 Mar 2019 21:44:10 +0100 (CET)
[...]
X-Mailer: YOUR MOMS MAILER
[...]

Ganz wichtig ist natürlich die Frage ob dabei Signaturen gebrochen werden; das werden sie nicht. Auch DKIM usw. nicht.

Dann mal viel Spaß!

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.

DNSSEC: https://www.kernel-error.de/dnssec

DANE: https://www.kernel-error.de/dnssec/tls-ssl-zertifikatschecksummen-im-dns

Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!

Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:

$ postconf -d | grep mail_version
mail_version = 2.11.0

Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz… Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:

$ postconf -e "smtpd_use_tls = yes"
$ postconf -e "smtp_dns_support_level = dnssec"
$ postconf -e "smtp_tls_security_level = dane"

Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.

Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.

$ openssl x509 -in postfix.pem -outform DER | openssl sha256
(stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95

Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.

_25._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.

$ dig _25._tcp.smtp.kernel-error.de +dnssec +m

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A

;; AUTHORITY SECTION:
kernel-error.de.        86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                                20140102708 ; serial
                                10000      ; refresh (2 hours 46 minutes 40 seconds)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
kernel-error.de.        86400 IN RRSIG SOA 7 2 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
                                qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
                                FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
                                2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
                                rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
                                ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
                                kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE  rcvd: 506

Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.

Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses „sichere“ Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für „reiche“ zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.

Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
posttls-finger: initializing the client-side TLS engine                                                                                                                                                                          
posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95                                                       
posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25                                                                                                                                  
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"                                                                                        
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de                                                                                                                                                                                                   
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95         
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5                                                                                                                                             
posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So bei Fragen, einfach fragen 🙂


09-08-2014 Update

Ich habe zur Auswertung den Mailgraph etwas angepasst ( mailgraph Graphen um DANE erweitern ). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.

SPF Record kurz erklärt…

Ich bin in der letzten Zeit immer mal wieder zu meinem SPF Record Beispiel gefragt worden. Ihr wisst schon… Diese beiden:

kernel-error.de.    IN  TXT "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"
kernel-error.de.    IN  SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Ich versuche das ganze noch einmal etwas aufzuschlüsseln. Die genannten Beispiele sollen die Möglichkeiten zeigen, welche man hat um den SPF-RECORD zu erstellen. Der echte SPF-RECORD sollte aber so schlank wie irgendwie möglich sein. Denn er wird ja theoretisch bei jeder eingehenden E-Mail geprüft. Um so länger er ist und umso mehr geprüft werden muss umso mehr DNS Lookups müssen gemacht werden. Man hat nach RFC nur maximal 10 DNS Abfragen, eine davon hat man schon verbrannt um den eigentlichen SPF RECORD zu holen. Es bleiben also noch 9 🙂 Kommt man über diese 10 Abfragen stirbt alles mit der Meldung:
Results – PermError SPF Permanent Error: Too many DNS lookups

Ist auch OK so, denn wenn der empfangende Mailserver für jede eingehende E-Mail hunderte DNS lookups durchführen muss, tut er ja nichts anders mehr!

Gut, nun zu meinem Beispielrecord.

v=spf1 ==> Ist die Protokollversion
ip4:212.23.142.146 ==> Von dieser IPv4 Adressen dürfen E-Mails kommen.
ip6:2001:7d8:8001:100::2 ==> Von dieser IPv6 Adresse dürfen E-Mails kommen.
ptr:smtp.kernel-error.de ==> Es dürfen E-Mails von den PTR Adresse“n“ des Hosts smtp.kernel-error.de kommen.
mx ==> Es dürfen E-Mails vom MX (Mail Exchange) der Domäne kernel-error.de kommen.
a:smtp.kernel-error.de ==> Es dürfen E-Mails von den IPv4 / IPv6 Adressen des Hosts smtp.kernel-error.de kommen.
==> Kommt die E-Mail von einem -nicht zutreffenden- System gilt der SPF-Test immer als Fehlschlag
all ==> Das ganze passiert immer.

Bei den IP-Adressen kann ebenfalls ein ganzes Netz angegeben werden. Zum Beispiel: 212.23.142.146/24

Beim mx könnte eine andere Domäne oder Subdomäne stehen. Zum Beispiel: mx:smtp.kernel-error.de damit dürften dann E-Mails vom MX der Domäne smtp.kernel-error.de kommen. Natürlich muss es diesen MX auch geben!!! Es geht noch mehr… Zum Beispiel habe ich in einer weiteren Domain von mir nur folgendes stehen:
v=spf1 include:kernel-error.de -all

include:kernel-error.de ==> Gibt an das bitte der SPF RECORD von der Domain kernel-error.de abgefragt und angewandt werden soll. Damit gilt die SPF-Policy der Domain kernel-error.de. Ich muss also nur eine Policy pflegen und lasse alle anderen Domains nur auf diese verweisen 🙂

Die Abfrage würde dann so aussehen:

DNS record(s):
    vandemeer.de. 86400 IN SPF "v=spf1 include:kernel-error.de -all"
    kernel-error.de. 86400 IN SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 -all"

Würde man nun den oben stehenden RECORD in die Zone kernel-error.de. werfen und ihn aktiv nutzen; Dann wird er funktionieren und absolut gültig sein. Das empfangende E-Mail System wird aber eine ganz Hand voll DNS Abfragen machen müssen um diese SPF Policy zu prüfen. Jetzt beantwortet sich sicher die Frage, warum ich einen anderen SPF-RECORD einsetzte als hier aufgeführt 😀 Denn die aufgeführten RECORDS sind schlicht ein Beispiel und keine Copy & Paste Vorlagen. Ok ok… Ich hätte das direkt genauer beschreiben sollen, hm?

Weniger ist im SPF RECORD also mehr. Man darf sich also überlegen welcher RECORD für seine Domain und sein System gerade der beste ist. Wenn es wechselnde IP Adresse gibt ist sicher ein A/AAAA RECORD besser, wenn sich dieser oft ändert dann ggf. ein MX der Domain oder ein ganzes Netz oder oder…

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Habt ihr eigentlich schon etwas von DMARC (Domain-based Message Authentication, Reporting & Conformance) gehört? Nein… Dann dann haben wir das ja nun aufgeholt 😛

Im Grunde „erweitert“ DMARC die beiden Systeme SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail). Warum und wie?!? Nun ja, beide Techniken sind erstmal ~nicht schlecht~. Setzt man sie ausgehend ein, fehlen dem Admin denn noch etwas die „Rückmeldungen“. OK, wenn etwas schief geht, jammern die User. Setzt man sie eingehend ein, würde es hin und wieder helfen wenn der „Absender“ einem etwas genauer sagen würde wie denn nun mit seinen Nachrichten umgegangen werden soll.

Hier springt nun DMAC -in die Bresche- (woher kommt eigentlich diese Redensart?). DMARC wird, wie bei SPF oder DKMI möglich, einfach als TXT-RECORD in der DNS Zone versenkt. Dort finden sich nun Informationen für den empfangenden Mailserver. Zum Beispiel kann angegeben werden wie viel Prozent der eingehenden E-Mails überhaupt gefiltert werden soll (pct), wie hart bei Fehlern im SPF (aspf) und DKIM (adkim) umgegangen werden soll, wie mit E-Mails der Haupt- (p) oder Subdomänen (sp) umgegangen werden soll und was tierisch geil für den Admin des Absendenden E-Mail Systems ist…. An welche E-Mail Adresse ein forensischer (das Wort trifft es, ich finde es aber doof :-P) Bericht (ruf) und wohin eine tägliche Zusammenfassung (rua) gesendet werden soll.

Diese Berichte schlagen normalerweise als E-Mail mit einem komprimierten ZIP-File im Gebäck auf. In diesem ZIP-File steckt dann ein XML-File (*würk* XML.. für die Auswertung denn noch geil). Diese kann man nun auswerten. So kann der Admin des absendenden E-Mail Systems sehen wie gut oder schlecht seine Bemühungen greifen. Er wird schnell über Probleme informiert und kann erkennen ob und wie stark seine Domain gerade -missbraucht- wird.

Eine E-Mail mit ZIP-File lässt sich sehr einfach automatisch auspacken und die XML Datei wird dann von irgendeinem Stück Software gefressen. Heraus kommt ein täglicher Bericht für den Admin. Ok, man könnte es schön bunt machen, dann kann man es auch einer Krawatte zum klicken geben 🙂

Klar muss der Empfänger es unterstützen, sonst bringt das alles nix. Aber jeder Absender, der bereits SPF und DKIM einsetzt, kann seinen DMARC Record schon mal erstellen, hm?

Ich probiere eine kurze Erklärung des DMARC TXT RECORDS an meinem…

_dmarc.kernel-error.de  IN TXT  "v=DMARC1; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de; adkim=s; aspf=s; p=quarantine; sp=quarantine"

_dmarc. ==> ist halt der „Bezeichner“
kernel-error.de ==> japp die Domain
IN TXT ==> Internet und Text
„“ ==> Dazwischen ist der Text
; ==> Trennt die Optionen
v=DMARC1 ==> Protokollversion, hier also 1
pct=100 ==> 100% meiner vermeintlichen Nachrichten sollen gefiltert werden
rua=mailto:postmaster@kernel-error.de ==> Zusammenfassung geht an postmaster@kernel-error.de
ruf=… ==> der forensiche Bericht geht ebenfalls an den Postmaster
adkim=s ==> DKIM soll nicht relaxed (r) sondern strict (s) ausgewertet werden
aspf=s ==> auch strict
p=quarantine ==> Fehlgeschlagenes der Hauptdomäne sollen als SPAM markiert werden.
sp=quarantine ==> bei der Subdomäne auch.

Noch eine Kleinigkeit. Wenn man mehrere Domains betreut und die Berichte an eine zentrale E-Mail Adresse senden möchte dann muss man noch etwas beachten. Denn sollen die Berichte an eine E-Mail Adresse außerhalb der Domain des DMARC RECORDS gesendet werden, dann muss dieses in der Empfängerdomäne „erlaubt“ werden. Dieses geht über einen gesonderten TXT RECORD.

kernel-error.com._report._dmarc.kernel-error.de TXT "v=DMARC1"

Wenn man diesen RECORD als Beispiel nimmt, würde er in der Zone kernel-error.DE stehen. Damit würden die Berichte aus der Zone kernel-error.COM an die Adresse xyz@kernel-error.de zugestellt werden können.

Noch Fragen? Na dann fragen 😀


UPDATE 12.12.2013

Ok ok… da die Frage jetzt ein paar mal aufgekommen ist, wie ein solcher Report aussieht…. Hier ein Beispiel: >> klick <<

Zur besseren Ansicht kann ich auch hier nur wieder auf dmarcian.com verlinken. Hier gibt es einen XML du Human Konverter 🙂 

Frage beantwortet?

Microsoft Office Outlook Autodiscover

Benutzer sind, wie der Name schon treffend beschreibt, Menschen welche etwas benutzen. Dieses bedeutet nicht dass sie es verstehen oder gar „montieren“ können. Sie möchten es einfach nur benutzen und dieses sollen sie auch.

Betreibt man einen Mailserver und verteilt Postfächer an seine Benutzer, kommt man extrem schnell an den Punkt dass die Benutzer ihre Postfächer nutzen wollen 😛 Sie möchten ihr neues Postfach in ihren E-Mail Client (wir sagen MUA) einbinden. Nur wie?!?

Ja klar nun kann man bebilderte Anleitungen oder besser noch Anleitungsvideos anfertigen und diese seinen Benutzer zugänglich machen. Sehr oft muss denn noch am Ende jemand das Postfach einbinden oder es wird nach einer Fehlerdiagnose festgestellt dass der Benutzer keine E-Mails versenden kann, weil er sich nicht am Postausgangsserver anmeldet. Einfacher wäre es doch, wenn sich der MUA selbst konfigurieren würde, oder? ADS Mitglieder welche von einem Exchangeserver bedient werden, kennen die Luxusversion… Kunden der großen Freemailer wie GMX, Google, Yahoo usw. kennen es ebenso. Diese geben in ihrem MUA nämlich maximal 3 Dinge an. Ihren Namen, E-Mail Adresse und das Kennwort. Also alles Dinge die ein normaler Benutzer angeben können sollte.

Wie läuft diese automatische Konfiguration nun bei Microsoft Outlook ab? Nun, da es eine ganze Latte an Möglichkeiten gibt Outlook die Konfiguration unter zu schieben, fragt Outlook diese ganz brav der Reihe nach ab. Bekommt er von einer der Stellen eine Konfiguration probiert Outlook diese aus. Klappt alles, ist die Einrichtung fertig, klappt etwas nicht, geht es in der Liste weiter. Ich fasse mal kurz zusammen:

1 – Ist der Computer Mitglied einer Domäne, wird die E-Mail Adresse vom Active Directory abgerufen.

2 – Der DNS Name des Exchangeservers wird abgerufen.

3 – SCP (Service Connection Point) Suche und Suche nach dem passenden AutoConfig Servers. Dann mit diesen Daten eine Verbindung herstellen. Fertig….

4 – Klappt dieses nicht, wird versucht im DNS einige Domainnamen aufzulösen und dort nach einer autodiscover.xml XML-Datei gesucht.
Gesucht wird dabei hier:
a. https://ads-domäne/autodiscover/autodiscover.xml
b. https://autodiscover.example.org/autodiscover/autodiscover.xml
c. http://autodiscover.ads-domäne/autodiscover.xml
d. DNS SRV-RECORD: _autodiscover._tcp.ads-domäne/examle.org

5 – Klappt dieses auch nicht, wird versucht auf dem Rechner eine XML Datei zu finden.

6 – Klappt dieses wieder nicht, es aber ein Exchange Server (Punkt 2) gefunden wurde, wird der manuelle Konfigurations-Wizard  für Exchangeserver aufgerufen.

7 – Wurde kein Exchange Server gefunden dann wir der einfache Konfigurations-Wizard aufgerufen.

Möchte man nun seinen Outlook Client automatisch alle nötigen Einstellungen für die Konfiguration seines Postfix / Dovecot-IMAP Servers finden lassen, klappt dieses wie folgt:

Wir haken einfach an punkt 4-b. ein. Wir sorgen also dafür dass es den Domainnamen autodiscover.example.org gibt oder halt ein passender SRV-RECORD vorhanden ist und dass dieser auf einen Webserver zeigt, welcher sich zuständig fühlt. Wenn wir nun noch dafür sorgen dass Outlook dort auch die XML-Datei autodiscover/autodiscover.xml abrufen kann sind wir schon ganz weit vorne 🙂

Zu beachten ist aber dass Outlook die Konfigurationsdatei nur dann abruft, wenn diese per https (SSL) zugänglich ist. Beim SRV-RECORD muss man wissen dass Outlook es als „Umleitung“ behandelt. Beim SRV-RECORD und bei allen anderen Umleitungen wird Outlook also ein kleines Fenster öffnen und den Benutzer fragen ob er wirklich dieser Umleitung zur Konfiguration folgen will oder nicht. Ist das SSL-Zertifikat für Outlook nicht gültig, wirft Outlook natürlich ebenfalls Meldungen raus.

Angenommen wir haben also die E-Mail Adresse: test@example.org

Outlook wird geöffnet, der Wizard geht auf und Fragt was für ein Konto wir einrichten wollen. Dann würfelt der Benutzer seinen Namen, seine E-Mail Adresse (test@example.org) und sein Kennwort in den Wizard. Nun geht Outlook seine Testliste durch und sieht das es die Domain: autodiscover.example.org (japp hier greift Outlook immer auf den Domainteil der E-Mail Adresse zurück) gibt. Nun macht Outlook einen HTTP/HTTPS-POST an die Adresse https://autodiscover.example.org/autodiscover/autodiscover.xml in diesem Post übermittelt Outlook unter anderem die vom Benutzer eingegebene E-Mail Adresse (das wird uns später noch helfen!). Als HTTPS Antwort erwartet Outlook nun die autodiscover.xml mit der zu nutzenden Konfiguration.

Alles geil, oder? Na ja fast… Outlook wird nämlich als Anmeldename per Default den Teil der E-Mail Adresse vor dem @ nutzen. In diesem Fall also test. Müssen sich Benutzer mit der kompletten E-Mail Adresse anmelden, hat man nun ein Problem. Es gibt in der XML Beschreibung zwar die Möglichkeit einen <LoginName> zu setzten. Dieser wäre aber statisch. Sprich man kann hier nicht einfach eine Variable wie %e-mailadresse% einsetzten. Nun können wir uns denn noch den POST zunutze machen. Denn hier wird dem Webserver ja die E-Mailadresse (also der Benutzername) mitgeteilt. Ein php://input könnte also die Welt retten.

Jaaaa nun klingelt es schon bei einigen, richtig? Genau… Die Datei: autodiscover/autodiscover.xml ist in Wirklichkeit die Datei: autodiscover/autodiscover.xml.php. In der Konfiguration des VirtualHosts im Apache wird nur ein Alias gesetzt: Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php Damit unser Apache bei der Outlookfrage nach autodiscover.xml bei einem PHP-Script landet. Dieses fischt alle nötigen Informationen ab und bereitet sie entsprechend für Outlook auf.

Perfekte Arbeit für dieses Script hat bereits David Ramsden geleistet. Sein Original ist hier zu finden: http://0wned.it/geek-bits/scripts/open-source-autodiscover-implementation-in-php/

Ich habe sein Script nur für meine Zwecke etwas angepasst.

>>Meine XML-Autodiscover Konfigurationsdatei<<

Ich hoffe dieses kann dem einen oder anderen etwas helfen diesen AutoErmittlungsdienst zu verstehen. Bei Fragen, einfach eine E-Mail schicken 🙂


So nebenbei… Der Microsoft Lync 2013 Client sammelt über den A-RECORD autodiscover.example.org den Weg zum Exchangeserver ein. So kommt dieser auch an die Interne EWS-URL und die Externe EWS-URL.

Der Lync Client benötigt also für jede SMTP-Domäne zwei DNS RECORDS:

autodiscover IN CNAME exchangeserver.example.org.
_autodiscover._tcp IN SRV 0 0 443 exchangeserver.example.org.

Ich muss beim Thema Microsoft Lync aber die Hände heben. Ich kenne hier aber jemanden an den ich Anfragen weiterleiten könnte 🙂


Mangels freier IPv4 Adressen, ist https://autodiscover.kernel-error.de/autodiscover/autodiscover.xml aktuell nur per IPv6 erreichbar. Sicher kein Problem für euch, oder? 😀

Zertifikat angepasst und per SNI passen eingebunden. So alte Clients haben dann also Pech! 😀 Als kleine Tipp für die eigenen Tests, ein kleines Tool von Microsoft selbst:

https://testconnectivity.microsoft.com/

Dort müsste der Exchange ActiveSync Autodiscover alle eure Wünsche erfüllen können!


Auf mehrfachen Wunsch, hier nun noch einmal die autodiscover.php als copy & paste Version:

<?
/*
 Open Source Autodiscover implementation in PHP.
 
 Version: 1.0
 Tested with:
        - Microsoft Exchange Remote Connectivity Analyzer (1.3)
        - iOS 4.3.5
        - Outlook 2010 (SP0)
        - Android 2.3.3
 
 Allows auto configuration of ActiveSync and Outlook (or any other MUA that has
 autodiscover support).
 
 Example Apache vhost configuration (SSL is required for Autodiscover):
 
        <VirtualHost 1.2.3.4:443>
                ServerName autodiscover.domain.com
                ServerAdmin webmaster@domain.com
 
                SSLEngine on
                SSLCertificateFile      /etc/apache/ssl/certs/apache.domain.com.crt
                SSLCertificateKeyFile   /etc/apache/ssl/private/apache.domain.com.key
 
                # Force all requests to lowercase. Different MUAs, mobile devices etc
                # request the Autodiscover URL in different cases.
                RewriteEngine On
                RewriteMap lc int:tolower
                RewriteCond %{REQUEST_URI} [A-Z]
                RewriteRule (.*) ${lc:$1} [R=301,L]
 
                DocumentRoot /var/www/autodiscover/htdocs
                <Directory />
                        Options +FollowSymLinks -Indexes
                        AllowOverride Options Indexes Limit FileInfo AuthConfig
                </Directory>
 
                 Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php
 
                ErrorLog /var/www/autodiscover/logs/error.log
                CustomLog /var/www/autodiscover/logs/access.log combined
        </VirtualHost>
 
 
------------------------------------------------------------------------------
  Copyright (C) 2011 David Ramsden
 
  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.
 
  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:
 
  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.
 
  David Ramsden david {at} 0wned {dot} it
------------------------------------------------------------------------------
*/
// For other supported protocols and more protocol settings, see:
//  http://technet.microsoft.com/en-us/library/cc511507.aspx
 
// Get contents of request made to Autodiscover.
$request = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email_address);



 
/*** Begin Configuration ***/
// ActiveSync URL.
$_CONFIG['MobileSync']['Url'] = "https://www.kernel-error.de/Microsoft-Server-ActiveSync";


 
// IMAP configuration settings.
$_CONFIG['IMAP']['Server'] = "imap.kernel-error.de";
$_CONFIG['IMAP']['Port'] = "993";
$_CONFIG['IMAP']['SSL'] = "on";
$_CONFIG['IMAP']['SPA'] = "off";
$_CONFIG['IMAP']['AuthRequired'] = "on";
$_CONFIG['IMAP']['LoginName'] = $email_address[1];
 
// SMTP configuration settings.
$_CONFIG['SMTP']['Server'] = "smtp.kernel-error.de";
$_CONFIG['SMTP']['Port'] = "465";
$_CONFIG['SMTP']['SSL'] = "on";
$_CONFIG['SMTP']['SPA'] = "off";
$_CONFIG['SMTP']['AuthRequired'] = "on";
$_CONFIG['SMTP']['LoginName'] = $email_address[1];
/*** End Configuration ***/
 

 
// XML document heading.
header("Content-Type: text/xml");
echo "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
 
// Get the schema from the request.
preg_match("/\<AcceptableResponseSchema\>(.*?)\<\/AcceptableResponseSchema\>/", $request, $schema);
// Determine the type of device requesting Autodiscover.
if (preg_match("/\/mobilesync\//", $schema[1]))
{
        // Mobile device.
        preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email_address);
        ?>
                <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
                        <Response xmlns="<? echo $schema[1]; ?>">
                                <Culture>en:en</Culture>
                                <User>
                                        <DisplayName><? echo $email_address[1]; ?></DisplayName>
                                        <EMailAddress><? echo $email_address[1]; ?></EMailAddress>
                                </User>
                                <Action>
                                        <Settings>
                                                <Server>
                                                        <Type>MobileSync</Type>
                                                        <Url><? echo $_CONFIG['MobileSync']['Url']; ?></Url>
                                                        <Name><? echo $_CONFIG['MobileSync']['Url']; ?></Name>
                                                </Server>
                                        </Settings>
                                </Action>
                        </Response>
                </Autodiscover>
        <?
}
else if (preg_match("/\/outlook\//", $schema[1]))
{
        // MUA (mail client).
        ?>
                <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
                        <Response xmlns="<? echo $schema[1]; ?>">
                                <Account>
                                        <AccountType>email</AccountType>
                                        <Action>settings</Action>
                                <?
                                        // Loop through each configured protocol.
                                        while(list($protocol, $settings) = each($_CONFIG))
                                        {
                                                // Skip ActiveSync protocol.
                                                if ($protocol == "MobileSync") continue;
                                        ?>
                                                <Protocol>
                                                        <Type><? echo $protocol; ?></Type>
                                        <?
                                                // Loop through each setting for this protocol.
                                                while(list($setting, $value) = each($settings))
                                                {
                                                        echo "\t\t\t\t\t\t\t<$setting>$value</$setting>\n";
                                                }
                                        ?>
                                                </Protocol>
                                        <?
                                        }
                                ?>
                                </Account>
                        </Response>
                </Autodiscover>
        <?
}
else
{
        // Unknown.
        list($usec, $sec) = explode(' ', microtime());
        ?>
                <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
                        <Response>
                                <Error Time="<? echo date('H:i:s', $sec) . substr($usec, 0, strlen($usec) - 2); ?>" Id="2477272013">
                                        <ErrorCode>600</ErrorCode>
                                        <Message>Invalid Request</Message>
                                        <DebugData />
                                </Error>
                        </Response>
                </Autodiscover>
        <?
}
?>

SPF Records

Es gibt seit einiger Zeit einen dedizierten SPF-Record. Dieser wird auch bereits von vielen SPF-Filtern sowie Bind seit Version 9.4 unterstützt. Dieses entlastet etwas die TXT Anfragen und sorgt für mehr Ordnung 🙂 Wird dieser SPF Record vom jeweiligen SPF Filter unterstützt, fragt dieser meist zuerst nach dem SPF-Record und wenn es keine Antwort gibt als nächstes nach einem TXT-SPF Record.

Um diesen Filtern etwas Arbeit zu ersparen, das DNS etwas aufzuräumen und auf lange Sicht RFC konform zu bleiben (es würde mich nicht wundern wenn der TXT-SPF Record bald ausstirbt). Sollte man ebenfalls bei seiner SPF geschützten Domain einen solchen Record erstellen.

Für meinen Bind und die Domain kernel-error.de würde ein Beispiel wie folgt aussehen:

kernel-error.de.    IN    SPF    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

Geprüft werden kann alles schnell und einfach mit DIG:

# dig kernel-error.de IN SPF +short
"v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

Sobald alle gängigen Filter die SPF-Records implementiert haben und alle Postmaster ihre Einführungszeit hatten, kann man dann sicher seinen TXT-SPF-Record entfernen. Dieses dauert sicher wieder ein paar Jahre! Ach ja, mein TXT SPF Record schaut so aus:

kernel-error.de.    IN    TXT    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

 

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

« Ältere Beiträge

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑