Probleme mit dem Emailversand

[Luukullus]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
Ich denke schon das es Keyhelp bezogen ist, doch nicht Keyhelp der Schuldige ist, sondern ich....

Server-Betriebssystem + Version
Ubuntu 22.04

Eingesetzte Server-Virtualisierung-Technologie
keine

KeyHelp-Version + Build-Nummer
23.1.1 (Build 3016)

Problembeschreibung / Fehlermeldungen
Emailversand aus Keyhelp nicht möglich (Sowohl Webmail von Kundenkonten, als auch Systememails vom Panel selber)

Erwartetes Ergebnis
Emailzustellung zum Beispiel bei Erfolgreichem Backup

Tatsächliches Ergebnis
Lange Emailwarteschlange und die Emails gehen nicht raus | Kundenkonten können aus dem Webmail keine Mails verschicken

Schritte zur Reproduktion
Wenn ich das wüsste, wäre es in diesem Fall sicher die Lösung

Zusätzliche Informationen
Email Protokolle:

3.png (15.47 KiB) Viewed 830 times

4.png (21.14 KiB) Viewed 830 times

--------------------------------------------------------------

Vom User in der Webmail:

Bitte lasst es mich wissen welche Informationen ihr noch benötigt.

Lieben Gruß,
Luuk

[Jolinar]

Da haut irgendwas mit den Zertifikaten nicht hin.
Wenn ich daheim bin, schau ich mal genauer. Vllt. hilft bis dahin ja auch schon jemand anderes...

[mhagge]

