IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Autor: Sebastian van de Meer (Seite 26 von 47)

Citrix XenServer: Festplattenpriorität im Storage-Pool konfigurieren​

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die Storage-Pool-Konfiguration hat sich grundlegend geändert. Alternativen: Proxmox VE oder XCP-ng.

Hat man in seinem Citrix XenServer mehrere virtuelle Festplatte in einem Storage liegen, kann es vorkommen dass man einzelnen davon eine höhere Priorität zuweisen möchte als anderen.

Leider gibt es diese Option nicht klickbar im Citrix XenCenter, sondern man muss die Konsole (CLI) bemühen.

Das Einstellen dieser Prioritäten ist etwas komplexer, ich beschränke mich in meinem Beispiel auf die „schnell und einfach“ Version. Damit möchte ich sagen, bitte selbst damit beschäftigen.

Zum Thema… Es gibt verschiedene Algorithmen, welche man für sein QOS der virtuellen Festplatten wählen kann. Ich nehme gerne ionice, da es bei mehreren Systemen eher um IO-Probleme als reine Durchsatzprobleme geht. Diesem Algorithmus gebe ich die Information mit das es hier um realtime geht und die Klasse in welche die virtuelle Festplatte gesteckt werden soll. Bei der Klassifizierung ist zu beachten, dass es ein ganzzahliger Wert zwischen 0 und 7 sein muss. Die Klasse 0 hat dabei die höchste Priorität und die Klasse 7 die geringste.

Kleines Beispiel gefällig?

Wir sind auf der root Konsole des XenServers. Ich lasse mir die VMs mit ihren Platten anzeigen, in diesem Fall gibt es keine Snapshots. Würde es welche geben, gleiches Vorgehen, es sieht nur etwas „unübersichtlicher“ aus.

[root@fra.srv.ha.xen.05 ~]# xe vbd-list
uuid ( RO)             : 66a3903c-8eba-4d8a-92d9-c435d399d3ac
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): VM-Kennzeichnung
         vdi-uuid ( RO): <not in database>
            empty ( RO): true
           device ( RO):

uuid ( RO)             : 4e004302-c32e-4c90-b986-9efc0b1995a1
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): 47e5ab14-9cf8-4e7f-88b8-fe20247efa85
            empty ( RO): false
           device ( RO): xvdb

uuid ( RO)             : 5b4f70ec-07cb-47a5-aa05-91647cf38b78
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): e6796376-995f-4a99-8ba6-893c30aa6a14
            empty ( RO): false
           device ( RO): xvda

Zu erkennen ist ein System (577e39d4-e771-477b-8829-8648b05b682b) mit zwei virtuellen Festplatten (4e004302-c32e-4c90-b986-9efc0b1995a1 / 5b4f70ec-07cb-47a5-aa05-91647cf38b78).

Versorgt mit diesen Informationen kann ich nun direkt die beiden Platten mit neuer Priorität versehen.

$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_params:class=5

$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_params:class=5

Als Test lasse ich mir nun noch einmal die gesetzten Einstellungen auf der Konsole ausgeben. Einmal den gewählten QOS-Algorithmus und dann dessen gesetzte Optionen.

$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_type
ionice
$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_params
class: 5; sched: rt

Noch Fragen? Dann fragen…

 

Mechanische Tastaturen: Von der IBM Model M zum Das Keyboard

Es soll Menschen geben, denen nur das Wort „bekloppt“ einfällt, wenn es im Zusammenhang mit mir um Tastaturen geht. Zugegeben, da könnte ein Funken Wahrheit dran sein.

IBM Model M

Angefangen hat es, wie bei vielen, mit der IBM Model M. Eine wunderbare Tastatur. Es schreibt sich klasse auf dem Ding, sie hat einen ganz eigenen Sound und man fühlt das Tippen einfach. Leider wurde zuletzt nur noch ein PS/2-Modell entwickelt. Es gibt zwar USB-Adapter, aber da die Tastatur mehr Strom verbraucht als normale PS/2-Tastaturen, sterben diese Adapter gerne mal. Zum Beispiel wenn man die NUM-Taste aktiviert. Lösung wäre, die LEDs aus der Tastatur zu nehmen oder einen USB-PS/2-Adapter mit externer Stromversorgung zu nutzen. Beides nicht ideal. Und die Windows/Linux-Taste fehlt ihr auch.

Die Suche nach Ersatz

