Beiträge von A:H

    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.

    Einen VPS mit durchgehend 50% Steal würd ich kündigen, Preis hin oder her, da stimmt dann die Produktbeschreibung nicht und ist irreführend. Wenn er hin und wieder auf 50% ausreißt aber sonst bei 0-10 ist find ich das aber wieder total ok und dem Produkt angemessen.

    https://github.com/mailcow/mailcow-dockerized/issues/1439

    Aber ich will da jetzt keine weitere Zeit damit verschwenden, bei mir läuft alles andere ja.

    Und nein bis jetzt hatte ich nur mit docker im Zusammenhang mit mailcow Probleme und nur deren container haben die Kernel Panik verursacht, meine eigenen nicht. Denn als ich die mailcow container mittels Rettungssystem am auto start gehindert habe, bootete das System wieder.

    Mir scheint es als ob mailcow wohl auch die Heilige Kuh einiger Leute hier zu sein scheint... Naja ich wünsch euch noch viel Spaß und möchte auch keine weiteren Tipps zu Mailcow, ist hier auch nicht das Thema.

    Ich habe lediglich meine Meinung dazu geäußert.

    Sorry, da muss ich noch einmal darauf antworten, ich will das so nicht stehen lassen.


    Eine Antwort weiter unten findest du nachfolgendes:

    Zitat

    This also never happens on port 587 and 465. Plus it never sticks the whole website. You are doing something very wrong. :(

    Mailcow hat wie bereits erwähnt keine künstlich erzeugte Verzögerung.

    Der Kernel-Panic wurde auch - wie in dem Bugreport zu sehen ist - nicht von Mailcow erzeugt sondern von einem Bug im Ubuntu Kernel.

    Mailcow ist nicht der heilige Gral, jedoch sollte man an deiner Stelle keine Software und kein Projekt schlecht reden weil es einen Fehler triggert der im Kernel eines Betriebssystems zu finden ist. Du musst hier klar unterscheiden und auch bei den Fakten bleiben. Das was ich mache ist, deine schrägen Aussagen gerade zu biegen um den Ruf des Projekts zu schützen.

    Meinung äußern ist gut, dann bilde dir deine Meinung aber auch aufgrund von Fakten und nicht aufgrund von unverifizierten Beobachtungen und Vermutungen.

    Trotz längerer Suche konnte ich nicht herausfinden, wie ich die eingebaute Verzögerung beim Versenden über smtp abschalten kann. Das hat dazu geführt, dass Bestellungen usw. teilweise mehrere Sekunden gedauert haben, weil eben E-Mails versendet wurden.

    Dann hat mailcow mein System lahm gelegt, da nach einem Update eine Kernel Panik (mit 4er Kernel) verursacht wurde. Später haben sie dann eine Prüfung in ihrem Update Skript eingebaut und es wurde erst ausgeführt, wenn man einen 5er Kernel verwendet.

    Das von dir angesprochene Problem lag nicht an Mailcow sondern am entsprechenden Ubuntu Kernel in Verbindung mit Docker Netzwerken (NAT Fragmentierung).

    Achja, auch eine eingebaute Verzögerung gibt‘s nicht.

    Wie wär’s wenn du deine Webseite von jemanden optimieren lässt der sich damit auskennt und so nachhaltig etwas verbesserst ohne den Server wechseln zu müssen?

    1,2MB sind eben 1,2MB. Wenn dein User dafür 4 Sekunden zum Laden braucht wird er durch einen neuen Server nicht plötzlich weniger Zeit benötigen.

    Ich bin selbst nebenbei Fotograf und hab auf meiner Webseite keine solchen Probleme, trotz größerer Seiten und ebenso vielen Bildern.

    Servus. „Sicherheit durch Geoblocking“ zu erreichen ist meiner Meinung nach komplett der falsche Weg. Eher solltest du darauf achten nur vernünftige Plugins und nicht jeden Müll zu installieren. Zusätzlich dazu solltest du darauf achten, dass deine Software immer aktuell ist, dass du sichere Passwörter verwendest und dass der Server selbst proffessionell gewartet wird (in dem Fall durch netcup bereits erledigt).

    Du kannst natürlich auch übertreiben und Web Application Firewall plus Intrusion Detection davor zu schalten, das erachte ich aber eher als unnötig auf kleinen Webseiten. Cloudflare (bietet eine WAF gegen Geld) könntest du dir aber tatsächlich mal ansehen, falls das für dich interessant ist.

    Ich könnte mich auch täuschen aber denke, dass die Redirect-Setzings bei Namecheap voraussetzen, dass du deren MX Einträge verwendest (sonst könnten sie auch keine Mails empfangen).

    Frag mal deine Domain ab ob da MX Einträge hinterlegt sind. Als Beispiel unter Linux:

    dig MX example.de