NETWAYS Blog

Ubuntu 18.04 LTS "Bionic Beaver" erschienen

von Fabian Rothlauf | Mai 2, 2018 | Technology, Web Services, Betriebssysteme, NETWAYS, Linux

Eigentlich wollte Canonical die neue Ubuntu LTS Version „Bionic Beaver“ bereits am Donnerstag veröffentlichen – einige Bugfixes zum Schluss verhinderten diesen Schritt jedoch und das Release verzögerte sich auf die frühen Morgenstunden des letzten Freitags unserer Zeit.
Desktop Nutzer, welche nur LTS Versionen nutzen werden bei Ubuntu 18.04 LTS werden sicher etwas gespalten sein, setzt die neue LTS Version wie auch schon sein unmittelbarer Vorgänger 17.10 ebenfalls auf GNOME, statt wie zuvor auf die Eigenentwicklung Unity. Für mich persönlich eine sehr willkommene Änderung, da ich mich in vielen Jahren nie wirklich mit Unity anfreunden konnte. Ubuntu 17.10 setzte dabei noch auf Wayland, Ubuntu 18.04 LTS kehrt jedoch zum altbewährten X.org zurück – nicht weil sich Wayland nicht bewährt hat, sondern weil es für eine LTS Version noch hier und da zu Problemen mit Remote Sessions, oder VoIP kommt. Zu einem späteren Zeitpunkt soll Wayland jedoch auch seinen Weg zurück zu Ubuntu finden. Für viele Nutzer sicher auch willkommen: Der Kernel-Livepatching-Mechanismus, der bisher zum Teil recht umständlich war, wird bei Ubuntu 18.04 per Default mit angeboten und soll die Sicherheit zwischen Reboots gewährleisten – benötigt wird hierfür jedoch ein Ubuntu SSO Konto, bei dem bis zu drei Geräte die Vorteile genießen dürfen.
Eine wichtige Änderung bei Ubuntu 18.04 LTS ist ebenfalls die Erfassung, sowie Übertragung anonymisierter Benutzerdaten. Bei der Installation sollte man daher unbedingt darauf achten die Checkbox entsprechend richtig nach dem eigenen Empfinden zu setzen. Wer also Bedenken hat wenn Hardwaredaten, oder benutzerdefinierte Settings wie beispielsweise aktiviertes Livepatching anonym übertragen werden, sollte hier genauer hinsehen.
Sowohl Desktop, als auch Server setzen auf einen Kernel der Version 4.15, welcher unter anderem Specte und Meltdown Probleme adressiert. Apropos Ubuntu 18.04 Server – auch hier gibt es natürlich diverse Änderungen. Wie gewohnt bei einer neuen LTS Version von Ubuntu werden diverse Softwareversionen angehoben. PHP kommt Beispielsweise in der Version 7.2, bei Ubuntu 16.04 LTS war es noch Version 7.0. Sollte man also ein Upgrade anstreben, sollte man unbedingt seine Applikation im Voraus testen, bevor ein böses Erwachen folgt. Ein Upgrade von 16.04 LTS auf 18.04 LTS sollte aber erfahrungsgemäß erst mit der ersten Überarbeitung 18.04.1 LTS erfolgen, ab diesem Zeitpunkt sollten „Xenial Xerus“-Systeme auch auf das Upgrade hinweisen. Ubuntu 18.04.1 LTS soll laut Release-Schedule im Juli erscheinen.
Eine weitere Änderung ist, dass Neuinstallationen von Ubuntu 18.04 LTS gänzlich auf ifupdown verzichtet – das altbewährte ifup und ifdown gibt es demnach natürlich auch nicht mehr, kann jedoch nachinstalltiert werden. Die Alternative ist jedoch auch mit „ip“ gegeben, welches sich ebenfalls intuitiv recht einfach bedienen lässt. Systeme, welche durch ein Upgrade auf 18.04 LTS angehoben werden sind von dieser Änderung allem Anschein nach nicht betroffen.

Fabian Rothlauf

Manager MyEngineer

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen durfte, freut er sich bei NETWAYS nun auf weitere nette Kolleg:innen, interessante Aufgaben und neue Blickwinkel.

Lies mehr von Fabian und triff unser Team

