Mailserverproblem. Zertifikate - Blocken einer Mail-Zustellung per SMTP an ***.live.com durch Microsoft

[Eisenacher]

ich habe die Probleme schon eine Weile ignoriert und beim Abrufen der Versenden durch Thunderbird die Ausnahme erlaubt. Problem ist folgendes auf dem ISPConfig sind mehrere Maildomains eingerichtet, die funktionieren soweit auch, der Mailserver unter mail.123.TLD hat aber folglich einen anderen Name als die Maildomains. Aus dem Grund hat Microsoft auch die Annahme der gesendeten Email auf live.com verweigert.

Was mache ich da fasch? Die Zertifikate sind alle von LetsEncrypt bei den Domains(SSH) und Webseiten funktioniert soweit auch alles.
Hat da jemand eine Idee und müsste ich da evtl ein internes Routing einrichten?

 

[Eisenacher]

Problem ist bei der Zustellung evtl DMARC fehlt

 

[Till]

Problem ist folgendes auf dem ISPConfig sind mehrere Maildomains eingerichtet, die funktionieren soweit auch, der Mailserver unter mail.123.TLD hat aber folglich einen anderen Name als die Maildomains. Aus dem Grund hat Microsoft auch die Annahme der gesendeten Email auf live.com verweigert.

Nein, das ist nicht der Grund. Es ist absolut normal und üblich dass der Hostname des mailservers nicht der maildomain entspricht. Gründe für abgelehnte Emails sind:

Fehlender oder falscher Reverse DNS Record für die IPv4 und falls vorhanden auch IPv6 Adresse. Dieser sollte mit dem Hostnamen übereinstimmen.
Fehlender SPF Record.
Keine DKIM Signierung aktiviert oder DKIM key nicht im DNS publiziert.
DMARC kann man haben, wenn man ihn nicht hat führt das aber auch nicht zur Ablehung von Emails.

 

[Eisenacher]

OK in das SPF-Thema muss ich mich noch mal intensiver einarbeiten, habe das bei einigen Maildomains auch angelegt und diese funktionieren deshalb wohl auch. Ebenso DKIM

 

[snocer]

ich finde der Hinweis mit DMARC ist gar nicht so schlecht. Den DMARC setzt DKIM und SPF voraus. Und Somit sollten alle Voraussetzungen erfüllt sein. Wichtig ist in dem Zusammenhang der Reverse DNS Eintrag, wenn der nicht stimmig ist, wird die Zustellung auch bei vielen anderen nicht korrekt funktionieren.

 

[Strontium]

https://dmarcian.com SPF, DKIM, DMARC Test

 

[Eisenacher]

https://dmarcian.com SPF, DKIM, DMARC Test

Warum ist das besser als Mxtoolbox oder warum geht es mal und dann auch wieder nicht?
Irgendwo habe ich noch n Verständnisproblem. Der Hoster, der die IP-Adresse bereitstellt ist auch der Meinung, es wäre eine Blockierung durch M$ - Der Weg zur Freischaltung führt nur über die Einrichtung eines M$-Kontos - geht es noch?
aber nichts destotrotz klemmen einige der Einstellungen.

Der Server ist ne VPS Debian 11 bei Contabo.

Das ISPConfig sowie die Aktualisierungen auf 11 Buster (war 10 vorher) habe ich selbst gemacht.
Das redirect zur IP das bei Contabo eingetragen ist lautet www.TLD.de der mailserver (Postfix) hat aber den hostname mail.TLD.de < ist das ein Fehler? Kommt deshalb gelegentlich in den Prüftools smtp email.(virtuelle)Domain.de nicht erreichbar?

Kann es sein, das ich dafür im ISPConfig die Routingfunktion einrichten und benutzen muss?

 

[snocer]