Gezwungenermaßen musste ich also eine neue Tastatur nutzen. Ich erinnere mich, dass ich schon beim Kauf dem Verkäufer ziemlich auf die Nerven gegangen bin, weil ich mich durch alle Tastaturen probieren wollte. Zu dem Zeitpunkt war eine Tastatur bereits ein Wegwerfartikel. Selbst eine „gute“ lag bei 60 Euro und war aus seiner Sicht völlig ausreichend. Aus meiner Sicht waren alle überladen mit Sondertasten: Taschenrechner öffnen, Suche öffnen, Play. Ich will tippen.

Es wurde eine Logitech. Sie war OK, wobei OK hier der Bruder von Scheiße ist. Dann eine Cherry, besser, aber nicht richtig gut.

Das Keyboard

Irgendwo hörte ich von einer Tastatur namens „Das Keyboard“. Der Preis war mit knapp 160 Euro heftig, besonders da ich keine Möglichkeit hatte, sie vorher zu testen. Glücklicherweise kann man Online-Bestellungen innerhalb von zwei Wochen zurückschicken. Es wurde also Das Keyboard in Version 1.

Perfekt. Schöne Tastatur, tippt sich wunderbar, klingt auch wieder schön. Zwei kleine Probleme: Erstens die Größe, ähnlich wie die IBM, aber nicht mehr ganz zeitgemäß. Zweitens habe ich ein Glas Dr Pepper über die Tastatur gekippt. Nach zwei Jahren war sie tot.

Dieses Mal keine Experimente beim Neukauf. Es wurde das „Das Keyboard Model S Professional Clicky“ mit Cherry MX Blue Switches. Nicht so groß, feiner Sound, tippt sich wunderbar. Mein Workspace zuhause war gerettet.

Im Büro

Blieb noch das Problem auf der Arbeit. Dort hatte ich eine Logitech, bei der die F-Tasten standardmäßig Play, Stop und ähnlich Wichtiges auslösten. Die echten F-Tasten erreichte man nur mit der Fn-Taste. Als schnellen Ersatz gab es dann eine Logitech MK120. Auf dieser konnte ich nicht schreiben. Tut mir leid, geht nicht. Vier Tage versucht. Also die alte Cherry mitgenommen. Das ging immerhin.

Fragen? Einfach melden.

STOP GELD

Am Wochenende habe ich mal wieder den Al Bundy gegeben. Damit möchte ich sagen, ich habe den Inhalt meiner Geldbörse an meine Familie verteilt. Um heute in der Mittagspause nicht am Hungertuch nagen zu müssen, wollte ich vor der Arbeit noch schnell Geld aus dem Geldautomaten der Sparkasse in der Nähe ziehen.

Leide präsentierte sich die Kiste mit dem unten stehenden Bild (sorry für die schlechte Aufnahme)….

Lustig oder? Na ja, wie man es sieht! Auf dem Automat läuft also klar ein Microsoft Windows. Dieses hat sich auf die Nase gelegt. Fehler gibt es in jeder Software, einfach nur zu lachen und auf das „dumme“ Windows zu zeigen wäre hier wohl zu einfach.

Warum läuft denn auf dem Automat ein Windows? Ich denke zum Teil gutes Lobbying… Dieses wird es nur nicht alleine sein. Ich denke der laufende Support wird ebenfalls ein Thema sein (wie lange hatte so ein Windows XP noch gleich Support?).

Fragen? Einfach melden.

Google will sicheres Internet.

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

Fragen? Einfach melden.

mailgraph Graphen um DANE erweitern

Wie sich die grafische Logfile Auswertung für, unter anderem, Postfix um Dinge wie SPF, DKIM und DMARC erweitern lässt, habe ich ja bereits vor kurzem hier gezeigt: mailgraph Graphen um SPF, DMARC und DKIM erweitern

Seit ein paar Monaten ist an meinem Mailserver DANE aktiviert, sprich es lassen sich die TLSA RECORDS für die Zertifikate am Postfix gegen einen DNSSEC gesicherten DNS Server abgleichen.

In diesem Zuge habe ich selbstverständlich die ausgehende Prüfung am Postfix aktiviert. Mein Postfix nutzt nun also auch DANE um die Verbindung zu anderen Mailserver zu prüfen. Dabei gibt es im Grunde nur vier mögliche Ergebnisse einer Prüfung der TLS Verbindung:

Verified