Postfix – SPF, DKIM und DMARC

von Fabian Rothlauf | Nov 15, 2017 | Technology, Web Services, Linux

In der heutigen Zeit werden E-Mails oftmals nicht mehr über einen einzelnen Server verschickt. Wie sollten große Anbieter es sonst schaffen alle E-Mails Ihrer Millionen Nutzer zeitnah abzuhandeln? Spätestens wenn es zu Versand von Newslettern kommt, wird auf mehrere Server zurückgegriffen, damit zum Beispiel E-Mails der Mitarbeiter nicht in einer Warteschlange landen mit 100.000 Newslettern.
Damit diese Server vom Empfänger verifiziert werden können wurden die Mechanismen SPF, sowie DKIM eingeführt. Basierend auf diesen beiden kam später noch DMARC hinzu. Im folgenden möchte ich beschreiben, wie man diese Mechanismen mit Postfix verbindet und entsprechende Informationen publiziert.

SPF – Sender Policy Framework

Fangen wir mit SPF an. Bei SPF wird im DNS einer Domain ein TXT-Record hinterlegt. Dort gibt man in einer bestimmten Syntax an, welche Server für diese Domain verifiziert sind. Beispielhaft sieht ein SPF Record in etwa so aus:

v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 a:mx.domain.tld include:other-domain.tld ?all

Dieser sagt aus, dass Mails von der IPv4 Adresse 1.2.3.4 und 1.2.3.5 verschickt werden dürfen, sowie vom Server hinter dem A-Record mx.domain.tld. Zudem sollen die Einstellungen der Domain other-domain.tld included werden und über alle anderen soll keine weiter Aussage getroffen werden mit ?all. Mit „-all“ würde man den Versand über alle anderen Mailserver verbieten. Dies kann jedoch zu Problemen führen in Szenarien, wie Beispielsweise bei der Weiterleitung von Mails. Bitte beim include aufpassen, hier gibt man einiges aus der Hand, wenn „other-domain.tld“ nicht von einem selbst verwaltet wird.

SPF mit Postfix verbinden

apt-get install postfix-policyd-spf-python

Anschließend öffnen wir die Datei /etc/postfix/master.cf und fügen folgendes hinzu:

postfix-policyd-spf unix – n n – 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf

Und um die policy auch zu verwenden, editieren wir die smtpd_recipient_restrictions in /etc/postfix/main.cf. Bitte beachtet, dass ihr diese unbedingt NACH reject_unauth_destination einfügt.

smtpd_recipient_restrictions = … reject_unauth_destination check_policy_service unix:private/postfix-policyd-spf …

Danach restarten wir postfix. Bei eingehenden Mails sollte nun ein Header enthalten sein, der in etwa wie folgt aussieht:

Received-SPF: Pass (sender SPF authorized) …

Weitere Einstellungen kann man noch unter /etc/postfix-policyd-spf-python/policyd-spf.conf vornehmen.

DKIM – DomainKeys Iidentified Mail

DKIM verfolgt ebenfalls das Ziel den Absender zu verifizieren, jedoch mit anderem Ansatz. Dabei werden Headerdaten, die man auch selbst definieren kann mittels eines privaten Schlüssels signiert, während sich der öffentliche Schlüssel im DNS der jeweiligen Domain befindet. Wo dieser genau zu finden ist, bestimmt der Selector – dazu aber gleich noch mehr. Sollte man die Headerdaten, welche signiert werden sollen, selbst definiert, sollte man unbedingt darauf achten, dass es Header sind, die im Verlauf des Versands nicht verändert werden, mehr dazu aber auch im RFC6376 – Abschnitt 5.4.
Beide Verfahren dienen nur dazu den Absender zu verifizieren, es bietet daher keinen Spamschutz im eigentlichen Sinn, wie manche sich vielleicht erhoffen. Sie sind aber relativ schnell eingerichtet und manche Mailserver und Dienste bewerten Mails mit gültigem SPF und DKIM besser, daher ist die Einrichtung kein absolutes „Muss“, aber dennoch ein „Nice-to-have“.

OpenDKIM mit Postfix verbinden

apt-get install opendkim opendkim-tools

