Datenhaufen zu IT und Elektronik.

Schlagwort: E-Mail (Seite 2 von 2)

Outlook Autodiscover für IMAP/SMTP: Automatische Kontoeinrichtung​

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

Die vergessenen abuse und postmaster Adressen

Was oft übersehen wird, ist dass es für jede Domain die Adressen postmaster@domain.tld sowie abuse@domain.tld geben muss. E-Mails an diese Adressen müssen angenommen werden und sollten auch gelesen werden!

 

Geregelt ist dieses im RFC5321 und im RFC2142 (ich verlinke hier mal auf http://www.rfc-ignorant.org , die haben es schön bunt gemacht, das ist ja für viele so wichtig)!

 

Hat man nun technische Fragen zum Mailsystem einer Domain, oder technische Anmerkungen, dann sendet man eine E-Mail an: postmaster@domain.tld
Im schlechtesten Fall sollte dort ein Mensch sitzen welcher in der Lage ist, diese E-Mail an den „echten“ Administrator weiter zu leiten.

 

Jetzt kommen immer mal wieder ~Beschwerden~ bei mir an, weil E-Mails Externer an gehostete Domains abgewiesen werden. Also macht man sich auf die Suche nach dem Grund. Der eigentliche Absender hat diesen zwar mit einer 5xx Meldung zusammen bekommen…. Die Nachricht war aber leider auf Englisch und Fehlermeldungen – vor allem in englischer Sprache – werden gerne und schnell gelöscht! Hat man den Grund also gefunden, schreibt man den Grund an den „Beschwerdeführer“ und natürlich den Postmaster der Absenderdomain. Das die E-Mail abgewiesen wurde weil sie auf eine Blockliste steht, der R-DNS nicht stimmt, alles von einer dynamischen IP kommt usw. usw…. Sehr oft hat man dann 4 – 5 Sekunden nach dem Absenden der E-Mail auch schon eine Antwort: – Sorry, Postfach nicht gefunden. / – Mailbox voll.
Es hängt ja mal schnell zusammen 😛

 

Eine E-Mail an die Abuse Adresse schreibt man immer, wenn auf einen Missbrauch hingewiesen werden soll. Wird also die Domain zum verschleudern von Spam und Viren missbraucht oder ähnliches. Eine Abuse Adresse findet sich auch im Whois der meisten IP Adressen/Netze. Sie erfüllt hier den gleichen Auftrag. Man sollte denn noch folgendes beachten. Wird eine Domain als Absender einer Spam oder Virenmail missbraucht und dieses läuft nicht über den Mailserver der Domain… Dann sind die Verantwortlichen der Domain in gewissem Umfang machtlos. Zwar kann man versuchen sich gegen so etwas mit Techniken wie SPF zu schützten. Dieses muss denn noch beim Empfänger ausgewertet werden.

 

Nun reicht es nicht nur die beiden Adressen postmaster@domain.tld sowie abuse@domain.tld anzulegen. Sondern die Absender sollten diese Adressen erreichen können. Hat jemand also ein Problem damit E-Mails an unsere Domain zu schicken, da sie immer von irgendwelchen Filtern abgewiesen wird, dann versucht er ggf. sich an den Postmaster der Domain zu wenden. Wird diese E-Mail nun ebenfalls gefiltert – dann hat der Absender verloren?!?! So könnte den Postmaster ein Hinweis auf ein echtes Problem mit seinem Mailsystem nicht erreichen. Das wäre schlecht, diese Adressen sollten also unabhängig von den Filtern immer durchgelassen werden.

 

Dieses geht über Whitelisting des jeweiligen Empfängers im Postfix und AMaViS. Denn Postfix sowie AMaViS dürfen ihre Filter nicht auf E-Mails an diesen Empfänger anwenden.

 

Hier nun ein kleines Beispiel dazu:

Postfix access-Tables

Für eine einfache Konfiguration erstellt man am einfachsten die Datei recipient-access unter /etc/postfix, der Inhalt besteht dann aus den jeweiligen Empfängeradressen und der Information was damit gesehen soll.

$ cat /etc/postfix/recipient-access
#Empfänger
postmaster@kernel-error.de    OK
abuse@kernel-error.de        OK

OK ist dabei immer erlauben

REJECT lehnt immer mit einem Error 5xx ab
In der Version 2.0 von Postfix wurde dieses Thema komplett überarbeitet. Es gibt noch viele weitere Möglichkeiten der access-tables. Hier einfach mal RTFM oder fragen.

Damit Postfix am Ende mit den Daten etwas anfangen kann fehlt noch ein:

$ postmap /etc/postfix/recipient-access

 Als letzten Schritt weisst man nun Postfix an, diese Daten auch auszuwerten. Dabei ist die Stelle ganz wichtig! Warum? Ganz einfach… Postfix hat die Möglichkeit verschiedene Filter an verschiedenen Stellen des Ablaufes zu nutzen. Die Filter werden immer von oben nach unten abgearbeitet und sobald einer passt, greift auch dieser. Sehr ähnlich wie bei einer Firewall.

So lassen sich Prüfungen an folgenden Stellen konfigurieren:

smtpd_client_restictions
nach connect

smtpd_helo_restrictions
nach helo

smtpd_sender_restrictions
nach mail from

smtpd_recipient_restrictions
nach rcpt to

smtpd_data_restrictions
nach data

smtpd_end_of_data_restrictions
nach mailübertragung

Ein solches Vorgehen ergibt schnell einen Sinn, wenn man darüber nachdenkt, wie man Last von seinem Mailserver fernhalten kann. Erwartet man zum Beispiel im HELO einen fqdm, kann man dieses direkt nach dem HELO prüfen (smtpd_helo_restrictions) und die Verbindung ggf. ablehnen. Der Mailserver nimmt also nicht noch dem Absender, den Empfänger oder gar die ganze E-Mail entgegen, bevor die Verbindung zurückgesetzt wird. Für einfache Systeme reicht es meist seine Prüfungen nach der Übergabe des Empfängers (smtpd_recipient_restrictions) zu setzten. Erst ganz am Ende (smtpd_end_of_data_restrictions) zu prüfen halte ich für gefährlich. Zwar sollte dieses Vorgehen kleinere Mailsysteme nicht weiter stressen… Denn noch hat man ja schon die komplette E-Mail angenommen, bevor man etwas damit tut. Rechtlich sicherer wäre es die Nachricht abzulehnen, noch bevor sie ganz übertragen ist.

Ich trage daher soweit oben wie möglich meine Whitliste ein:

/etc/postfix/main.cf

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        ...........,

Nachdem Postfix die neuen Einstellungen übernommen hat, greifen alle nachfolgenden Filter nicht mehr auf alle Empfänger mit einem OK in der /etc/postfix/recipient-access.

AMaViS spam_lovers_maps

Postfix lässt nun zwar die E-Mails durch, AMaViS wird sie denn noch grillen. Es sei denn wir sagen AMaViS dass diese Empfänger Spam Liebhaber sind 🙂

Folgender Eintrag in /etc/amavis/conf.d/50-user erfüllt dieses:

@spam_lovers_maps = (
  [
        "postmaster\@kernel-error.de",
        "abuse\@kernel-error.de",
  ]
  );

 

AMaViS testet die E-Mail nun zwar noch immer, sie wird denn noch druchgewunken. Nun gibt es nicht nur Spam Liebhaber „spam_lovers_maps“ sondern auch Viren Liebhaber „virus_lovers_maps“ oder Liebhaber gesperrter/verdächtiger Dateianhänge „banned_files_lovers_maps„. Mir kommt nur gerade kein Grund in den Sinn, warum man dem Postmaster einen „verdächtigen“ Dateianhang oder gar einen Virus schicken sollte. Daher fische ich in der Regel diese E-Mails weiterhin raus. Nur Werbung lasse ich für diese beiden Adressen passieren. So sollten mich alle E-Mails an Postmaster oder Abuse erreichen. Selbst wenn sie von einem falschen Absender per Telnet über eine dynamische und gesperrte Adresse versucht mir Viagra zu verkaufen *schnief*.

DKIM

Ich gehe davon aus, das eine funktionsfähige amavis, postfix usw… Konstellation vorhanden ist!

Ich habe einen Server im Internet stehen, welcher sich um meine E-Mails und die meiner Verwanden und Bekannten kümmert. Hier liegen mehrere Domains und die E-Mails in lokalen Postfächern. Diese sind per smtp, imap und webmail zu erreichen.

OS ist Debian Lenny, als MTA nutze ich Postfix welcher mit amavis, spamassassin, clamav, dovecot und etwas Krims mehr zusammenarbeitet.

Meine Idee war nun alle ausgehenden E-Mails jeweils mit DKIM zu signieren und alle eingehenden E-Mails zusätzlich auf eine gültige DKIM Signatur zu prüfen.

Es gibt hier nun mehrere Möglichkeiten dieses umzusetzen. Ich habe mehrere Systeme ausprobiert und finde, für mich ist es über amavis am angenehmsten. Seit der Version 2.6 bringt amavis-new diese Funktionalität mit. Na dann wollen wir mal….

Vorbereitung der Signaturprüfung

Ich habe folgende Einträge in meiner 50-user unter /etc/amavis/conf.d/ dafür ergänzt:

$enable_dkim_verification = 1;

Damit überreden wir amavis die DKIM Signaturen zu prüfen. Dieses läuft in Zusammenarbeit mit spamassassin. Hier müssen folgende Einträge vorgenommen werden:

/etc/spamassassin/v320.pre
loadplugin Mail::SpamAssassin::Plugin::DKIM

Ohne diesen Eintrag wird spamassassin nicht das passende Modul laden und versteht überhaupt nicht was man von ihm will (häufige Fehlerquelle).

/etc/spamassassin/local.cf
#DKIM
score DKIM_VERIFIED -3.0
score DKIM_POLICY_TESTING 0
score USER_IN_DKIM_WHITELIST -8.0
whitelist_from_dkim @kernel-error.de

Hier lege ich nun die Punkte fest, welche von spamassassin vergeben werden. Da natürlich auch Spammer eine DKIM Signatur erstellen könnten (was eher selten ist) gebe ich maximal -3 Punkte für eine erfolgreich geprüfte DKIM Signatur.

Es fehlt nur noch ein Paket: libmail-dkim-perl
Dieses installieren wir einfach schnell mit

apt-get install libmail-dkim-perl

nach!

Ab jetzt werden E-Mails schon auf eine gültige DKIM Signatur überprüft.

Ich werfe, nach einiger Zeit, mal ein: cat /var/log/mail.log|grep dkim_id raus um zu sehen ob schon etwas passiert ist:

Mar 11 10:59:56 kernel-error amavis[10736]: (10736-05) Passed CLEAN, [91.194.xxx.xxx] [91.194.xxx.xxx] <e3@xxxxx.net> -> <xxx@xxx-meckenheim.de>, Message-ID: <0.0.10@e3xxys.net>, mail_id: Cf, Hits: -9.187, size: 33396, queued_as: 6883, dkim_id=eBay@reply.ebay.de,eBay@reply.ebay.de, 6951 ms

Schaut gut aus und im MailHeader dieser E-Mail steht:

Authentication-Results: kernel-error.de (amavisd-new); dkim=pass
header.i=eBay@reply.ebay.de
Authentication-Results: kernel-error.de (amavisd-new); domainkeys=pass

Das geht also schon mal 😀

Vorbereitung der Signierung

In /etc/amavis/conf.d/50-user müssen folgende Konfigurationszeilen eingefügt werden:

$enable_dkim_signing = 1;
dkim_key('kernel-error.de', 'kernel-error', '/pfad/kernel-error.key.pem');
@dkim_signature_options_bysender_maps = (
{ '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );
@mynetworks = qw(127.0.0.0/8);  # list your internal networks

Zeile 1 bringt amavis dazu E-Mails per DKIM zu signieren.
Zeile 2 sagt amavis wo für die jeweilige Domain (hier kernel-error.de) die Schlüsseldatei liegt.
Zeile 3 gibt vor wie und was signiert werden soll.
Zeile 4 gibt an, welche IP-Netze als lokal behandelt werden sollen. Da dieser Server bei uns im Rechenzentrum steht gibt es kein lokales Netzwerk, bis auf 127…

Jetzt müssen wir noch den Schlüssel erstellen. amavis hilft dabei mit folgendem Befehl:

amavisd-new genrsa /pfad/kernel-error.key.pem

Wir können uns den Schlüssel anschauen und direkt Testen ob amavis alles richtig verstanden hat, mit Hilfe dieses Befehls:

amavisd-new showkeys

Die Ausgabe sollte ähnlich dieser sein:

kernel-error._domainkey.kernel-error.de.        3600 TXT (
"v=DKIM1; p="
"MIGfMCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC/KYIHw8NZNIB"
"SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS6orDC2DzZ7"
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
"qZZZZZZZZZZZZZZZZZZZZZZZZB")

Genau diesen Schlüssel müssen wir nun in den DNS-Eintrag des DNS-Servers eintragen, welcher für die Domain zuständig ist. Der DNS-Server meiner Domain ist ein Bind9. Um diesem meinen Schlüssel schmackhaft zu machen, muss ich ihn noch etwas umformen. Er wird am Ende so ausschauen:

kernel-error._domainkey.kernel-error.de.        3600 TXT  "v=DKIM1; p="MIGfMCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC/KYIHw8NZNIBSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS6orDC2DzZ7XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXqZZZZZZZZZZZZZZZZZZZZZZZZB"

Ich habe alle Zeilenumbrüche und ~überfüssige~ ( „ ) sowie die beiden Klammern entfernt. Der Eintrag im Bind schaut nun also so aus:

$ORIGIN .
$TTL 86400      ; 1 day
kernel-error.de         IN SOA  kernel-error.de. root.kernel-error.de. (
xxxxxxxxx ; serial
10000      ; refresh (2 hours 46 minutes 40 seconds)
1800       ; retry (30 minutes)
2419200    ; expire (4 weeks)
86400      ; minimum (1 day)
)
NS      ns1.kernel-error.de.
NS      ns2.kernel-error.org.
A       213.xx.xx.xx
MX      10 smtp.kernel-error.de.

kernel-error._domainkey.kernel-error.de.        3600 TXT  "v=DKIM1; p="MIGfMCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC/KYIHw8NZNIBSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS6orDC2DzZ7XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXqZZZZZZZZZZZZZZZZZZZZZZZZB"


$ORIGIN kernel-error.de.
$TTL 300        ; 5 minutes
imap                    A       213.xx.xx.xx
smtp                    A       213.xx.xx.xx

Ein amavisd-new testkeys sollte nun folgendes ergeben:


TESTING: kernel-error._domainkey.kernel-error.de => pass

Ab jetzt werden alle lokalen E-Mails signiert! Hier ist darauf zu achten, dass nur E-Mails signiert werden, welche als lokal eingestuft werden. Wir erinnern uns daran, dass wir 127.0.0.0/8 als lokales Netzwerk eingestuft haben. Wenn also nun E-Mails von Benutzern signiert werden sollen, welche sich mit ihrem E-Mail Client per smtp am Server anmelden und E-Mails verschicken, dann ist noch etwas mehr Arbeit nötig!

Am einfachsten ist es mit zwei verschiedenen IP-Adressen zu arbeiten und für diese Spezielle Regeln anzulegen. Dazu müssen ein paar Einträge in der /etc/postfix/master.cf vorgenommen werden:

213.xx.xx.xx:smtp      inet  n       -       -       -       -       smtpd 
127.0.0.1:10025 inet n  -       -     -       -  smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o local_header_rewrite_clients=

Ist hier mein Eintrag für E-Mails, welche über den MX Eintrag an meinen Mailserver gesendet werden, also für die Domains und User bestimmt sein sollten, welche ich über meinen Mailserver verarbeite. Die User sollten über diese Adresse keine E-Mails einliefen!!

### Einlieferung eigene Nutzer
213.xx.xx.xxx:smtp      inet  n       -       y       -       100     smtpd
-o smtpd_proxy_filter=localhost:10028
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=
213.xx.xx.xxx:smtps    inet  n       -       y       -       100       smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_wrappermode=yes
-o smtpd_proxy_filter=localhost:10028
-o smtpd_sasl_auth_enable=yes
-o content_filter=

Dieses sind nun meine Einträge für die zweite IP-Adresse. Über welche die User, welche sich per sasl anmelden, ihre E-Mails ins System werfen.

localhost:smtp      inet  n       -       -       -       -       smtpd

Damit auch mein Webmail sauber funktioniert ist dieser Eintrag zuständig. Sonst lauscht halt keiner mehr lokal 😀

Hier ist nun klar zu sehen, das die per smtp angenommenen E-Mails je nach IP anderen Regeln unterliegen und auch lokal an amavis auf anderen Ports weitergeleitet werden. Dieses müssen wir natürlich amavis auch mitteilen. Wenn amavis nicht weiss das es auf weiteren Ports lausch soll, wird es dieses kaum von sich aus tun. Dafür müssen wir einen Eintrag unter /etc/amavis/conf.d/20-debian_defaults ändern.

$inet_socket_port = [10024,10028,10032];  # listen on multiple TCP ports geaendert

Jetzt geben wir in der /etc/amavis/conf.d/50-user noch unsere spezielle Regel für die sasl Benutzer an:

# DKIM
$policy_bank{'SASLNUTZER'} = {   # Einlieferung eigener Nutzer
originating => 1,
os_fingerprint_method => undef,  # eigentlich ueberfluessig
};
$interface_policy{'10028'} = 'SASLNUTZER';

Interessant ist hier im Grunde nur:

originating => 1,

Man könnte originating => 1 auch einfach mit in die 20-debian_defaults werfen und sich das mit der zweiten IP und den amavis Regeln sparen. Damit wird aber jede E-Mail als lokal behandelt. Ob das so gut ist bleibt jedem selbst überlassen 😛

Tja, was soll ich sagen, hier ist nun Ende. Sollte es Fragen oder Probleme geben, könnt ihr euch gerne bei mir melden!

Hier nun noch ein Paar Informationen zu DKIM:

DomainKeys ist ein Identifikationsprotokoll zur Sicherstellung der Authentizität von E-Mail-Absendern, das von Yahoo entwickelt wurde und seit Ende 2004 in Erprobung ist. Es wurde konzipiert, um bei der Eindämmung von unerwünschter E-Mail wie Spam oder Phishing zu helfen.

DomainKeys wurde ursprünglich unter dem Titel Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) im RFC 4870 veröffentlicht und unter dem Titel DomainKeys Identified Mail (DKIM) Signatures durch RFC 4871 abgelöst.

Arbeitsweise

DomainKeys basiert auf asymmetrischer Verschlüsselung. Die E-Mail wird mit einer Digitalen Signatur versehen, die der empfangende Server anhand des öffentlichen Schlüssels, der im Domain Name System (DNS) der Domäne verfügbar ist, verifizieren kann. Schlägt dies fehl, hat der empfangende Mail Transfer Agent (MTA) oder das empfangende Anwendungsprogramm die Möglichkeit, die E-Mail zu verweigern oder auszusortieren.

Kern des Verfahrens ist, dass der sendende MTA jede versendete E-Mail im sogenannten „DomainKey-Signature-Header“ mit einer digitalen Signatur des Inhaltes der E-Mail versieht.

Für die Erzeugung des für die Signatur nötigen Hashwertes unterstützt DKIM die Hashfunktionen SHA-1 und SHA-256, wobei die Verwendung von letzterer empfohlen wird. Die anschließende Verschlüsselung des Hashwertes, die letztlich die digitale Signatur zum Ergebnis hat, wird in beiden Fällen mit dem Verschlüsselungsverfahren RSA realisiert. Damit die Signatur mit dem beim E-Mail-Versand verwendeten ASCII-Zeichensatz dargestellt werden kann, wird sie mit Base64 kodiert.

Die so erzeugte digitale Signatur wird vom empfangenden MTA zunächst base64-dekodiert und dann mit dem öffentlichen Schlüssel der angeblichen Absender-Domäne (z.B. yahoo.com) entschlüsselt, der Hashcode der E-Mail wird neu berechnet. Stimmen der gelieferte entschlüsselte und der selbst berechnete Hashcode überein, stammt die E-Mail wirklich von der angegebenen Domäne. Der oder die verwendeten öffentliche(n) Schlüssel werden hierzu im DNS-Eintrag der sendenden Domäne publiziert. Das heißt, dass der DNS als Zertifizierungsstelle fungiert. Eine mit Hilfe von DomainKeys signierte E-Mail bietet also die Möglichkeit, sicher nachzuprüfen, ob die in der E-Mail-Absenderadresse enthaltene Domäne korrekt ist und dass die E-Mail auf dem Weg der Zustellung nicht verändert wurde.
Spamfilterung

Da es sich bei DomainKeys um einen Authentifizierungsmechanismus handelt, dient DomainKeys nicht dazu, Spam zu filtern. Stattdessen begrenzt DomainKeys die Möglichkeit, E-Mail-Absenderadressen zu verschleiern, da man mit DomainKeys feststellen kann, ob eine E-Mail tatsächlich über die angegebene Domäne versendet wurde.

Diese Nachvollziehbarkeit kann dazu verwendet werden, Bewertungssysteme und Filtertechniken von Spamfiltern wirkungsvoller zu gestalten. Zudem kann DomainKeys den Datendiebstahl durch Phishing begrenzen, da teilnehmende Mailversender ihre E-Mails als Originale zertifizieren können. Fehlt eine solche Zertifizierung, obwohl der vermeintliche Absender angibt, seine E-Mails zu zertifizieren, so kann die E-Mail als mögliche Fälschung betrachtet werden.
Lizenzierung

Yahoo hat das Verfahren patentieren lassen und es bei der IETF zur Standardisierung eingereicht. Das Verfahren wurde mittlerweile als Standard RFC 4871 akzeptiert.

Das DomainKeys-Verfahren kann von Yahoo wahlweise unter den Bedingungen der GPL 2.0 oder den Bedingungen des proprietären Yahoo DomainKeys Patent License Agreement lizenziert und verwendet werden.

Dem DomainKeys-Verfahren werden nach dem Scheitern der Standardisierung von Microsofts Sender ID – bei welchem an keine GNU-Lizenzierung gedacht wurde – gute Chancen eingeräumt, sich neben dem Sender Policy Framework (SPF) im Internet zu etablieren.
Unterstützung

Das DomainKeys-Verfahren erfordert größere Modifikationen am Mailserver – entsprechende Anpassungen existieren derzeit für fast alle gängigen Mail Transfer Agenten. Derzeit wird das DomainKeys-Verfahren nur von sehr wenigen Providern unterstützt; bekannte größere Provider, die Domainkeys einsetzen, sind Yahoo, Gmail und Strato.

Das Problem bei dieser und aller anderen Methoden zur Sicherstellung der Absender-Authentizität ist, dass es einen langen Zeitraum brauchen wird, um ein solches System zu verbreiten, da zuerst die Software angepasst werden muss und diese dann auch noch auf den Mailservern zum Einsatz kommen muss.
Weiterentwicklungen

Im Juli 2005 wurde von Cisco und Yahoo ein gemeinsamer Entwurf mit dem Titel DomainKeys Identified Mail (DKIM) bei der IETF eingereicht. Unterstützt wurde dieser Vorschlag nun auch von anderen Größen der IT-Branche, darunter mit Microsoft und AOL auch von denjenigen, die als Alternativlösung SPF vorschlugen. DKIM wurde im Mai 2007 als RFC 4871 veröffentlicht und ersetzte damit den vorherigen Entwurf RFC 4870.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