Der bisher seltenste aber beste Fall. Denn die ausgehende Verbindung zum anderen Server ist per DANE gesichert. Das Zertifikat ist also nicht nur gültig sondern konnte auch mit den TLSA-RECORDS abgeglichen werden.

Trusted

Der OK Fall… Das Zertifikat ist gültig.

Anonymous

Na ja… Es gibt ein Zertifikat und dieses ist passend zum Hostname, es konnte aber keine Vertrauenskette gebildet werden.

Untrusted

Schlecht! Es gibt zwar ein Zertifikat und somit auch eine verschlüsselte Verbindung, denn noch stimmt etwas mit dem Zertifikat nicht. Es ist abgelaufen, passt nicht zum Hostname oder ähnliches.

Im Logfile findet es sich wie folgt:

Aug  3 18:34:08 servername postfix/smtp[1234]: Verified TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  9 12:07:28 servername postfix/smtp[1234]: Trusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  8 22:15:34 servername postfix/smtp[1234]: Anonymous TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Aug  7 21:48:48 servername postfix/smtp[1234]: Untrusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)

Was mich nun interessiert, ist die Tendenz der einzelnen Prüfungen. Wie sicher ist die Kommunikation zu anderen Mailservern wirklich, rein bezogen auf die Vertrauenswürdigkeit der eingesetzten Zertifikate. Eine schnelle Übersicht soll mir hier wieder der mailgraph liefern.

Den Mailgraph habe ich also, wie mit SPF, DKIM und DMARC ebenfalls, erweitert. Das nötige Patchset gibt es natürlich wieder unten. Dieses Mal habe ich darauf geachtet für die TLS Auswertung ein eigenes File für die RRD-Daten anzulegen. So kann ein bestehender Mailgraph einfach erweitert werden, ohne die vorhandenen Daten zu verlieren.

Heraus kommt am Ende dieser Graph.

Für interessiere finden sich die beiden nötigen Patchfiles hier:

/usr/sbin/mailgrapht

/usr/lib/cgi-bin/mailgraph.cgi

Viel Spaß! Bei Fragen, fragen.

Fragen? Einfach melden.

E-Mail-Benachrichtigung bei Root-Login einrichten

Kein Server lässt sich zu 100 Prozent absichern. Wenn sich jemand eine Root-Shell öffnet, will ich das zeitnah wissen. Nicht erst wenn Kunden sich melden oder Abuse-Mails eintrudeln. Eine kurze E-Mail mit IP-Adresse und Zeitstempel bei jedem Root-Login gibt zumindest einen Anhaltspunkt.

Vorweg: Das ist kein Security-Feature. Ein Angreifer mit Root-Rechten kann die Benachrichtigung deaktivieren, die Mail abfangen oder die .bashrc löschen. Es ist Schlangenöl, wenn man es als Schutzmaßnahme verkauft. Aber als ergänzender Hinweis funktioniert es gut, weil die Mail meist schon raus ist bevor der Angreifer sie verhindern kann. Vorausgesetzt, die Mail geht an einen anderen Server.

Variante 1: .bashrc

Die einfachste Methode. Eine Zeile in /root/.bashrc schickt bei jedem Öffnen einer interaktiven Shell eine Mail:

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@example.com

Das Ergebnis sieht dann so aus:

Subject: Alert: Root Access from 203.0.113.42
ALERT - Root Shell Access (bsd01) on: Mi 12. Mär 14:22:03 CET 2026 root pts/0 2026-03-12 14:22 (203.0.113.42)

Damit die IP-Adresse statt eines Hostnamens in der Mail steht, sollte der SSH-Server keine DNS-Abfragen machen:

# /etc/ssh/sshd_config
UseDNS no

Variante 2: PAM

Robuster als die .bashrc-Methode, weil PAM vor der Shell greift und nicht so leicht umgangen werden kann. In /etc/pam.d/sshd am Ende:

session optional pam_exec.so /usr/local/bin/login-notify.sh

Das Script /usr/local/bin/login-notify.sh:

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
echo "SSH Login: $PAM_USER von $PAM_RHOST auf $(hostname) um $(date)" | \
  mail -s "SSH Login: $PAM_USER@$(hostname) von $PAM_RHOST" root-logins@example.com

PAM setzt die Umgebungsvariablen PAM_USER, PAM_RHOST und PAM_TYPE automatisch. Das Script prüft auf open_session, damit es nur beim Login feuert und nicht beim Logout.

FreeBSD

