Ich habe keine postmaster Adresse und garantiert auch keinen CatchAll.
Beiträge von TBT
-
-
Habe ich auch überlegt.. ich bin irgendwie Raspberry geschädigt seitdem es den gibt..
Ein extrem performanter und dabei effizienter Ableger wäre eher die M Serie von Apple. Wenn man mehr Geld als Raspberry für seine CPUs investieren kann, kommt auch Performance dabei rum.
-
-
Da lernst du beim Kunden.
Mein Argument ging eher in die Richtung: man bietet "dem Kunden" nicht eine voraussichtlich schlechtere, oder nicht die Erfordernisse erfüllende Lösung an, wenn man bessere schon vorher kennt.
-
Joa. "Halb aufsetzen" geht halt nicht. Entweder alles oder nichts.
Weiterer Hinweis: Du wirst ggfalls Mails über Deine neue Lösung herein bekommen, die aber nur in dem IMAP Postfach landen, das auf Deiner Lösung ist. Wenn Du das wieder platt machst, sind auch diese Mails weg. Hängt etwas davon ab, ob Du das mit etablierten Mailadressen oder wohl eher Domains machst oder mit neuen Mails auf einer neuen Domain.
-
Der Kunde bin ich.
Ich bin Privatier...
Es geht doch hier um Bud und seine Vereinsheimlösung...
-
Meine Meinung (kein Angriff): man lernt nicht "am Kunden", sondern für und bei sich. Wenn es für Kunden / Nutzer bessere Lösungen gibt, sollte man diese auch nutzen.
-
Wie so oft: deutlich angenehmer mit Tailscale zu lösen. Da KÖNNEN die Leute die VPN Verbindung nicht als Default Gateway verwenden es sei denn das Ziel ist aktiv als Exit Node definiert.
-
Ich hab übrigens noch keine PM mit Tipps.
Werd euch jetzt so oft nerven, bis ihr mir eure smtp Provider verratet.
https://www.brevo.com/de/ selektiv für die Microsoft. Dienste. Die kostenlose Version beinhaltet nur 300 E-Mails/Tag. Das reicht wenn man selektiert, aber eher nicht, wenn man alles drüber laufen lassen würde. Mein Mailserver (Kerio Connect) unterstützt selektive Auswahl des SMTP Servers abhängig von der Zielmaildomain. Daher ist das meine gangbare Lösung.
-
Ich sag ja, ich bin konservativ.
Containern traue ich nur, wenn ich sie selbst gemacht hab.
Auch wenn das in den meisten Fällen nur subjektiv ist...
Man kann in jeden Containervorgang hineinsehen (dockerfile und docker-compose angucken). Und Du installierst Dir die o.g. Software ja auch, ohne dass Du jede Codezeile angesehen hast. Durch die Containerisierung wird die Separation zu anderen Containern und dem OS doch nur besser, nicht schlechter.
-
Habe den Storage Share vom roten H schon länger und bin sehr zufrieden (geht auch mit der eigenen Domain). Nextcloud ist imho nicht so angenehm selbst zu hosten. Daher lieber "machen lassen". Da ist dann noch die Storage Box auch vom H eingehängt und man hat Platz ohne Ende.
-
Ich habe der Telekom einen Auszug der DENIC-Daten für meine Domain geschickt, weil daraus auch hervorgeht wer der Betreiber des Mailservers ist. Das ging tatsächlich so durch und mein Mailserver wurde freigeschaltet.
Ich habe das mit dem Impressum umgesetzt.
-
Als Backport hab ich momentan nur Zoneminder...
Das gibts für Debian Buster, Bullseye, Bookworm. Wieso Backport?
Davon abgesehen setze ich nichts mehr ein, was nicht von vorneherein containerisiert ist.
-
Bei Ubuntu mit Docker stellt sich die Frage ob docker aus SNAP oder den Paketquellen - oder direkt von docker.
Außerdem meine ich mich zu erinnern, dass die container den Host-Kernel verwenden - der im Falle von Debian halt nie so aktuell ist... Ich muss aber zugeben, dass ich bisher nie ein Problem damit hatte.
Ich nehme ausschließlich Paketquellen. Wenn sie älter sind, dann ist das halt so. Dafür sind dann auch weniger "bleeding edge" Probleme drin.
Sooo veraltet dass irgendwas gar nicht mehr geht? Ist mir jetzt noch nie untergekommen.
-
Ach, tja. Da haben sie jetzt aber Pech gehabt. Also die Nutzer von T-Online...
Wie ASS schreibt, geht das auch nur, wenn man den Mailserver quasi nur für sich selbst betreibt und für sich selbst ausschließt, Mails an t-online.de Mailadressen schreiben zu wollen. Ist bei mir aber nicht so. Und da wollen meine Nutzer halt auch an t-online.de Adressen schreiben. Sind ja leider immer noch sehr verbreitet. Und dann muss man das halt möglich machen. In der Tat "realistisch ist eine solche Haltung nicht".
Schon, weil meine Mailserverdomain nicht meine Webdomain ist und ich auch nicht vorhabe, das zu ändern.
Ist irrelevant. Wenn Du mail.maildomain.net als Mailserver betreiben willst und http://www.meinetollewebsite.de als Webdomain, dann will halt T-Online zumindest eine einzige Rumpfseite (ohne jeden Inhalt) mit Impressum auf maildomain.net sehen. Und wenn man das nicht macht, gehts nicht weiter. Diese Regelung ist extrem dumm und wider jeden Sinn des Mailprotokolls. Aber T-Online zieht sie durch und man muss mitspielen oder bleibt draußen.
-
Also wenn ich dich richtig verstehe darf ich die Mail Records verändern und auf den VServer zeigen lassen. Das ist schon mal sehr hilfreich. Dann kann ich das Vorhaben erstmal testen und wenn das nicht so hinhaut, wie ich mir das vorstelle, lasse ich die wieder auf das Hostingpaket zeigen.
Hinweise:
- Die TTL (Time to Live) des DNS Eintrags einige Zeit vor solchen Änderungen auf einen möglichst kleinen Wert setzen (z.B. 180 (Sekunden)). Dann ist die Änderung auch möglichst schnell überall umgesetzt. Die TTL gibt an, wie lange ein cachender Server die Records im Cache behalten sollte). Wenn diese auf z.B. 86400 (Sekunden = 1 Tag) gestellt ist, kann es sein, dass die Änderungen 1 Tag benötigen, bevor sie überall umgesetzt sind.
- Ein MX Record MUSS auf einen FQDN verweisen. D.h. Du brauchst einen A Record, der z.B. mail.domain.tld auf die IP Deines Mailservers auflöst. Und Du brauchst einen MX Record, der auf mail.domain.tld auflöst. Wenn mehrere MX Records existieren, ordnet die Priorität des MX Records die Reihenfolge der Verwendung (größere Zahl = höhere Priorität).
- Der reverse DNS Record zur IP des Mailservers muss auf den gleichen FQDN verweisen wie der, der im MX Record steht. Diese Einstellung kann im SCP beim jeweiligen Server unter Netzwerk angepasst werden werden. D.h. IP -> DNS Name und DNS -> IP müssen wechselseitig auf sich auflösen.
- Du brauchst einen SPF TXT Record. Generator dafür: https://www.spf-record.de/generator?domain=&opt_out=onDann musst Du den Mailserver korrekt aufsetzen und dabei KEIN OFFENES RELAY KONFIGURIEREN!!! Jede Domain, die damit betrieben werden soll, muss ihren MX Record auf Deine o.g. Subdomain setzen. Also z.B. für domain0815.org als MX mail.domain.tld.
Wenn das geschehen ist:
- Spamfilter entweder aufsetzen oder konfigurieren, wenn im Mailserverpaket vorhanden. (Ohne Spamfilter ist ein Mailserver unbrauchbar).- sich um gültige SSL Zertifikate kümmern. Das kann mit Let's Encrypt gehen, alternativ bekommt man auch aus anderen Quellen kostenlose oder kostenpflichtige Zertifikate.
- Backup aufsetzen und externes Abspeichern konfigurieren. Wenn Dein Server die Grätsche macht, muss er aus einem EXTERNEN Backup wiederherstellbar sein. Idealerweise testet man diesen Vorgang auch. Auf jeden Fall muss er automatisiert sein und jede Nacht laufen.
- Spezialbehandlung: große Mailanbieter wie T-Online und Microsoft benötigen Spezialbehandlungen, sonst werden Mails von Deinem Mailserver dort nicht ankommen.
- Regelmäßige Updates von Betriebssystem, Mailserverpaket etc. ist Pflicht. Das Screenen von IT Sicherheitswebsites ebenso (Heise Online und andere).
- ...hast Du meist "nur" einen Mailserver, der v.a. (SSL abgesichertes) IMAP macht. Für Groupware fehlen noch Kontakte und Termine. Manche Komplettpakete bringen hierfür Optionen mit.
Wenn Dir das alles zu kompliziert ist oder Du nichts kapierst, solltest Du evtl Dein Vorhaben nochmals überdenken...
-
Also mein Netcupmailserver hatte noch nie ein Zustellungsproblem, das nicht an mir lag.
Doch. Haben sie alle:
- Telekom / T-Online
wenn Mails dorthin gehen sollen, MUSS der Mailserver whitegelistet werden. Hierzu fordert TOSA ein Impressum auf einer Website der Mailserver Domain.- Microsoft / Outlook / Hotmail: hier gibt es auch oftmals (nicht immer) Schwierigkeiten mit der Zustellung. Ein Smarthost explizit für diese Ziele ist empfehlenswert.
Für beides kann der Mailserverbetreiber selbst nix.
-
Ergänzung: mit der Verwendung von Docker ist es imho nahezu irrelevant, was "darunter" als Betriebssysstem (Distro) läuft. Das OS muss imho eigentlich nur noch die virtuelle/physische Hardware erkennen, durchreichen und möglichst sicher und stabil sein. Idealerweise wird es möglichst lange und zeitnah mit Sicherheitsupdates versehen. Ansonsten das womit man vertraut ist.
Alles andere findet eh in den Containern statt. Ältere Pakete in konservativeren Distros sind - außer das Docker Paket - doch egal wenn man als Basis eines Containers nehmen kann was man will.
-
Debian. Hat mir in den letzten 20 Jahren gut gedient, wird auch die nächsten 20 Jahre die stabilste Basis für Server sein. Bleeding Edge sollen andere ausprobieren und sich daran aufschneiden.
-
vielen Dank für euer Feedback zu den aktuellen Einrichtungszeiten unserer Server.
Wie bereits korrekt angemerkt, kommt es aktuell bei einigen Produkten, insbesondere bei unseren ARM-Servern, aber auch bei unseren Root-Servern, zu Verzögerungen bei der Bereitstellung.
Das ist auf eine außerordentlich hohe Nachfrage seitens unserer Kunden zurückzuführen. Darüber freuen wir uns natürlich, gleichzeitig ist die Beschaffung von Hardware in entsprechenden Stückzahlen mit gewissen Vorlaufzeiten verbunden, so dass die Nachfrage aktuell teilweise die vorhandenen Ressourcen übersteigt.
Ist Euch denn auch die sehr wahrscheinliche Ursache der hohen Nachfrage bekannt?: https://forum.netcup.de/administration…kte/#post224189
Wollt Ihr wirklich solche Kunden?