Bevor wir nun mit opendkim und postfix weiter machen generieren wir erst einmal Keys, die wir verwenden möchten:

mkdir -p /etc/opendkim/keyfiles/domain1.tld
cd /etc/opendkim/keyfiles/domain1.tld
opendkim-genkey -s mail -d domain1.tld

Damit werden zum einen die Datei mail.private generiert, die den privaten Schlüssel beinhaltet, sowie mail.txt. welche den öffentlichen Schlüssel beinhaltet. Der oben genannte Selector ist „mail“. Den öffentlichen Schlüssel können wir daher schon im DNS der Domain domain1.tld hinterlegen. Dabei handelt es sich um einen Textrecord, der in unserem Beispiel unter mail._domainkey.domain.tld hinterlegt sein muss. Ist dies erledigt geht es weiter in der Konfiguration.
Anschließend ist die Datei /etc/opendkim.conf wichtig, hier wird die zentrale Konfiguration von opendkim vorgenommen. Beispielsweise so kann eine Konfiguration aussehen:

Mode sv
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
UserID opendkim:opendkim
Syslog yes
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Canonicalization relaxed/relaxed
LogResults yes
LogWhy yes
SyslogSuccess yes
Socket inet:10080@localhost
SignatureAlgorithm rsa-sha256

Wichtig sind hier zum einen der Port, zum anderen aber natürlich die beiden Parameter KeyTable und SigningTable. Weitere Konfigurationsparameter kann man in der Dokumentation der offiziellen Seite von opendkim nachlesen. Gehen wir aber weiter in unserem Beispiel. Ein Keytable kann z.B. wie folgt aussehen:

mail._domainkey.% %:mail:/etc/opendkim/keyfiles/domain.tld/mail.private

Das „%“ in diesem Beispiel ist ein Platzhalter für die jeweilige Domain. Es werden daher alle Domains mit dem privaten Schlüssel signiert, welcher unter /etc/opendkim/keyfiles/domain.tld/mail.private liegt. Als selector wird „mail“ verwendet. Sollte man für jede Domain einen anderen Key verwenden, was auch im Normalfall so ist, dann kann man einfach folgende Änderungen vornehmen:

mail._domainkey.domain1.tld domain1.tld:mail:/etc/opendkim/keyfiles/domain1.tld/mail.private
mail._domainkey.domain2.tld domain2.tld:mail:/etc/opendkim/keyfiles/domain2.tld/mail.private

Kommen wir zum SigningTable. Hier wird festgelegt, welche Mails mit welchem Eintrag im KeyTable signiert werden.

*@domain1.tld mail._domainkey.domain1.tld
*@domain2.tld mail._domainkey.domain2.tld

Auch hier kann man aber mit Wildcards und Platzhaltern arbeiten und Beispielsweise folgenden Eintrag setzen.

* mail._domainkey.%

Damit wird jede Mail signiert, mit mail._domainkey.<Name der Domain>
Will man nun noch postfix mit opendkim verbinden, ist es relativ einfach. Hier werden einfach entsprechende Einträge in der /etc/postfix/main.cf angehängt:

milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:10080
non_smtpd_milters = inet:localhost:10080

Danach einfach noch beide Services restarten und schon werden alle Mails entsprechend signiert.

DMARC – Domain-based Message Authentication, Reporting & Conformance

Mit DKIM und SPF haben wir schon zwei Mechanismen, mit denen ich als Absender gewisse Informationen weitergeben kann. Was der Empfänger damit anstellt ist jedoch ihm selbst überlassen. Lehnt Mailserver A eine Mail ab, weil der SPF Check fehlschlägt, lässt Mailserver B die Mail mit höherem Spamscore vielleicht durch. Die Bewertung liegt beim Empfänger, der neben SPF und DKIM noch viele weitere Checks implementiert hat um Spam entsprechend abzuwehren. Die Entscheidung, was nun mit der Mail im besten Fall passieren soll, soll DMARC dem Empfänger erleichtern und dem Sender ein wenig mehr Möglichkeiten geben.
Als Absender hinterlege ich im DNS einen entsprechenden Eintrag. Hier gibt es einige Variablen und zugehörige Optionen, die man setzen kann. Der Empfänger hingegen kann diese Empfehlung, die vom wirklichen Inhaber der Domain kommt nutzen um zu entscheiden was er mit der Mail passieren soll. Der DMARC Eintrag von Google sieht Beispielsweise wie folgt aus:

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com

