Es ändert sich im Laufe der Zeit ja mal immer wieder etwas. So auch der Weg mit Netzwerkkarten umzugehen unter Solaris 🙂 Wer also gerade versucht die MAC Adresse seiner lokalen Netzwerkkarte / NIC herauszufinden, dem wird folgender Command helfen:
Hin und wieder bleibt beim Herunterfahren eine VM irgendwie hängen. Dann hat man über das XenCenter keine Möglichkeit mehr diese VM zum Leben zu erwecken. Damit man nun nicht den kompletten VM-Host dom0 neustarten muss, kann man erst folgenden Weg probieren.
Als erstes kann man einen force shutdown der vm probieren:
$ xe vm-shutdown –force vm=“VM-NAME“
Wenn es nicht hilft, kann man versuchen die “wartenden” pending Prozesse am XenServer zu killen:
$ xe task-list
Dann die Prozesse abbrechen welche den Shutdown zu verhindern scheinen:
$ xe task-cancel uuid=“TASK-UUID“
Bringt das alles nichts kann man als letztes noch folgendes probieren:
$ xe-toolstack-restart
Nun kann man noch einmal einen force shutdown probieren. Klappt es auch nicht, muss man wohl doch den VM-Host durchstarten!
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:
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>
<?
}
?>
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.
Es ist ein ordentlicher Nachfolger für rfc-ignorant.org gefunden! Der Hosting-Provider manitu hat auch bereits eine Domain gestellt: rfc-ignorant.de
Noch ist die Liste „leer“. Keine Anfrage wird daher negativ bewertet. Denn noch kann man sie bereits in seine Konfiguration aufnehmen. Die neuen Zonen sind:
Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt.
Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht.
Zusammengefasst bedeutet es:
– Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen.
– Ich kann diesen Speicher aber nicht anlegen 🙁
Damit wäre also nur das Problem des Anlegens zu lösen!
Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit.
Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen.
Festhalten, es geht los…
– gparted öffnen
– den >2TB Datenspeicher auswählen
– über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen
– unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden
– den neuen unallocated Speicher markieren
– über den Menüpunkt Partition den Unterpunkt New auswählen
– nun den File system Type auf lvm2 pv setzten und Hinzufügen
– Abschließend noch diese Änderungen anwenden über den Button Apply
Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen.
Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:
Ich war mal wieder auf so einem lustigen Postfixvortrag… Die verschiedenen Möglichkeiten der Spamabwehr waren natürlich wieder Thema. Der Vortragende ist dabei tierisch auf sender adress verification abgegangen. Er hat es quasie als Lösung aller Probleme verkauft. Puhh, ich habe mich bald an der Mate verschluckt. Ich mein… OK in ganz besonderen Fällen kann es möglicherweise helfen (mir fallen zwar gerade keine ein aber…) und früher ging da vielleicht mal was. Im Grunde macht diese Art der „Spamabwehr“ nur Stress.
Versucht jemand eine E-Mail einzuliefern, versucht Postfix vor der Annahme der E-Mails zuerst selbst eine E-Mail an den Absender zuzustellen. Klappt dieses nimmt er die E-Mail an und wenn es nicht geht, dann nicht. Kommt also eine E-Mail vom Absender: spam@spamgott.net versucht Postfix diesem Absender eine E-Mail zuzustellen. Es wird also geprüft ob es die Domain überhaupt gibt, dann wird geschaut ob es einen MX-RECORD gibt, dann wird versucht eine Verbindung zu diesem Server aufzubauen. Ist es nicht möglich würde Postfix die jeweilige Meldung an den einliefernden „durchreichen“. Damit würden E-Mails nicht abgewiesen nur weil der Maileingangsserver des vermeintlichen Absenders gerade Stress hat oder dort Greylisting aktiviert ist. Wäre es möglich eine E-Mail einzuliefern wird die E-Mail erst überhaupt angekommen und die Absenderadresse in folgender Datei abgelegt:
/var/lib/postfix/verify_cache.db
Aktiviert wird der ganze Foo in der Postfix Konfigurationsdatei /etc/postfix/main.cf:
Klingt alles erst einmal ganz gut, oder? Ne überhaupt nicht…. Die Idee ist nett aber wenn man sich nun mal vorstellt eine Domain wird zum versenden von Spam missbraucht, dann schlagen bei diesem Server nicht nur die ganzen Bounce E-Mails auf, sondern zusätzlich noch der ganze Verification Krims. Es soll auch Absender geben die man wirklich nicht erreichen kann (sinnfrei, ist mir auch klar). Diese E-Mails kommen natürlich nicht an…. Versucht immer mal wieder jemand E-Mails an Empfänger zuzustellen, welche es nicht gibt, machen Mailserver gerne mal für eine gewisse Zeit dicht. Was ebenfalls nicht gut ist 😀
Und mal im Ernst, niemand will wirklich Strom, Traffic und Hardwareleistung bezahlen für den Mist. Wenn man sich einfach nur unnötige Last auf sein System ziehen will, wäre SETI@home mein Tipp! Mit etwas Hirnschmalz in seine Konfiguration gibt es deutlich bessere und effektivere Möglichkeiten. Dieser Weg ist einfach mal wieder der Versuch die Arbeit anderen aufzuhalsen.
Klar, nach RFC müssen bestimmte Dinge bei einem Mailserver zusammenpassen.
Nach RFC1912 – Section 2.1 muss der Rückwärts aufgelöster Hostname zu dessen Vorwärtsauflösung passen.
Als Beispiel: Wenn ich nachfrage welcher DNS Name zur IPv4 Adresse 10.2.3.4 gehört und darauf die Antwort bekomme, es ist: test.example.com…. Ja dann muss auf die Frage welche IPv4 Adresse zum DNS Namen test.example.com gehört auch die Antwort kommen: 10.2.3.4
Aus Sicht des testenden ist die Wahrscheinlichkeit schon höher dass beide Systeme unter der gleichen Kontrolle stehen. Zusätzlich haben Bots in einem Botnetz extrem selten die Möglichkeit diese Einträge passend zu setzten und der Administrator des Systems hält sich nicht nur die RFCs sondern konfiguriert zudem ordentlich. Es ist daher ebenfalls wahrscheinlich dass er sich bei seinen sonstigen Konfigurationen auch Mühe gegeben hat 😀 Dieses lässt sein System zusätzlich sicherer gegen Missbrauch erscheinen.
Weiter im Text… Denn nach RFC 2821, Section 3.6 muss der im HELO/EHLO angegebene DNS Name nicht nur ein gültiger Fully Qualified Domain Name (FQDN) sein, sondern er muss zusätzlich zum Hostname des einliefernden Mailservers passen. So lässt sich nun ersehen dass nicht nur IP und DNS unter der gleiche Kontrolle zu sein scheinen, sondern gleichfalls das Mailsystem.
Der Admin scheint also zu wissen was er tut und hat auch die Kontrolle über das System 🙂
Ich prüfe dieses nun bei jeder einzuliefernden E-Mail. Ist nicht alles korrekt, wird die E-Mail abgelehnt. In den letzten Wochen tauchen genau hier gehäuft Unstimmigkeiten auf und dieses nicht bei kleinen „Wurstbuden“ sondern auch bei den ganz Großen! Natürlich ist es kein zwingender Grund E-Mails auf dieser Basis abzuweisen…. Da die Sysadmins der Mailserver, vor allem der ganz GROSSEN, ja Fachleute sind… Sollte man von diesen erwarten können sich an diese einfachen Vorgaben zu halten, oder? — Oder ist es wirklich zu pingelig?
Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:
dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space
Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result: pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
To:'20'<check-auth@verifier.port25.com>;'0D''0A'
Subject:'20'check-auth@verifier.port25.com'0D''0A'
MIME-Version:'20'1.0'0D''0A'
Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
'20'format=flowed'0D''0A'
Content-Transfer-Encoding:'20'7bit'0D''0A'
Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
'09's=kernel-error.com;'20't=1352457228;'0D''0A'
'09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
'09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
'09''20'Date:From:Message-ID;'0D''0A'
'09'b=
Canonicalized Body:
check-auth@verifier.port25.com'0D''0A'
DNS record(s):
kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"
NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions. If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.
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.