das von Strontium genannte Testtool ist nicht besser, sondern nur ein anderes. Auch dieses wird Dir keine anderen Ergebnisse liefern als mxtoolbox.com.
Meinst Du mit M$ Microsoft? Dann ist hier erst einmal grundsätzlich zu klären, Was für ein Paket hast Du gebucht? Geschäftskonto oder Privat (da wird häufig etwas getrickst von diversen Kunden). Das eine ist eine Exchange Konto das andere dann ein Imap Konto. Zum Beispiel. Wenn Du hier nicht mehr Informationen rausgibst, kann man schlecht helfen.
Und Contabo, naja geht zwar meist mehr schlecht als Recht, wir betreiben zwar auch einiges bei Ihnen, das ist aber eher eine preisliche und weniger sensible Sache. Häufig mussten wir Ihnen auch schon Ihre Fehler vorkauen. Teilweise konnten unsere Cloud Kunden über mehrere Stunden ihre Cloud nicht erreichen, öfter mal zwischendurch einfach auch mal weg, und auch mal 4 Tage am Stück weg. Alles schon erlebt, Contabo. Nur wen es nicht anders geht sonst lieber woanders. Dein Problem scheint aber eher an fehlender Einrichtung M$ zu liegen. Aber wie gesagt alles noch Spekulation ohne entsprechende Infos.

Reverse DNS Einträge bei Contabo geprüft?

 

[Eisenacher]

das von Strontium genannte Testtool ist nicht besser, sondern nur ein anderes. Auch dieses wird Dir keine anderen Ergebnisse liefern als mxtoolbox.com.
Meinst Du mit M$ Microsoft? Dann ist hier erst einmal grundsätzlich zu klären, Was für ein Paket hast Du gebucht? Geschäftskonto oder Privat (da wird häufig etwas getrickst von diversen Kunden). Das eine ist eine Exchange Konto das andere dann ein Imap Konto. Zum Beispiel. Wenn Du hier nicht mehr Informationen rausgibst, kann man schlecht helfen.
Und Contabo, naja geht zwar meist mehr schlecht als Recht, wir betreiben zwar auch einiges bei Ihnen, das ist aber eher eine preisliche und weniger sensible Sache. Häufig mussten wir Ihnen auch schon Ihre Fehler vorkauen. Teilweise konnten unsere Cloud Kunden über mehrere Stunden ihre Cloud nicht erreichen, öfter mal zwischendurch einfach auch mal weg, und auch mal 4 Tage am Stück weg. Alles schon erlebt, Contabo. Nur wen es nicht anders geht sonst lieber woanders. Dein Problem scheint aber eher an fehlender Einrichtung M$ zu liegen. Aber wie gesagt alles noch Spekulation ohne entsprechende Infos.

ja mit M$ ist Kleinweich gemeint. Zuerst habe ich für das hier aufgetretene Problem keinen M$-Account (oder doch, aber noch nicht in Betracht gezogen), weil es eigentlich nicht sein kann, das man einem Empfänger mit hotmail/outlook.com-Mailadresse eine Email schickt, die 2 Mal ankommt und dann mein Absender dort geblockt wird.
hier die Meldung:

<dRN00b@hotmail.de>: host eur.olc.protection.outlook.com[104.47.18.161] said:
550 5.7.1 Unfortunately, messages from [93.104.210.xxx] weren't sent.
Please contact your Internet service provider since part of their network
is on our block list (S3150). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors.
[AM7EUR06FT063.eop-eur06.prod.protection.outlook.com
2023-06-14T21:16:33.368Z 08DB6C885FFCFEC2] (in reply to MAIL FROM command)

Reporting-MTA: dns; web-***.xx-xx.de
X-Postfix-Queue-ID: 84EBF2582852
X-Postfix-Sender: rfc822; info@***************.de
Arrival-Date: Wed, 14 Jun 2023 23:16:32 +0200 (CEST)

Final-Recipient: rfc822; dRN00b@hotmail.de
Original-Recipient: rfc822;dRN00b@hotmail.de
Action: failed
Status: 5.7.1
Remote-MTA: dns; eur.olc.protection.outlook.com
Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [93.104.210.xxx]
weren't sent. Please contact your Internet service provider since part of
their network is on our block list (S3150). You can also refer your
provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
[AM7EUR06FT063.eop-eur06.prod.protection.outlook.com
2023-06-14T21:16:33.368Z 08DB6C885FFCFEC2]


Einen derartigen Eindruck habe ich von Contabo leider auch. Das Einfache, was ich selbst kann, dafür benötige ich ja keinen Support. Aber schließlich läuft der VServer auf Deren Infrastruktur, auf die ich ja weder Einfluss noch Zugriff habe. Der kleinste Fehler dort hat ja Auswirkungen, die ich nicht ändern kann.

 