Unter FreeBSD heißt die PAM-Konfiguration /etc/pam.d/sshd (gleicher Pfad). Statt mail steht dort mailx zur Verfügung, oder man nutzt direkt sendmail. Die .bashrc-Variante funktioniert genauso, die Datei liegt unter /root/.profile wenn csh/tcsh die Standard-Shell ist.

Einordnung

Login-Benachrichtigungen ersetzen kein Monitoring und kein Intrusion Detection System. Sie sind ein einfacher Stolperdraht, der in der Praxis überraschend oft hilft. Nicht weil er einen Angriff verhindert, sondern weil er die Reaktionszeit verkürzt. Wenn um drei Uhr nachts eine Login-Mail von einer unbekannten IP kommt, weiß man dass etwas nicht stimmt.

Wer den SSH-Zugang selbst härten will: Multi-Faktor-Authentifizierung mit Google Authenticator macht einen erfolgreichen Login ohne den zweiten Faktor deutlich unwahrscheinlicher. Fragen? Einfach melden.

Der eingeschlafene Hintern im DataCenter

Da hocke ich heute mal wieder im DataCenter und arbeite an den Systemen. Wie immer, im Schneidersitz auf dem Boden und mit den Notebook auf den Beinen. Nach einiger Zeit merke ich, dass mein Hintern aufgehört hat sich über die Temperatur zu beschweren. Dieses ist in der Regel ein untrügerisches Zeichen dafür, dass er eingeschlafen ist. Was nun Vor- und Nachteile hat. Vorteil, ich kann noch länger so sitzen ohne das es fühlbar unbequem wird; Nachteil, wenn ich später versuche aufzustehen, wird es lustig!

Das muss doch irgendwie besser gehen, oder? OK, ok… Es gibt in der Regel einen hässlichen Hocker, der ist aber so hässlich das man doch besser auf dem Boden sitzt, weil es dann doch bequemer ist. Dann könnte ich mir noch ein Kissen mitbringen und es unterlegen.. ne, doch nicht! Wenn ich so überlege dann finden sich in meiner Erinnerung nur Bilder, von auf dem Boden hockenden Technikern vor einem Schrank. Alle mit kaltem Hintern und jedem schläft dieser früher oder später ein. Da sollte mal jemand was erfinden *AUFRUF*.

Wie auch immer, wenn ich mir schon über solche Dinge Gedanken mache… Dann kann es mir nicht so schlecht gehen, oder vielleicht genau aus diesem Grund doch? Na dann werde ich wohl nun mal jemanden aufwecken, wünscht mir Glück.

Fragen? Einfach melden.

Samsung Galaxy S2: Überhitzung durch defekten BCM4330 und Mainboard-Tausch

Das ärgert mich jetzt. Es hat tatsächlich einige Zeit gedauert, bis ich mich überhaupt zu einem Smartphone habe hinreißen lassen. Damals fiel die Wahl auf das Samsung Galaxy S II. Es lief ein paar Jahre tadellos, vor allem mit CyanogenMod 11.

Das Problem

Irgendwann hielt der Akku nicht mehr den ganzen Tag. Es ging so schleichend, dass ich es zunächst nicht bemerkt habe. Als es dann massiv wurde, dachte ich natürlich zuerst an den Akku selbst, der hatte ja bereits zwei Jahre auf dem Rücken. Beim Laden wurde das Handy besonders warm, um nicht zu sagen heiß.

Also einen originalen Samsung-Akku über eBay besorgt. Leider änderte sich damit nichts. Dann habe ich gelesen, dass Dreck an der USB-Buchse zu Kriechströmen führen kann. Buchse gereinigt, nichts. Netzteil getauscht, nichts.

Die Fehlersuche

Also aufgeschraubt. Inzwischen verbrannte das Gerät selbst im abgeschalteten Zustand so viel Strom in Wärme, dass es trotz angeschlossenem Ladegerät nicht mehr reichte, den Akku zu laden. Ich wollte herausfinden, welches Bauteil die Hitze erzeugt.

Unter einer Schirmung mit der Aufschrift GT-I9100 #4 vermutete ich die Quelle zuerst. Es stellte sich aber heraus, dass es der IC auf der anderen Seite des Mainboards war: SWB-B42. Das ist der Broadcom BCM4330, zuständig für WLAN, Bluetooth und FM-Radio. Meine Hoffnung, dass nur die nahe am Mainboard verlötete CMOS-Batterie ein Problem hatte, war damit dahin.