Dies dient lediglich als Beispiel, wer mehr über die Parameter und Optionen lesen möchte sollte den zugehröigen RFC7489 genauer ansehen
Damit ist auch schon alles getan, was man als Absender machen kann. Wichtig dabei ist der p-Parameter, der auf none (keine Aussage, Entscheidung liegt weiter beim Empfänger), quarantine (Dem Empfänger wird geraten bei einem fehlerhaften Check die Mail als Spam zu betrachten und ggf. in einen Spamordner zu verschieben), oder reject (Die Mail soll auf SMTP Ebene bereits abgelehnt werden) gesetzt werden kann. Es ist schwer hierbei eine Empfehlung oder ähnliches auszusprechen, da es immer auf den Fall an sich ankommt, welche Features man von DMARC im gegebenen Szenario verwenden möchte.

OpenDMARC mit Postfix verbinden

apt-get install opendmarc

Anschließend editieren wir die Datei /etc/default/opendmarc. Hier sind schon einige Beispiele angegeben und sind auch sehr selbsterklärend. Wir tragen folgendes ein:

SOCKET=“inet:12345@localhost“

Nun editieren wir noch die Konfiguration von DMARC, welche unter /etc/opendmarc.conf zu finden ist.

AuthservID mx.domain.tld
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
SyslogFacility mail
TrustedAuthservIDs localhost,mx.domain.tld
IgnoreHosts /etc/opendmarc/ignore.hosts
UMask 002
UserID
FailureReports false
AutoRestart true
HistoryFile /var/log/opendmarc.log
RecordAllMessages true
SoftwareHeader true

Danach editieren wir noch /etc/opendmarc/ignore.hosts

127.0.0.1

Die Option „SoftwareHeader true“ ist eher für eure ersten Tests von Vorteil, da ihr in einem weiteren Header die verwendete Version und verarbeitete E-Mail sehen könnt:

DMARC-Filter: OpenDMARC Filter v1.3.1 mx.domain.tld A3DF6FFB75

Anschließend geht es an die Integration von OpenDMARC in Postfix. Da es sich hierbei um einen Mailfilter handelt, wird er an der bereits bekannten Stelle in der main.cf nach unserem DKIM Milter eingetragen.

smtpd_milters = inet:localhost:10080, inet:localhost:12345
non_smtpd_milters = inet:localhost:10080, inet:localhost:12345

Danach starten wir OpenDMARC und restarten Postfix. Nun sollten E-Mails einen Header enthalten, der in etwa so aussieht, falls der DMARC-Check erfolgreich war:

Authentication-Results: mx.domain.tld; dmarc=pass header.from=sender-domain.tld

Angemerkt sei, dass opemdmarc seit Version 1.3 auch selbst SPF Checks ausführen kann, falls es also bei jemandem Probleme geben sollte mit postfix-policyd-spf, kann auch der eigene SPF Check verwendet werden.

Fabian Rothlauf

Manager MyEngineer

Lies mehr von Fabian und triff unser Team

Postfix – TLS / SSL Verschlüsselung aktivieren

von Fabian Rothlauf | Okt 18, 2017 | Technology, Web Services

In aller Munde ist es stets, dass man verschlüsselte Verbindungen nutzen soll. Auch beim Versand von E-Mails sollte man auf Verschlüsselung setzen, damit die Kommunikation entsprechend sicher abgewickelt wird. Auch Postfix bietet diese Möglichkeit.

Verschlüsselung der Verbindung zwischen Client und Server

Bei Ubuntu werden standardmäßig einige selbstsignierte Zertifikate mitgeliefert, welche per Default auch schon im Postfix hinterlegt sind.

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