Da muss es irgendwo bereits einen Bug-Report zu geben - im Changelog ( https://www.keyhelp.de/changelog/ ) von Keyhelp 23.2 unter "Fixes" steht (unter anderem)

Fixed the dovecot error 'Command output: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.keyhelp.d/10-ssl.conf line 4: ssl_ca: Can't open file /etc/ssl/keyhelp/mail-ca.crt: Permission denied' by removing the ssl_ca configuration option from /etc/dovecot/conf.keyhelp.d/10-ssl.conf

Wenn es nicht eilig ist, hilft vielleicht auch einfach ein paar Tage warten, bis die neue Version draußen ist

[Jolinar]

Dim Changelog ( https://www.keyhelp.de/changelog/ ) von Keyhelp 23.2 unter "Fixes" steht (unter anderem)

Fixed the dovecot error 'Command output: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.keyhelp.d/10-ssl.conf line 4: ssl_ca: Can't open file /etc/ssl/keyhelp/mail-ca.crt: Permission denied' by removing the ssl_ca configuration option from /etc/dovecot/conf.keyhelp.d/10-ssl.conf

Ich wußte doch, daß ich dazu schon was gelesen hatte in den letzten Tagen. Wußte nur nicht mehr, wo genau...
Danke @mhagge für die Erleuchtung

[Luukullus]

Da muss es irgendwo bereits einen Bug-Report zu geben - im Changelog ( https://www.keyhelp.de/changelog/ ) von Keyhelp 23.2 unter "Fixes" steht (unter anderem)

Fixed the dovecot error 'Command output: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.keyhelp.d/10-ssl.conf line 4: ssl_ca: Can't open file /etc/ssl/keyhelp/mail-ca.crt: Permission denied' by removing the ssl_ca configuration option from /etc/dovecot/conf.keyhelp.d/10-ssl.conf

Wenn es nicht eilig ist, hilft vielleicht auch einfach ein paar Tage warten, bis die neue Version draußen ist

Oh Mein Gott. Ich habe mich stuuuuundenlang halb zu Tode gesucht und zweifle immer mein ganzes IT Wissen an.
Vielen Dank für die Info.

Ja es kommt auf ein paar Tage nicht an...
Ich denke es dauert eh noch um die zwei Wochen bis die ASIA Instanz online geht

Ich melde mich hier noch einmal nach dem Update.

Einen wundervollen Tag euch!

[Luukullus]

Moin ihr lieben.
Nach dem ich nun auf die neuste Version geupdated habe. Funktioniert der Mailversand nach außen.
Auch die User können das Webmail wieder nutzen.
Leider aber, kann keine Mail zur Paneladresse geschickt werden. Ich verstehe aber die Meldungen nicht wirklich. Kann mir da jemand behilflich sein?
Versuch eine Mail zu senden (an alle externen mails ist es kein Problem):

Und hier die zugehörigen Logeinträge:

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Zudem habe ich seit dem Update merkwürdige Meldungen im Log, siehe Bild. Kann ich die ignorieren?:

Lieben Gruß,
Luuk

[tab-kh]

Ist doch eigentlich eindeutig. Die Empfängeradresse existiert nicht auf dem Server, allerdings scheint die Domain (ratucloud.com) auf dem Server zu existieren und kann dort auch für Mail verwendet werden. Das DNS der Domain gibt zwar ratucloud-com.mail.protection.outlook.com. als MX an. Wenn allerdings die Domain lokal bekannt ist und auch für Mail(empfang) verwendet werden kann, dann wird ausgehende Mail für die Domain nicht an ...outlook.com geschickt, sondern es wird versucht sie lokal zuzustellen. Hier existiert aber offenbar das betreffende Postfach nicht, was die Fehlermeldung ja ganz klar sagt.

[Luukullus]

Ist doch eigentlich eindeutig. Die Empfängeradresse existiert nicht auf dem Server, allerdings scheint die Domain (ratucloud.com) auf dem Server zu existieren und kann dort auch für Mail verwendet werden. Das DNS der Domain gibt zwar ratucloud-com.mail.protection.outlook.com. als MX an. Wenn allerdings die Domain lokal bekannt ist und auch für Mail(empfang) verwendet werden kann, dann wird ausgehende Mail für die Domain nicht an ...outlook.com geschickt, sondern es wird versucht sie lokal zuzustellen. Hier existiert aber offenbar das betreffende Postfach nicht, was die Fehlermeldung ja ganz klar sagt.

Meeeega, vielen Dank.
Ich habs echt nicht gerallt...
Ich dachte mir die ganze Zeit. Wieso existiert die nicht... Ist doch eh extern...

Danke dir. Ich prüfe das mal!

[Alexander]

Um den lokalen Zustellungsversuch zu unterbinden, dann einfach bei entsprechender Domain, die keine (lokale) Email-Funktionalität haben soll, den Haken unter "KeyHelp Admin Bereich -> Domainverwaltung -> entsprechende Domain zum Bearbeiten auswählen -> den Haken bei 'Domain kann für E-Mail verwendet werden'" rausnehmen.

[Luukullus]

Oh Man!

Vielen vielen Dank euch. jetzt funktioniert alles.
Ich habe das echt nicht gerallt.

Wiedermal top Hilfe von euch!
Was würde ich nur ohne euch machen.
Vielen Dank <3

[tab-kh]

Zudem habe ich seit dem Update merkwürdige Meldungen im Log, siehe Bild. Kann ich die ignorieren?:

Ist ja offenbar immer die selbe IP 141.98.11.82. Sieht nach Litauen aus. Da scheint jemand zu versuchen, Zugangsdaten für SMTP, also Mailversand, herauszufinden. Seinen PTR hat er gefaked, der Name löst nicht auf seine IP auf, sondern auf 45.79.133.252, irgendein "Internet-Research-Project", was wohl sein Tun verharmlosen soll. Im Erfolgsfall kann er dann Spam über deinen Server versenden, was nicht so lustig wäre angesichts der DNS-Blocklisten. Typischerweise werden da irgendwelche Passwortlisten durchprobiert. Man kann auch herausfinden, welcher User und Passwort angegeben wurden. Das muss man aber erst in Dovecot einstellen, habe ich bei zwei Servern mal gemacht, da sehe ich dann User & Passwort im Log. Sobald aber mal Kunden auf dem Server sind, sollte das natürlich aus Datenschutzgründen deaktiviert werden.

Du kannst natürlich auch versuchen, die Versuche per fail2ban zu blocken. Aber wenn du Kunden auf dem Server hast und nicht bei jedem in deren Mailclient mal falsch eingegebenen Passwort die IP entsperren willst, kannst du die Versuche nur bremsen. Solange es bei der einen oder wenigen IPs bleibt, was erfahrungsgemäß nicht lange so sein wird, kannst du die IP natürlich auch in der Firewall sperren. Oder du vertraust auf die Passwörter, auf die du ja durch Mindestanforderungen Einfluss nehmen kannst, so dass keiner das beliebte "123456" benutzen kann .

[Luukullus]

Zudem habe ich seit dem Update merkwürdige Meldungen im Log, siehe Bild. Kann ich die ignorieren?:

Ist ja offenbar immer die selbe IP 141.98.11.82. Sieht nach Litauen aus. Da scheint jemand zu versuchen, Zugangsdaten für SMTP, also Mailversand, herauszufinden. Seinen PTR hat er gefaked, der Name löst nicht auf seine IP auf, sondern auf 45.79.133.252, irgendein "Internet-Research-Project", was wohl sein Tun verharmlosen soll. Im Erfolgsfall kann er dann Spam über deinen Server versenden, was nicht so lustig wäre angesichts der DNS-Blocklisten. Typischerweise werden da irgendwelche Passwortlisten durchprobiert. Man kann auch herausfinden, welcher User und Passwort angegeben wurden. Das muss man aber erst in Dovecot einstellen, habe ich bei zwei Servern mal gemacht, da sehe ich dann User & Passwort im Log. Sobald aber mal Kunden auf dem Server sind, sollte das natürlich aus Datenschutzgründen deaktiviert werden.

Du kannst natürlich auch versuchen, die Versuche per fail2ban zu blocken. Aber wenn du Kunden auf dem Server hast und nicht bei jedem in deren Mailclient mal falsch eingegebenen Passwort die IP entsperren willst, kannst du die Versuche nur bremsen. Solange es bei der einen oder wenigen IPs bleibt, was erfahrungsgemäß nicht lange so sein wird, kannst du die IP natürlich auch in der Firewall sperren. Oder du vertraust auf die Passwörter, auf die du ja durch Mindestanforderungen Einfluss nehmen kannst, so dass keiner das beliebte "123456" benutzen kann .

Vielen Dank für deine ausführliche Erklärung.
Irgendetwas in diese Richtung habe ich mir schon gedacht und habe deshalb die IP Proforma bereits in der Firewall manuell geblockt.

Ich habe alle Passwörter mit 20 bis 32 Zeichen mindestens vierfach komplex. Da will ich auf jeden Fall auf Nummer sicher gehen.

Lieben Gruß,
Luuk

[Ralph]

Irgendetwas in diese Richtung habe ich mir schon gedacht und habe deshalb die IP Proforma bereits in der Firewall manuell geblockt.
Ich habe alle Passwörter mit 20 bis 32 Zeichen mindestens vierfach komplex. Da will ich auf jeden Fall auf Nummer sicher gehen.

wenn es sehr viele Attacken sind sollte man Fail2ban etwas strikter konfigurieren eventl. maxretry = 2 ([keyhelp-postfix] + [keyhelp-dovecot]) ...
oder die f2b.postfix noch aktivieren mit mode aggressive etc.
solche attackierenden IP Adressen lassen ich leicht prüfen z.b.
https://www.abuseipdb.com/check/141.98.11.82

[Luukullus]

Irgendetwas in diese Richtung habe ich mir schon gedacht und habe deshalb die IP Proforma bereits in der Firewall manuell geblockt.
Ich habe alle Passwörter mit 20 bis 32 Zeichen mindestens vierfach komplex. Da will ich auf jeden Fall auf Nummer sicher gehen.

wenn es sehr viele Attacken sind sollte man Fail2ban etwas strikter konfigurieren eventl. maxretry = 2 ([keyhelp-postfix] + [keyhelp-dovecot]) ...
oder die f2b.postfix noch aktivieren mit mode aggressive etc.
solche attackierenden IP Adressen lassen ich leicht prüfen z.b.
https://www.abuseipdb.com/check/141.98.11.82

Danke für deine Tipps.
Ich habe die bestehenden Werte ergänzt:

[postfix]
# To use another modes set filter parameter "mode" in jail.local:
maxretry = 3
findtime = 1d
bantime = 1y
mode = more
port = smtp,465,submission
logpath = %(postfix_log)s
backend = %(postfix_backend)s

[dovecot]
port = pop3,pop3s,imap,imaps,submission,465,sieve
maxretry = 3
findtime = 1d
bantime = 1y
logpath = %(dovecot_log)s
backend = %(dovecot_backend)s


Ist das so erstmal ausreichend?

LG,
Luuk

[Ralph]

Ich habe die bestehenden Werte ergänzt:

[postfix]
# To use another modes set filter parameter "mode" in jail.local:
maxretry = 3
findtime = 1d
bantime = 1y
mode = more
port = smtp,465,submission
logpath = %(postfix_log)s
backend = %(postfix_backend)s

[dovecot]
port = pop3,pop3s,imap,imaps,submission,465,sieve
maxretry = 3
findtime = 1d
bantime = 1y
logpath = %(dovecot_log)s
backend = %(dovecot_backend)s

findtime = 1d ist viel zu hoch, dies erzeugt sehr viel unnötige CPU Last
findtime = 30m sollte ausreichen, wenn es Botnet Attacken sind, würde ich maxretry auf 2 oder sogar 1 setzen.
bantime = 1y keine Ahnung ob das klappt, sinnvoll ist es nicht gerade - 1w oder 48h sollte besser sein damit das OS zukünftige neue Attacken noch blocken (verarbeiten) kann.