Ja. Basis ist noch AlmaLinux 8, darum muss ich auch bald ran 
Beiträge von daq4th
-
-
Man sollte auch ungefähr wissen, welche Bausteine man zusammenstecken will.
- Postfix als SMTP
- Amavis für AV und Spam-Filter eingehend?
- dovecot als IMAP/POP3
- Alles TLS mit LE-Zertifikaten?
- Amavis ausgehend für DKIM Signierung?
- Übergabe Postfix und dovecot mit LMTP?
- Mailfilter mit sieve?
- Webmailer als alternative Oberfläche? mit 2FA?
- ...
Das sind in der Regel mehr als eine Anleitung, da kenne ich keine die alle Bausteine vollständig abbildet.
-
Alles anzeigen
https://std.rocks/linux-mail-server-postfix-dovecot.html ... jesus...
https://www.debianadmin.com/debian-mail-se…irrel-mail.html ...alter ...
ok - ich fang mit dieser an und postfix.org zum nachschlagen
https://www.splitbrain.org/blog/2008-01/3…_on_debian_etch
Thema ist dann ja wohl erledigt.
Ich poste den Fehler wenn ich ihn gefunden habe hier.
Die AI hat diese Anleitung sicher auch gelesen
Die Frage ist, wie sie diese Anleitungen mit den anderen Anleitungen geremixt hat ...
-
Nur für mich: Warum fetchmail? Das ist für mich nicht "empfangen" ...
Ansonsten: logfiles postfix und dovecot würde ich lesen wollen, nicht abrufprotokolle auf leere postfächer ...
-
oje, backscatter gleich vorprogrammiert.
Ja, oder man macht es richtig. Vorne nix annehmen was man hinten nicht verarbeiten will ist schon mal hilfreich.
-
Nein, man kann MX und Versand trennen, wird auf VPS meist nicht gemacht, weil sonst bräuchte ich zwei VPS oder eine zweite IP.
MX ist Port 25 aktiv, Versand ist in der Regel submission 587. Früher hat man alles auf 25 gemacht, darum brute forcen sie auf 25 rum, weil es noch genügend oldschool setups gibt. Der Versand-Server steht dann eben im SPF als authorisierter Versender.
Optimal hat man zwei 1€ server bei unterschiedlichen Anbietern, die als MX fungieren und dem eigentlichen Mail-Server die Mails übergeben. Mail-Storage und Mail-Versand laufen über den Mail-Server, der dann eben keinen Port 25 eingehend braucht. Und wenn er gewartet wird, queuen die beiden MXe. Und wenn der Anbieter mit dem Mailserver sein Netz verbuchselt, gibts noch einen Ersatz MX bei einem anderen Anbieter. Somit hab ich die Queues selbst im Griff und bin nicht auf die Einstellungen der sendenen Server angewiesen.
-
Die zählen ja nicht, da diese ja (hoffentlich) zu 100% geblockt werden. Es muss/sollte am SMTP nichtmal der Port 25 geöffnet sein.
Doch Port 25 ist zum Annehmen von Mails aus diesem Internetz schon notwendig, aber Versand und Relay und Auth sind gar nicht erst aktiviert. Da können sie AUTH probieren, sooft sie wollen.
-
Wenn ich so schaue, wer sich alles an meinem SMTP abmüht, dann ist der Versand wohl das Thema. 30000 bis 120000 erfolglose Anmelde-Versuche am Port 25 oder am submission Port am Tag sind da so die Regel.
Die paar Anmeldeversuche direkt am IMAP sind da eher vernachlässigbar, so 0 bis 350 am Tag.
Webmail-Anmeldungen ist dann nochmal ein anderes Thema.
In der Regel werden solche Systeme nur zum Versand weiterer Spams genutzt und zack ist die Reputation ruiniert.
Mit Postfach-Zugriff andere Accounts zurücksetzen zu lassen ist viel zu aufwändig, ausser es geht um gezielte Angriffe.
-
Was dein IDP unterstützt, in der Regel TOTP, andere Varianten je nach IDP. Da kannst du schauen was beispielsweise keycloak kann.
Knackpunkt sind eher die MUAs, weil die meist nur die Anmelde-Prozedur von EntraID und Google unterstützen, die Unterstützung für generische IDPs fehlt oft.
Vielleicht ein Projekt für 2026, um den Serverteil mal aufzusetzen. Jemand Pikos übrig?
-
Ja, aber die Ausstellung des Tokens und die VAlidierung kann an Dinge wie 2FA oder MFA geknüpft sein.
-
So wie Microsoft sein IMAP und SMTP über OAUTH2 schützt, kann das mittlerweile auch dovecot:
https://doc.dovecot.org/latest/core/config/auth/databases/oauth2.html
Dazu braucht es halt dann auch FreeIPA oder Keycloak oder sowas als OAUTH2 Provider.
Das 2FA steckt dann im OAUTH2.
Das geht schon, braucht halt ein wenig mehr Aufwand.
-
Du hast im Formular (Screenshot #7) keinen Absender definiert. Den solltest du setzen, in der Hoffnung, dass diese Adresse auch für den Envelope verwendet wird. Für diese Domain müssen dann DMARC und SPF korrekt gesetzt sein.
DMARC dient nur der DKIM+SPF Verifizierung, in der Regel gesetzt auf "wenigstens eines muss erfüllt sein".
Wenn das System lokal versendet muss es mit der IP (v4 und v6) in den SPF Record aufgenommen werden, um das zu erfüllen.
-
- dns
- vorgelagerter MX
- statischer Webserver
- znc
- jumphost
-
Da der MX für die Zone schon v1202511316580408226.yourpserver.net ist, braucht er das System nicht dreimal freischalten, einmal via mx reicht. Die beiden A: Einträge helfen hier nicht weiter.
-
Ich kann technisch auch nichts negatives finden.
Mit hoher Wahrscheinlichkeit haben die bei GMX eine Menge Domains oder Muster auf der Blocklist.
Die Änderung des DNS-Namen mit allen Konsequenzen scheint umungänglich.
Ob es den fairen Wettbewerb behindert müssen Juristen klären
-
Es immer schwierig ohne konkrete Namen/IPs die Details zu analysieren, aber hier nochmal die gängigsten Probleme:
Der Rev-Lookup (ip) und der Fwd-Lookup (dnsname) sollten matchen. Wenn ipv4 und ipv6 konfiguriert sind, muss das auf beiden Ebenen passen.
Zusätzlich sollte der HELO des Mailservers auch noch dieser Name sein.
Die anderen Domains legitimierst du am besten mit einem SPF-Record "v=spf1 mx ~all" für den Mailversand durch dieses System, wenn der MX-Eintrag für die Domain das angegebene System ist.
Soweit mal die üblichen Hinweise.
-
Hat hier noch jemand deutlich spürbaren Packet Loss im Nürnberger RZ? Seit gestern betrifft das mehrere vServer aus verschiedenen Generationen, egal ob IPv4 oder IPv6, selbst das Cloud vLAN ist betroffen. Es betrifft sowohl den externen als auch RZ-internen Traffic, aber nicht zwischen allen vServern.
Meine Smokeping-Installationen zeigen erneut nicht viel an, weil es genau diese Verbindungen wohl nicht betrifft oder es dabei nicht lange genug läuft…
Ich sehe aus dem Netz der Telekom einige Verluste, allerdings auf Telekom-Seite:
Code
Alles anzeigen$ mtr -n --tcp --report xxx Start: 2025-12-15T07:31:22+0100 HOST: yyy Loss% Snt Last Avg Best Wrst StDev 2.|-- 2003:0:8a03:1000::1 0.0% 10 9.2 9.9 9.1 10.9 0.7 3.|-- 2003:0:1304:8024::1 70.0% 10 3073. 1033. 13.5 3073. 1766.8 4.|-- 2003:0:1304:8024::2 50.0% 10 7198. 2069. 12.8 7198. 2990.9 5.|-- 2a02:2d8::57f5:e08c 0.0% 10 15.4 15.7 15.0 16.4 0.4 6.|-- 2a02:2d8:0:4813:232a::1 0.0% 10 17.6 19.6 15.4 27.4 4.5 2a02:2d8:0:4818:232a::1 7.|-- 2a00:11c0:47:3::121 0.0% 10 16.5 27.1 16.5 37.9 7.0 2a00:11c0:47:3::123 $ mtr -n -4 --tcp --report xxx Start: 2025-12-15T07:34:21+0100 HOST: yyy Loss% Snt Last Avg Best Wrst StDev 2.|-- 62.155.245.100 0.0% 10 10.1 10.9 9.8 12.1 0.8 3.|-- 62.154.3.38 0.0% 10 13.3 13.5 12.1 15.7 1.1 4.|-- 80.156.160.126 30.0% 10 3113. 1043. 12.7 3113. 1191.1 5.|-- 87.245.234.67 0.0% 10 15.4 17.5 14.9 32.9 5.5 6.|-- 87.245.246.141 0.0% 10 23.2 30.5 22.8 51.3 11.3 87.245.240.71 7.|-- 94.16.25.159 0.0% 10 19.8 27.3 15.4 65.1 14.6 94.16.25.155 -
Nur so am Rande: Wer autoritative DNS als Einzelunternehmer oder Kleinunternehmen für seine Kunden macht, ist auch von der NIS-2 Regulierung betroffen.
-
Beim Umzug einer Domain ist es auch immer wichtig zu wissen, wie ich mit den Nameservern umgehen muss.
Es gibt Anbieter die werfen den Nameserver im Moment des Transfer-Out weg, andere lassen ihn noch liegen. Andere Anbieter erlauben das Anlegen der neuen Zone vor dem Transfer, andere wiederum nicht.
Hier muss man seine "Spezialisten" kennen und eben auch entsprechend auch den Transfer entsprechend planen. DNS zuerst umziehen oder hinterher ist manchmal auch entscheidend für die Erreichbarkeit.
-
Nein, ein 1m³ Cube aus Beton.
Der AI-Overlord sagt 1,5 kg sind zu wenig:
ZitatEin Kubikmeter Beton wiegt je nach Art typischerweise zwischen 2.000 und 2.600 kg. Der Durchschnittswert für Normalbeton liegt bei etwa 2.400 kg, während Leichtbeton zwischen 800 und 2.000 kg und Schwerbeton über 2.600 kg wiegt. Die genaue Dichte hängt von den verwendeten Zuschlagstoffen und dem Wassergehalt ab.