Benutzt man diese, kommen bei allen gängigen E-Mail Clients jedoch Hinweise, dass die Verbindung eventuell nicht sicher sei. Beseitzt man kein gültiges Zertifikat, kann man hier auch ein Zertifikat von LetsEncrypt verwenden. Mehr dazu kann man auch im Artikel „kostenfreie TLS-Zertifikate mit Let’s Encrypt“ lesen. Wie man ein konstenpflichtiges Zertifkat erwerben kann, wird zudem im Artikel „SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern“ beschrieben. Alternativ kann hierzu auch unser Support kontaktiert werden.
Anschließend ist die Option smtpd_tls_security_level zu befüllen – per Default ist diese nicht gesetzt.

smtpd_tls_security_level = may

Durch „may“ wird besagt, dass TLS Verschlüsselte Clients unterstützt werden, es aber nicht zwingend notwendig ist. Wer TLS Verschlüsselte Kommunikation forcieren möchte, kann hier entsprechend „enforce“ setzen, damit es erzwungen wird und Clients immer verschlüsselt mit dem Server Kommunizieren. Damit wäre es grundlegend getan, man sollte jedoch noch darauf achten gewisse SSL Versionen, sowie Cipher zu verbieten, da diese schon etwas älter sind und daher nicht mehr als sicher gelten. Anbei eine Beispielkonfiguration, diese muss je nach Endgerät ggf. auch angepasst werden.

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA
smtpd_tls_mandatory_exclude_ciphers = ECDHE-RSA-RC4-SHA

Möchte man zudem die TLS Informationen auch im Header sehen, kann man noch folgende Option setzen:

smtpd_tls_received_header = yes

Verschlüsselung der Verbindung zwischen Servern

Damit wäre die Client <-> Server Kommunikation soweit verschlüsselt und viele denken sich sicher, das wäre es. Zwischen Mailservern findet aber natürlich ebenfalls Kommunikation statt, welche verschlüsselt werden soll. Dies wird entsprechend wie folgt aktiviert:

smtp_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtp_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtp_tls_security_level=may

Ähnlich wie bei der Client-Server-Kommunikation wird auch hier durch „may“ besagt, dass Verschlüsselung genutzt wird insofern es möglich ist. Im Header kann man dies nun auch nachvollziehen, indem man nach ähnlichen Daten sucht:
Ohne Verschlüsselung (smtp_tls_security_level=none):
Received: from mail.domain1.tld (mail.domain1.tld [1.2.3.4]) by mail.domain2.tld (Postfix) with ESMTP id 1234567890
Mit Verschlüsselung (smtp_tls_security_level=may):
Received: from mail.domain1.tld (mail.domain1.tld [1.2.3.4]) by mail.domain2.tld (Postfix) with ESMTPS id 1234567890

Verschlüsselung der IMAP Verbindung

Damit wären wir fertig mit Postfix. Anbei noch einige Informationen für jene, die Dovecot nutzen um E-Mails von Ihrem Server per IMAP abzurufen, denn diese Verbindungen wollen ja auch noch verschlüsselt werden. Dies funktioniert sehr simpel – die Konfigurationen dafür finden wir normalerweise unterhalb von „/etc/dovecot/conf.d/„, meist handelt es sich dabei um die Datei „10-ssl.conf„.
Dort editieren, bzw. erweitern wir unsere entsprechenden Konfigurationen um folgende Zeilen:

ssl = yes
ssl_cert = </etc/ssl/certs/ssl-cert-snakeoil.pem
ssl_key = </etc/ssl/private/ssl-cert-snakeoil.key

Zudem nehmen wir noch einige Feinjustierungen vor, wie bereits zuvor bei Postfix. Beachten sollten wir aber, dass sich die Cipher-Liste je nach Endgerät auch ändern kann und man diese etwas anpassen muss. Diese dient hier nur als Beispiel.

ssl_protocols = !SSLv3 !SSLv2
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
ssl_dh_parameters_length = 2048

Auch hier gilt: Hat man bereits ein gültiges Zertifikat, kann man dieses hier gerne verwenden um Fehler im E-Mail Client zu verhindern. Nun ist noch in der „10-auth.conf“ die folgende Einstellung wichtig:

disable_plaintext_auth = no

Damit wird ein ähnlicher Effekt erzielt, wie bereits bei Postfix wenn wir „may“ als Option gesetzt haben. Wir können nun TLS nutzen, müssen es aber nicht zwingend. Wer hier auf absolute Nummer sicher gehen möchte, kann natürlich auch hier „yes“ setzen.
Mit „dovecot -n“ können wir die aktiven Einstellungen überprüfen.