Reparatur-Optionen

Den BCM4330 bekommt man für etwa 15 Dollar plus Porto. Mit drei Wochen Wartezeit und 30 Euro Einsatz wäre das machbar gewesen. Den alten IC mit Heißluft lösen, neuen auflöten. Viel Arbeit, und gemacht haben sollte man es auch schon mal.

Ich habe mich stattdessen für ein neues Mainboard entschieden. Neu lag ich bei 150 bis 200 Euro. Zu teuer. Aber auf eBay fand ich ein Galaxy S2 mit defektem Display, irgendjemand war wohl draufgetreten. 50 Euro. Gekauft, Mainboard getauscht.

Ergebnis

Es funktioniert. So blieb mir das Galaxy S II doch noch eine Weile erhalten.

Fragen? Einfach melden.

Aber ich habe doch nichts zu verbergen…

Da ist nun also das Ergebnis von eurem „Ich habe doch nichts zu verbergen“! Klasse, gut gemacht….

http://www.golem.de/news/data-mining-polizei-will-straftaten-mit-predictive-policing-verhindern-1407-107638.html

Jetzt muss du nicht mal was zu verbergen haben, jetzt reicht es, wenn man statistisch leider gerade „auffällig“ ist. Am Ende treten die Jungs euch die Türe ein, verhaften euch und führen euch in Handschellen ab. OK ok… Wird nicht passieren, Rechtsstaat usw…. Riiiiiiccchhhhtttiiiigggg

Glaubt ihr das wirklich?

Klar, wenn sich am Ende herausstellt das ihr nichts zu verbergen hattet, wird schon nichts passieren…. Dem Rest kann man ja auch später erklären das die Vorwürfe völlig haltlos waren und euch nichts nachgewiesen werden konnte. Das verstehen alle und es bleibt kein ~Nachgeschmack~… Ich übertreibe? Na warten wir mal ab, ich denke es wird noch genau so kommen. Genug Metadaten habe sie ja inzwischen.

Ich denke: „It´s time for PANIC!“ Ich habe Angst 🙁

Panic reaction GIF about surveillance and privacy

Wir müssen unbedingt alle etwas mehr auf unsere Daten achten und vor allem etwas „nervöser“ werden wenn es um die Überwachung von egal was geht. Nicht alles sinnfrei glauben, sondern mal mit Hirn hinterfragen! Das Thema: „Ich habe doch nichts zu verbergen“ ist damit wohl hoffentlich erschlagen, oder?

Fragen? Einfach melden.

Google, IPv6 und geblockte E-Mails…

Google lehnt hin und wieder E-Mails ab, die per IPv6 eingeliefert werden. Der Mailserver ist korrekt konfiguriert, SPF, DKIM, DMARC und DANE sind vorhanden, kein Eintrag auf irgendeiner Blacklist. Per IPv4 geht die gleiche Mail problemlos durch.

Die Fehlermeldung

550-5.7.1 Our system has detected that this message is likely
550-5.7.1 unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked.

Der verlinkte Support-Artikel hilft nicht weiter. Alle Vorgaben sind erfüllt. Googles Antwort auf Nachfrage: „Warum genau eine E-Mail abgewiesen wird, können wir Ihnen leider nicht mitteilen.“ Das betrifft gmail.com, googlemail.com und jede bei Google gehostete Domain gleichermaßen.

Workaround: IPv4-only für Google

Da Google per IPv4 keine Probleme macht, lässt sich Postfix so konfigurieren, dass E-Mails an Google-Domains nur über IPv4 zugestellt werden. Das ist unnötig, ärgerlich und widerspricht dem Gedanken hinter IPv6. Aber es funktioniert.

In /etc/postfix/master.cf einen eigenen SMTP-Service anlegen, der nur IPv4 spricht:

smtp4     unix  -       -       -       -       -       smtp -o inet_protocols=ipv4

In /etc/postfix/main.cf die Transport Map aktivieren:

transport_maps = hash:/etc/postfix/transport

Die betroffenen Domains in /etc/postfix/transport eintragen:

googlemail.com smtp4:
gmail.com smtp4:

Anwenden und Postfix neu laden:

postmap /etc/postfix/transport
service postfix reload

E-Mails an Google-Domains gehen ab sofort nur noch über IPv4 raus. Wer weitere Domains pro Ziel steuern will, findet in Postfix TLS Policy Maps einen ähnlichen Ansatz.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