Beiträge von tbc233

Ich weiß nicht, wann dieses letzte Mal war. Aber ich würde behaupten, dass seit einiger Zeit reine Blacklist Lösungen nicht mehr viel bringen. Irgendwann hatte ich genug von dem ganzen ständigen Blacklisten und Spamassassin Feintuning das nie ein Ende nimmt. Da war mir dann klar dass ich das jetzt an Profis outsourcen möchte. Hab mir dann einige solcher Lösungen, die man via MX Record einbindet, angesehen und Spamexperts fand ich am besten und von Preis/Leistung am fairsten.

Das ist in der Tat oft ein Problem bei Weiterleitungen an einen der großen Mailanbieter. Dadurch dass der ganze Spam ebenfalls weitergeleitet wird, beginnt hotmail,apple,etc. dann irgendwann damit den eigenen Server als Spamquelle zu identifizieren (vereinfacht gesagt) glaube ich.

Wenn Du hier was machen willst und mehrere Domains hast die Du schützen möchtest, kann ich Dir spamexperts.com empfehlen. Macht aber erst ab zumindest 10 Domains Sinn von den Kosten her.

Wenns nur eine oder weniger Domains sind, findest Du sicher jemand der Dir einen Domainslot günstig re-sellt. Wir machen das auch, aber ich will hier nicht einen auf Verkäufer machen.

Ich würd jetzt nicht mehr rumspielen wenns schon funktioniert hat

Ich glaube MAD M!NDWORX natürlich wenn er sagt dass es bei ihm so läuft. Fakt ist aber dass bei all meinen Installationen (also auch bei jenen wo es immer funktioniert hat) die Dateien popuser:popuser gehören, ohne mein Zutun. Ob das Berechtigen auf den popuser damals bei meinem Problem ein entscheidender Schritt war oder nicht, trau ich mir heute nicht mehr sagen. Aber ich würds auf jeden Fall auf popuser lassen, insbesondere weil mir das der Default zu sein scheint (und nochmal insbesondere wenn es damit funktioniert hat )

Wunderbar. Interessant ist übrigens, dass diese falschen Berechtigungen, bei Servern die ich später aufgesetzt hab, nicht mehr aufgetreten sind bei mir. Ich ging daher davon aus dass es ursprünglich ein Fehler im tar Paket bzw. in der Installationsroutine war, der mittlerweile behoben ist. Möglicherweise entsteht dieser Fehler eher diffus.

Sehr fein, vielleicht haben wir es damit ja bald vom Tisch. So sieht das Ganze btw bei mir aus:

Es ist zwar ein Strohhalm und eine blöde Frage, aber vielleicht kannst Du trotzdem mal zur Sicherheit die Ausgabe von

posten? Ich, der ja diesen Thread damals ins Leben gerufen hat, hab mir das eben nochmal alles angesehen und es bleibt trotzdem als Ursache fast nur eine Berechtigungsgeschichte. Ich würde Mindworx auch tendentiell eher widersprechen dass der Besitzer root:root bleiben darf, wenn ich mich richtig entsinne hat es erst funktioniert als popuser:popuser Besitzer der beiden Dateien war.

Sowas ist echt Mist...

Ich hab hier ein paar Jungs (Thread ist zwar alt aber das ist der qmail Kern letztendlich ja auch) gefunden, die ein sehr ähnliches Problem hatten. Der Thread führt zwar nicht zu einer Lösung, aber hier wird das Tool "recordio" erwähnt, das zumindest mir bisher nicht bekannt war und mit dem man anscheinend in den smtp Dialog rein schauen kann:

https://groups.google.com/foru…mp.mail.qmail/TaEDf-voEgc

Du müsstest dieses recordio in das qmail-smtp run script inkludieren. https://qmailrocks.thibs.com/maybe-recordio.php

https://www.linux-magazin.de/b…service-attacke-moeglich/

Bin allerdings nicht sicher ob wir unmittelbar betroffen sind. Als betroffene Version wird 1.3.6a genannt, in der Standardumgebung dürfte 1.3.5e enthalten sein.

Sehr allgemein formuliert kümmert sich pd-admin recht wenig um Software die ansonsten am Server installiert ist. Ausnahme natürlich Dienste, die zum Beispiel bezüglich benututzter Ports oder so mit dem pd-admin Diensten konkurrieren.

Habe mal kurz quergelesen worum es bei tesseract geht, das sieht mir nicht danach aus dass es Probleme geben sollte.