[Eisenacher]

evtl. muss ich noch hinzufügen, das meine Domains bei alldomins.hosting liegen und ich auch die dortigen Nameserver verwende. Die Verweise auf den VServer bei Contabo werden dort eingestellt.

 

[snocer]

auf alle Fälle hast ja schon einmal die richtige Antwort bekommen. Die Domain des Absenders wird geblockt.
Dafür gibt es bei M$ ein Formular was Du einreichen kannst, da sind ein paar Angaben zu tätigen und das wird zu Beginn öfter angefragt, später dann seltener weil Deine Domain bereits als sicher eingestuft ist.
Das hat auch etwas damit zu tun das viele Anwender hier über hotmail, outlook.com schon besser, Schrott versenden. Hier sollen die Domain Hoster in die Pflicht genommen werden. Das Formular müsste FDNS oder so ähnlich heißen, wenn ich es noch richtig im Kopf habe.

Damit sollte dann auch die Zustellung an M$ (hotmail, outlook.com etc.) möglich sein.
Bei M365 Konten brauchst das nicht, da läuft die Authentifizierung etwas anders. Hier teilst Du M$ ja mit bei der Einrichtung und der Mxxxx Nummer das die Domain Dir gehört und danach wird der E-Mail Verkehr über die entsprechenden DNS Einträge abgewickelt.

Man schreibe ich wieder ein Haufen Zeug.

 

[Eisenacher]

auf alle Fälle hast ja schon einmal die richtige Antwort bekommen. Die Domain des Absenders wird geblockt.
Dafür gibt es bei M$ ein Formular was Du einreichen kannst, da sind ein paar Angaben zu tätigen und das wird zu Beginn öfter angefragt, später dann seltener weil Deine Domain bereits als sicher eingestuft ist.
Das hat auch etwas damit zu tun das viele Anwender hier über hotmail, outlook.com schon besser, Schrott versenden. Hier sollen die Domain Hoster in die Pflicht genommen werden. Das Formular müsste FDNS oder so ähnlich heißen, wenn ich es noch richtig im Kopf habe.

Damit sollte dann auch die Zustellung an M$ (hotmail, outlook.com etc.) möglich sein.
Bei M365 Konten brauchst das nicht, da läuft die Authentifizierung etwas anders. Hier teilst Du M$ ja mit bei der Einrichtung und der Mxxxx Nummer das die Domain Dir gehört und danach wird der E-Mail Verkehr über die entsprechenden DNS Einträge abgewickelt.

Man schreibe ich wieder ein Haufen Zeug.

Das hilft mir, denn es deckt sich mit meiner zu dem Vorgang.
Dann werd ich doch mal eines der M$-Konten dafür bemühen müssen.

Danke.

 

[Eisenacher]

den DMARC-Fehler habe ich auch beheben können. Aus dem _dmarc war ein @ geworden, damit konnte das nicht funktionieren.

 

[snocer]

Super freut mich das es nun funktioniert. Dir noch ein schönes WE.

 

[Eisenacher]

Naja so ganz richtig funktioniert es immer noch nicht.
Spamassassin?
Aber da ergeben sich auch noch andere Fragen und Probleme - das 1. Bild zeigt alles ok aber am 2. Bild zeigt es was noch klemmt. Wie stelle ich das SPF_HELO_NONE ab?
Woran liegt es, das die DKIM-Signatur nicht als gültig erkannt wird? 3. wenn in MXtoolBox der SMTP-Test mit Error endet, liegt das doch sicher am verschlossenen Port 25? (benutze ich zum Versand nicht, also bleibt er aus)

 

[snocer]

was hat Spamassasin mit Deinem E-Mail-Server zu tun? Erst einmal gar nichts. Höchstens der E-Mali-Client den Du verwendest (Thunderbird) bindet Spamassasin im Client mit ein und macht eigentlich nichts anderes, wie Dein E-Mail-Server, Abgleich mit diversen Black Listen. Prüfe über mxtoolbox etc. ob Dein E-Mail-Server irgendwo bereits gelistet ist. Laut Deinem Bild scheint das ja bereits der Fall zu sein. Dann behebe Die Ursachen und beantrage ein Withlisting für Deine IP-Adresse beim dem entsprechen Listen Betreiber.

