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.
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 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.
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.
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:
Nun sorgt dieses bei Outlook für eine kleine Warnmeldung bei der Konfiguration, ob man diesem Verweis wirklich folgen möchte.
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.
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.
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.
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.
[...]
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.
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.
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:
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.
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.
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.
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…
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. ==> 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.
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 🙂
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.
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.
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 🙂
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:
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>
<?
}
?>
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:
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"
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Dauer
Beschreibung
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Dauer
Beschreibung
CONSENT
16 years 3 months 22 days 14 hours
These cookies are set via embedded youtube-videos. They register anonymous statistical data on for example how many times the video is displayed and what settings are used for playback.No sensitive data is collected unless you log in to your google account, in that case your choices are linked with your account, for example if you click “like” on a video.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Dauer
Beschreibung
yt-remote-connected-devices
never
These cookies are set via embedded youtube-videos.
yt-remote-device-id
never
These cookies are set via embedded youtube-videos.