Ehrlich gesagt wundert es mich, dass Du mit diesem Setup durchgekommen bist, ohne dass bei Dir rund um die Uhr das Telefon läutet. Also jedenfalls dann, wenn auf dem betroffenen Server schon einige Mailboxen laufen. Insbesondere Apple (inkl. iphone etc.) ist bei sowas extrem empfindlich. Wenn da der Hostname aus dem Dialog nicht mit dem Zerti zusammenpasst, hagelt es ständig Warnungen die sich in neueren ios Versionen nicht mehr dauerhaft abnicken lassen.

Unbeschadet dessen: Ich würd mal probieren was passiert, wenn Du ein Zerti verwendest dass beide Hostnamen mit drin hat. Dank letsencrypt kann man das ja recht leicht mal kostenlos antesten. Im Falle von certbot zum Beispiel einfach mal alle benötigten Hostnamen mit -d verfüttern.

Wenn das geht, wärst Du fein raus.

Vielleicht findet sich ja hier ein pd-admin Hoster, der seinerseits bei B&K ist? Wär ein Kompromiss.

Zitat von RudiX

vielen Dank für Dein Feedback. Meinst Du damit den Punkt Mail-Submission limitieren und Drosselintervall?
Aber der zieht doch lediglich wenn "Reines Email-Hosting" aktiviert ist.

Ja, den mein ich. Und nein, der zieht immer (Ausnahme wie gesagt Mails die per Script oder auf der Kommandozeile erstellt wurden). Gott sei Dank.

Deine Domains sind im Normfalfall außer Gefahr. Du bist zwar ziemlich sicher auf einem Berg voller Blacklists gelandet, aber diese blacklisten in aller Regel ja die IP und nicht die Domain. Stampf den Server ein und hol Dir einen neuen mit neuer IP. Ist zwar nicht besonders fair dem gegenüber, der als nächster diese IP bekommt, aber da mussten wir alle mal durch und Du bist die Sorge schneller los.

Für den sicheren Einsatz empfiehlt sich starke Kennwörter zu verwenden und fail2ban einzusetzen. Typo3 sollte immer aktuell gehalten werden.

Bei mir geht seit längerem kein Server mehr ohne fail2ban online. Damit kriegt man die Passwortattacken ganz gut in den Griff.

In deinem Fall wäre weiters zu klären, warum es kein vernünftiges Mail Limit gab. Normalerweise wird im Angebot ja festgelegt, wieviele Mails man in welchem Zeitraum verschicken darf. Diese Mechanismus verhindert meist Schlimmeres. UND er hat den Nachteil, dass er nicht für Mails zieht, die über Scripte eingeliefert wurden. Deswegen würde ich in Deinem Fall nochmal klären ob der ganze Mist nicht doch eher auf ein veraltetes Webscript zurückzuführen ist.

Owncloud... Ich würds mir nicht antun in Zeiten in denen man Nextcloud Instanzen bei allen möglichen Anbietern voll gewartet um ein paar Euro mieten kann. Wenn Du es dennoch machen willst, würde ich es auf einem eigenen Server machen.

Ja, der Thread hat sich etwas verlaufen.

Check mal mit df -i ob Deine Platte keine Inodes mehr hat. Soweit ich das mitbekommen habe, ist die Kiste ja aufgrund Deines Urlaubs oder so relativ lange in dem angegriffenen Zustand dahin gelaufen. Eine Theorie wäre, dass Dir so dermaßen viele Spams (zuzüglich Bounces darauf) eingliefert wurden, dass die Platte keine inodes mehr hat.

Um wieder zum Thema zu kommen, die neue Serverumgebung mit dem gehärteten Dovecot ist raus. DANKE an Herrn Bradler und sein Team.

Das "unable to append to Bounce message" hat zu 99% damit zu tun dass Deine Disk voll ist. Hat nichts mit der Lücke zu tun um die es hier geht.

Du musst dringend rausfinden warum Deine Festplatte so voll ist bzw. platz schaffen.

Wie meinst Du, Du wirst "zugeballert"?

Zudem: Wenn Du ein Update machst wegen dieser Sicherheitslücke, damit kannst noch warten. Die derzeitige SEU Version hat noch die betroffene Version drin.

Schwer für mich zu sagen, inwieweit wir betroffen sind. Workaround gibt es jedenfalls anscheinend keinen.

https://www.golem.de/news/sich…ilserver-1908-143508.html

Sieht verdächtig danach aus als würde der Installer hier die CLI Version prüfen. Hast Du diese schon hochgestellt?

Herzlichen Dank für die schnelle Information!