Eigener Mailserver

  • Was noch viel lustiger ist (das ist mir letztens mehrmals passiert): Appliance lehnt Mails von mir an Firma X ab. Begründung: Kein ausreichender positiver Mailscore für die Absenderdomain sowie IP-Adresse. Positiver Mailverkehr erhöht den Score. Mit der Zeit "verblasst" der Score. Mein Score: 0 für die IP, 0 für die Mailadresse, 0 für die Domain. Es hätte noch nie Mailverkehr stattgefunden.


    Was war mein Anliegen: Es kommen weder Bestellbestätigungen noch Rechnungen bei mir an.


    Reaktion der Firma: Ja, viele Mails bouncen bei uns. Sie sind nicht für uns nicht erreichbar. Sie sind kein Einzelfall. Das wurde vor kurzem an einen externen Dienstleister outgesourcet.

  • Mit SPF habe ich bereits getestet, bei manchen Anbietern scheitert man ja schon an den Namen der Mailserver von netcup "mxxxx.netcup.de" lehnt zum beispiel GMX folglich ab

  • Ich hab nach 3.5 Jahren meinen Mailserver endlich perfekt eingerichtet (naja fast, ViMbAdmin möchte ich loswerden) und überlege mir jetzt, auf mailcow (dockerized) umzusteigen...


    Alles selbst aufzusetzen ist schon recht viel Aufwand, mit all den Tools die involviert sind.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Ich erlaube mir mal diesen alten Thread wiederzubeleben, da er genau zu meiner Frage passt:


    Wie genau gehe ich vor, wenn ich einen Mailserver per Failover IP "absichern" will?

    - Lasse ich dann den identischen Mailserver auf zwei Hosts laufen?

    - Wird die Failover IP dann im DNS-Record eingetragen und bedient beide Server? Bzw. wie wird das priorisiert? Ich nehme ja an, dass ein Server quasi der Master ist und der andere nur zum Zug kommt, wenn der andere down ist.

    - Müssen dann die Daten des Mailservers (die Mails halt) an einer zentralen Stelle gespeichert werden, damit beide auf den selben Datensatz zugreifen?


    Wie ihr seht, habe ich das Konzept noch nicht ganz verstanden... Bin für Aufklärung schon mal dankbar.

  • Wie ihr seht, habe ich das Konzept noch nicht ganz verstanden... Bin für Aufklärung schon mal dankbar.

    Eine Möglichkeit könnte sein, zwei im wesentlichen identisch aufgesetzte Server zu benützen, die einen gemeinsamen DRBD-Spiegel benützen (also einen Teil ihrer Partition als Storage zur Verfügung stellen, der über DRBD permanent synchronisiert wird). Das ist quasi ein Netzwerk-Raid.

    Voll aktiv ist immer nur einer der beiden Server. Fällt dieser Server aus, was der zweite über heartbeat detektieren könnte, holt er sich die Failover-IP (via API) und setzt fort. Dazu greift dann auf seine Kopie des synchronisierten Storage zu und startet die Maildienste.

    Alternativ, ohne DRBD könnte der Storage auf einem dritten Server liegen (SPoF!) oder netcup-NFS-Storage sein. NFS hat aber so seine Nachteile.

    Damit das klappt, ist die Failover-IP als A/AAAA eingetragen, auf die der MX mit der niedrigsten nummerischen Priorität zeigt.

    http://www.linux-ha.org/wiki/Heartbeat/

    https://docs.linbit.com/docs/users-guide-9.0/

  • Danke für die Erklärung, von Heartbeat hatte ich schon gelesen, das übersteigt aber aktuell noch meinen Horizont. Die Hälfte deines Beitrags verstehe ich nicht ;)

    Für das DRBD bräuchte ich dann wohl auch ein vLAN zwischen den beiden Servern, oder?

    Ich werde mich weiter einlesen und erstmal versuchen, meinen Server nicht mehr am Tag zu warten :D

  • Servus. Ich möchte nicht deine Entscheidungen in Frage stellen aber dennoch den gut gemeinten Tipp anbringen, einen Mailserver nicht zu clustern. Das macht im kleineren Rahmen in meinen Augen nur für IMAP/POP3 Systeme Sinn und auch nur dann, wenn es sich dabei um kritische Infrastruktur handelt die keine Ausfälle von um die 30 Minuten verkraftet.


    Das Clustern von E-Mail Systemen birgt viele Stolpersteine und Gefahren und auf jeden Fall auch eine deutliche Erhöhung des Administrationsaufwands mit sich.


    Es kann zu Splitbrain Situationen in der Datenbank kommen, das zweite System kann schlechter Spam filtern weil die Synchronisation der Filterregeln nicht klappt, usw..


    Gerade bei Mail, bei der ein Server bis zu 4 Tage unerreichbar sein kann und lt. RFC dennoch alle Mails zugestellt bekommt ist es meines Erachtens nach total sinnlos.


    Solltest du deine MX doppelt auslegen kann die Übermittlung zum IMAP Server fehlerhaft sein, was du eventuell nicht mitbekommst weil über den ersten MX eh alles normal reinkommt. Das kann auch rechtlich relevant sein, weil die Mail in dem Fall als zugestellt gilt.

  • Coxeroni ist bei kleineren Setup relativ unnötig. (Und bei klein rede ich von 100.000 Nutzern).


    Dovecot unterstützt eine eventbasierte Replizierung aller E-Mails zwischen zwei Sytemen. Da brauchst du also keine Blockreplizierung o.Ä.

    Die SMTP Server kannst du mit mehreren MX Records eintragen. Fällt einer aus, gehen die Mails an den anderen.


    Habe ich so auch im Einsatz. User DB ist ein LDAP Cluster.


    https://www.heinlein-support.d…cote_einfach_clustern.pdf

    https://wiki.dovecot.org/Replication

  • Ich danke euch, ich scheine die Kanone auf meinen Spatzenserver zu richten. Das mit den vier Tagen wusste ich zB nicht, das reicht mir ja für meine Zwecke völlig. Dachte das hängt an der config des Absenders bzw dessen Servers.

    Dann lege ich dieses Projekt wieder zu den Akten bevor ich es begonnen habe.

    Danke trotzdem für die lehrreichen Antworten.

  • Dachte das hängt an der config des Absenders bzw dessen Servers.

    Da bist du auch nicht falsch der RFC sieht die 4 Tage vor, allerdings kann ein „schlecht“ konfigurierter AbsenderMX auch anders handeln und keine erneute Zustellung versuchen.