spf und DKIM werden automatisch erstellt beim erstellen einer E-Mail Domain. Vorausgesetzt Du aktivierst DKIM auch und erstellst dabei auch den Schlüssel.

E-Mail Versand über Port 25 ist nicht glücklich gewählt, viele Anbieter wie Telekom etc. sperren von Haus aus erst einmal den Versand über Port 25 auf ihren Routern. Bei Verwendung von TLS/SSL empfiehlt es sich Port 465 oder 587 zu verwenden. E-Mails sind nur noch gesichert zu versenden (01.07.2022).

 

[Eisenacher]

lt mxtoolbox ist er nicht gelistet. alle grün
Lt. dem Test bei mail-tester.com meckert spamassassin rum, aber das scheint z.Zt. nur an DKIM zu liegen. die 24h seit der letzten Änderung sind auch noch nicht rum.

Die Schlüssel sind erstellt und aktiviert wurde es auch, nur dieser Mailtester sagt nö ist nicht "Wir bekommen den öffentlichen Schlüssel nicht"

Was den Port 25 betrifft, habe ich den abgeschaltet, da ich darüber nichts versende. Wie Du ja auch vorschlägst:

TLS/SSL empfiehlt es sich Port 465 oder 587 ist so eingerichtet. Deshalb kann MboxTools den Smtp-Test auch nicht durchführen.

 

[snocer]

siehe Bild 1, solange wie Dein smtp Test fehlschlägt, hat Du noch ein grundsätzliches Problem. Das hat primär erst einmal nichts mit dem Port 25/465/587 zu tun. Ein Port muss eben funktionieren. Und das ist bei TLS/SSL normalerweise 465 und bei StartTLS 587. Da Dein Mail-Server ja mit einem Zertifikat ausgestattet ist (gehe mal jedenfalls davon aus) kannst Du auch dieses, solltest Du auch diese Zertifikat verwenden.

dns Fehler: Nameserver befinden sich im selben Subnetz ist keine gültige Konfiguration. Wen Du nicht über zwei eigene Name Server verfügst, nutze die von Deinem Hoster. Das solltest Du beheben.

Der SOA Fehler deutet darauf hin, das Dein Hoster hier zu hohe Limits gesetzt hat, die außerhalb der Spezifikation liegen, verursacht mal prinzipiell keinen Fehler, Sollte aber einfach zu korrigieren sein. Entweder ein eigenes Zonenfile bei Deinem Hoster erstellen oder das benutzte entsprechend anpassen.

 

[Eisenacher]

SOA-Fehler hätte also Alldomains.hosting zu beheben, deren 4 Nameserver ich dafür nutze. Gleiches dann für die Meldung zum Subnet. Wäre es sinnvoll 2 (weitere) von Contabo einzufügen oder den im ISPConfig mit einem Zonefile zu bestücken?(der hätte dann ja die gleiche IP)
zum SMTP-Test, kann es also mehrere Probleme geben. Er funktioniert per Telnet auch nur, wenn ich mittels WINSCP/Putty auf dem Server bin. (Firewall gesperrt?) Warum versendet der Server aber die Mails, die aus Thunderbird verschickt werden?
1. Das Zertifikat des Servers(VPS), auf dem ISPConfig läuft, was beim Einrichten genutzt wurde(und wohl auch noch wird), ist selbst erstellt und wird als ungültig gewertet. Nach Updates im Thunderbird muss ich auch immer wieder die Ausnahme bestätigen, damit das Senden und Empfangen funktioniert. Es unterscheidet sich somit von dem Zertifikat, das die .TLD.de (in der auch der VPS eingebunden ist) von LetsEncrypt innerhalb der Domainverwaltung zugewiesen bekommt.
3. der Hostname des Server unterscheidet sich. Auf nslookup antwortet er mit web.TLD.de was auch im rDNS bei Contabo so eingetragen ist. Der Mailserver bzw. die maildomain(s) aber ist auf mail.TLD.de konfiguriert. (mein Verständnisproblem?)

 

[Eisenacher]

zum ungültigen DKIM-Key habe ich noch was gefunden, was sich nicht erklären lässt.