Fabian Rothlauf

Manager MyEngineer

Lies mehr von Fabian und triff unser Team

Postfix – Fine tuning für bessere Performance

von Fabian Rothlauf | Okt 4, 2017 | Web Services

Postfix ist von grundauf schon recht schnell. E-Mails werden in einer Queue abgelegt und dort entsprechend der Reihe nach abgearbeitet, dennoch gibt es auch hier und dort gewisse Optimierungen, um zum Beispiel beim Versand von Newslettern etwas schneller zu sein. Wir möchten hierbei aber auch darauf hinweisen, dass manche dieser Einstellungen dazu führen, dass Mechanismen von Postfix außer Kraft gesetzt werden, die dafür da sind den Server vor Überlastung zu bewahren. Daher sollte man schon wissen was genau man macht und nicht alles kopieren, ohne sich Gedanken gemacht zu haben, was es bewirkt.
Fangen wir an, bei der Annahme neuer E-Mails. Standardmäßig akzeptiert Postfix je Prozess neue Mails, bevor diese intern weiter verarbeitet werden. Um diese Zahl zu erhöhen, kann man einfach die Anzahl der Prozesse erhöhen – per Default sind 100 gesetzt. Dies passiert mit folgendem Parameter:

default_process_limit = 150

Dieser Erhöht wohlgemerkt jegliche Prozesse von Postfix, möchte man diese genauer steuern, kann man diese in der master.cf ebenfalls anpassen. Man sollte jedoch immer die Auslastung des Systems im Auge behalten, beispielweise mit Icinga oder um direkte Vergleiche zu sehen mit Graphite, da man unter Umständen den Server überlastet. Daher sollte dieses Limit Schrittweise erhöht werden.
Danach schauen wir uns die Annahme des Postfix etwas genauer an. Hier gibt es zwei Anlaufstellen, die man sich etwas genauer ansehen sollte. Zum einen kommt hier tar pitting zum Einsatz, dem ein oder anderem sicher ein Begriff. Im Grunde wird dabei die Kommunikation zwischen Server und einem unerwünschten Client künstlich verlangsamt. Dies führt dazu, dass der fehlerhafte Client, oder ein Spammer nicht einfach so den Server überlasten kann. Dennoch bleibt der Postfix Prozess dadurch blockiert. Da wir annehmen, dass wir dem Client vertrauen – zum Beispiel, da die Mails auch nur in einem internen Netzwerk angenommen werden, deaktivieren wir dieses Feature:

smtpd_error_sleep_time = 0

Zum anderen wird die Annahme neuer Mails ebenfalls begrenzt, wenn ein Client zuviele Connections öffnet. Dies ist durchaus gut im Normalfall, in unserem speziellen Fall wollen wir jedoch auch diesen Wert deaktivieren, da alle Connections angenommen werden sollen. Zum anderen deaktivieren wir auch das Throttling neuer Verbindungen des clients.

smtpd_client_connection_count_limit = 0
smtpd_client_connection_rate_limit = 0

Damit nehmen wir nun alles an, egal wieviel kommt, damit alle Prozesse ausgelastet werden und verzögern auch keine neuen Verbindungen.
Kommen wir zum Versand an die selbe Domain. Vor allem bei Newslettern ist es oftmals der Fall, dass gleich mehrere tausend Empfänger die selbe Domain betreffen, wie Beispielsweise gmail.com. Während Postfix nun mit mehreren hundert Prozessen laufen kann, ist es jedoch nicht anzuraten den Mailserver der Empfänger mit mehreren hundert Verbindungen zu penetrieren. Dafür sind die folgenden Einstellungen wichtig:

initial_destination_concurrency = 5
default_destination_concurrency_limit = 20

Dabei handelt es sich um die Defaultwerte, man kann hier mit default_destination_concurrency_limit etwas „spielen“, damit Beispielsweise mehr Mails in einem Schwung an eine Domain verschickt werden, kann man diesen Wert erhöhen. Oftmals wird auch davon gesprochen die Queue einfach öfter abzuarbeiten, als per Default gesetzt ist. Mechanismen wie Greylisting verhindern jedoch, dass diese Einstellung einen großen Effekt erzielt, da die Mail vom empfangenden Mailserver widerum abgelehnt werden würde.
Anschließend kann man die aktiven Einstellungen per postconf überprüfen. Möchte man noch einige Sekunden mehr gewinnen, kann man sich auch noch Gedanken machen, ob ein Caching Nameserver dies ermöglichen kann, damit Anfragen optimiert werden können.

Fabian Rothlauf

Manager MyEngineer

Lies mehr von Fabian und triff unser Team

NETWAYS stellt sich vor – Fabian Rothlauf

von Fabian Rothlauf | Jan 26, 2017 | Team, Serien, NETWAYS

This entry is part 19 of 55 in the series NETWAYS stellt sich vor

Name: Fabian Rothlauf

Alter: 31
Position bei NETWAYS: Systems Engineer im Hosting Support
Bei NETWAYS seit: September 2016
Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?
Primär geht es bei uns im Hostingsupport darum, unsere Kunden bei Problemen zu unterstützen, oder bestenfalls diese Probleme frühzeitig zu erkennen um entsprechende Gegenmaßnahmen einleiten zu können. Aber nicht nur wenn unsere Kunden Probleme haben sind wir der direkte Ansprechpartner, sondern beraten und unterstüzen diese auch bei jeglicher Planung neuer Vorhaben.
An welchen Projekten arbeitest Du gerade?
Erst letzte Woche habe ich ein Projekt abgeschlossen, bei dem es darum ging im Auftrag einer unserer Hostingkunden, ein Cluster zu realisieren, welches bei einem Event von Skoda in Portugal zum Einsatz kommt. Ungewöhnlich, wenn man glaubt, dass wir nur für „Hosting“ zuständig seien, aber genau das ist es was den Beruf ausmacht und ihn vor allem bei NETWAYS so attraktiv gestaltet.
Welche größeren oder besonders interessanten Projekte stehen zukünftig an?
In naher Zukunft steht die Migration eines Kunden mit rund 50 Servern unterschiedlicher Arten auf dem Plan – es wird also definitiv nicht langweilig.
Was macht Dir an Deiner Arbeit am meisten Spaß?
Ich bekam mit ganzen fünf Jahren meinen ersten Computer und erledige seit meinem 16. Lebensjahr – damals noch sehr Laienhaft – unterschiedliche Aufgaben, welche sich um Serveradminstration drehen. Es war also relativ früh schon klar, wohin mein Weg wohl einmal führen würde. Das Beste an unserem Beruf ist: Man lernt nie aus. Neue Technologien und neue Herausforderungen zusammen mit einem weiten Spektrum an unterchiedlichen Kundensetups lassen es praktisch nicht zu, dass sich ein gewisser Alltag, oder gar Stillstand einfindet. Ich mag es morgens zur Arbeit zu kommen und eben nicht zu 100% zu wissen was mich erwartet. Was mich bei NETWAYS überrascht hat, ist der familiäre Umgang untereinander, durch den man sich auch als Neuling gleich fühlt als würde man schon ewig hier arbeiten.
Was machst Du, wenn Du mal nicht bei NETWAYS bist?
Selbst mit meinen mittlerweile 31 Jahren habe ich mein Hobby, welches mich auch zur Serveradministration brachte, nie aufgegeben – Onlinespiele, vorzugsweise World of Warcraft, Overwatch oder DayZ. Komme ich dann doch mal vom PC weg, dann genieße ich die meiste Zeit mit meiner Lebensgefährtin, oder versuche meine „Couchpotatoe“ von Hund, einem in die Jahre gekommenen Mops, dazu zu bewegen sich doch mal aus dem Haus zu wagen.
Wie geht es in Zukunft bei Dir weiter?
Beruflich gesehen sehe ich nach nur wenigen Monaten meine berufliche Zukunft defintiv bei NETWAYS, ich müsste ehrlich gesagt von allen guten Geistern verlassen sein, etwas anderes anzustreben, nachdem ich hier nicht nur herzlich aufgenommen wurde, sondern mir jegliche Wege sowohl beruflich und fachlich weiterzukommen offen stehen.