Die Entscheidung, ob der Mailserver grundsätzlich alle Emails annehmen soll, die an deine Domain gehen, wird in Plesk getroffen. Die Stelle hast du schon gefunden. Wenn du eher weniger als mehr Emails bekommen willst, lass das so, wie es voreingestellt ist, also Catch-All aus. Die Entscheidung, was mit Emails passiert, die der Mailserver angenommen hat, trifft der Sieve-Filter nach Kriterien, die du festlegst. Der wird im Webmail-Client konfiguriert (oder mit einem Sieve-Client deiner Wahl, aber fang mal mit dem Webclient an.)
Beiträge von NaN
-
-
Das ist die Stelle, wo du angeben kannst, dass du alle Emails für deine Domain bekommen möchtest, auch wenn der Local-Part (der Teil vor dem @) nicht ausdrücklich als Adresse angelegt ist. Voreingestellt ist, dass du solche Mails nicht bekommst. Aber siehe oben, warum du auch Emails bekommst, die (nur anscheinend) nicht an dich adressiert sind.
-
Die Adresse im To: Feld ist nicht notwendigerweise die Adresse, an die die Email geschickt wurde. Da kann auch etwas völlig anderes drin stehen. Die Adresse muss nicht zu deiner Domain gehören. Der To: Header muss nicht mal existieren. Wenn du wissen möchtest, an welche Adresse die Mail geschickt wurde und warum sie in deinem Postfach gelandet ist, musst du in die Received: Header schauen: Der Netcup Mailserver schreibt in seinen Received Header, für welche Adresse er die Mail angenommen hat.
Wenn du Mails bekommst, die "nicht an dich adressiert sind", und die ausfiltern möchtest, kannst du das mit dem Sieve-Filter machen, den du im Webmail-Client von Netcup konfigurieren kannst. Aber Achtung: Es gibt auch legitime Mails, die deine Adresse nicht im To: stehen haben, z.B. Mailinglisten, Weiterleitungen und BCC-Mails.
-
Auf der Festplatte sind wahrscheinlich noch alte Partitionstabellen. Siehe hier.
-
Guter Einwand, aber das letzte Zertifikat ist vor vier Monaten ausgestellt worden. In der Zwischenzeit kann viel umkonfiguriert worden sein. Deswegen "zum Zeitpunkt der Aktualisierung". Ich wollte nur darauf hinweisen, dass es exotischere Konfigurationen gibt, bei denen die automatische Verlängerung scheitert. Ich habe selbst so eine, aber dafür kann Netcup garantiert gar nichts. Man kann natürlich trotzdem mal freundlich beim Support anfragen.
-
Wenn der entsprechende Pfad für die Server von Letsencrypt aus irgendeinem Grund zum Zeitpunkt der Aktualisierung nicht erreichbar ist, klappt das nicht und man bekommt keine Fehlermeldung außer der Ablaufwarnung von Letsencrypt selbst kurz vor Schluss. Mir fallen da z.B. restriktive .htaccess Dateien oder zu pauschale Redirects als mögliche Ursache ein.
-
Es soll eine SubDomain dyn.beispiel.de auf meinen DNS Server verweisen, wo die Hostnamen der Zone verwaltet werden. Hierfür habe ich A/AAAA Records verwendet.
Delegation von Domains an andere Nameserver macht man mit NS Records, nicht mit A/AAAA Records.
-
authorized_keys file von .ssh nach /home/user/.ssh kopiert
Der SSH Server nimmt es mit den Zugriffsrechten genau. Achte darauf, dass das ~/.ssh Verzeichnis dem User gehört und nur für den User zugreifbar ist (drwx------, 0700).
-
goPapa
Das betrifft anscheinend nur Email Accounts im Rahmen einer Plattformmigration. Egal, meine Rechnung wollten sie im Rahmen einer Eigentumsmigration zu einer mehrfach höheren Rechnung migrieren, so dass ich da wegmigriert bin, bevor die irgendwelche Email-Accounts migrieren/löschen konnten. Da wollte jemand den Hostingmarkt konsolidieren. Hat auch geklappt: Ich habe meine Sachen auf drei andere Hoster konsolidiert. Als nächstes schaue ich nach, was diese Worte bedeuten.
-
Bekommt ihr auch solche Phishing-Mails?
Ja, gelegentlich. Den Headern nach zu urteilen kommt die Mail aber tatsächlich vom Mailserver und ist das, was sie zu sein behauptet: Eine Mitteilung, dass der Mailserver eine Mail als sehr verdächtig einstuft und sie daher mit Warnung und Infos zum Spamstatus in einer neuen Mail nur als Anhang zustellt. Interessanter finde ich die Einträge RCVD_IN_ZEN_BLOCKED und URIBL_ZEN_BLOCKED. Der Mailserver von Netcup versucht wohl noch, diese Listen zu verwenden, obwohl er das nicht darf.
-
Dadurch kommt man direkt zum second level Support!
Shibboleet. Nice.
-
Ist das eigentlich normal, dass wenn man einen Ausfall des Routings zwischen Anexia und Deutsche Glasfaser meldet, so dass u.a. keine von Anexia gehostete Domain, inkl. netcup.de, erreichbar ist, und man nicht nur selbst betroffen ist sondern die Meldungen auf allestörungen.de ansteigen, eine Antwort vom Support zurückkommt mit der Aufforderung, das Rettungssystem zu booten und die Netzwerkverbindung mit mtr und iperf3 zu testen?
Ich frage, weil ich als Antwort auf einen etwas schnippischen Kommentar dazu vom Support versichert bekommen habe, dass diese Informationen sehr wohl wichtig sind, falls das Problem auf Seiten von Netcup liegt. Ja klar, Leute, euer ganzes Unternehmen ist seit Stunden für Deutsche Glasfaser Kunden aus dem Netz verschwunden, aber ich boote dann mal meinen Server ins Rettungssystem, damit ihr 'ne Chance bei der Fehlersuche habt...
-
sind die Kabel tatsächlich so empfindlich für Störungen
Was sich geändert hat, ist ja anscheinend, dass du das Drumherum beim funktionierenden Test abgebaut hattest. Vielleicht hast du Erdungsprobleme. Versuch mal, die Fritzbox nur mit unabgeschirmten Netzwerkkabeln zu verbinden. Es wäre nicht das erste Mal, dass in Sorge vor Störungen super abgeschirmte Kabel eingesetzt werden, die die Probleme durch unnötige Erdverbindungen erst auslösen. Ethernet ist eigentlich galvanisch getrennt. Elektrische Verbindung entsteht nur über den Schirm.
Edit: Ich sehe gerade, dass die Fritzbox gar keine geschirmten Ethernetbuchsen hat. Das wird's also nicht sein.
-
Das funktioniert nur, wenn der Server, der für die Zieldomain zuständig ist, auch die Anfragen mit deiner Domain beantwortet. Normalerweise ist das nicht der Fall. Der Browser fragt nach der IP der Quelldomain, bekommt die IP der Zieldomain, fragt den Server an der Adresse "gib mir http://quelldomain/", und bekommt wahrscheinlich eine Fehlermeldung vom Server, weil der mit der Domain nichts anfangen kann.
Für die übliche Weiterleitung per HTTP-Redirect brauchst du einen Webhosting-Tarif, einen Server oder einen externen Dienst, der das macht. Wenn der Server aber tatsächlich auch für die Quelldomain konfiguriert ist, lässt du so nur die Subdomains dieser Domain auf die Zieldomain zeigen (* sind alle Subdomains, für die keine anderen DNS-Einträge existieren). Wenn du die Domain selbst (ohne www) umleiten möchtest, muss der Eintrag für "@" geändert werden. Das kann dann aber kein CNAME sein, weil @ technisch zwingend andere Einträge haben muss, was für eine Domain mit CNAME Eintrag nicht erlaubt ist.
Am einfachsten buchst du dir ein kleines Webhosting-Paket und weist dem die Domain zu. Dann kannst du dir die Weiterleitung zusammenklicken und musst die DNS-Einträge gar nicht anfassen.
-
Wolltest du dich nicht mit IPv6 beschäftigen?
2a0d:3344:xxxx:xxxx:c47:3d2a:b512:c39d
Alles rechts von den xxxx:xxxx ist dein Interface-Identifier. Für die Entstehung dieses Teils gibt es bei IPv6 viele Möglichkeiten. Die wahrscheinlichste Antwort ist, dass sich die Geräte diesen Teil der Adresse selbst aussuchen. Das nennt sich SLAAC, StateLess Address AutoConfiguration, und zwar wahrscheinlich zufällig wegen der "privacy extensions". Wenn dieser Adressteil aus der MAC-Adresse des Geräts gebildet würde (EUI-64), wäre er statisch, aber dann wäre das an einem ff:fe in der Mitte des Interface-Identifiers zu erkennen (da, wo bei dir 2a:b5 steht). Wenn das Präfix, also der linke Teil der Adresse einschließlich der xxxx:xxxx, konstant ist, brauchst du nur feste Interface-Identifier zu konfigurieren (EUI-64 oder Tokenized), um eine insgesamt statische Adresse zu haben. Wenn du tatsächlich ein /56 bekommst, sind die letzten zwei x vom Router gewählt, und der wählt die dann offenbar immer gleich. Das Präfix solltest du nicht statisch konfigurieren, wenn dir vom Provider nicht ausdrücklich ein statisches Präfix versprochen wurde.
-
Deswegen liest man rückwärts. Dann sind solche Links ein Level-Warp. Kann aber auch schiefgehen.
-
DNS sorgt nur dafür, dass die Anfragen der Clients an den Server gerichtet werden. Erst mit der Zuordnung der Domain zum Hostingpaket fühlt sich der Server dann aber dafür zuständig, diese Anfragen zu bearbeiten. Wie du das am geschicktesten ohne Datenverlust machst, kann ich dir aber nicht sagen.
-
Mehr lesen und verstehen, weniger schreiben.
-
Warum ist ein Verbindungen annehmendes VPN sicherer als SSH?
Weil (Open)SSH ein riesiges Programm mit entsprechend großer Angriffsfläche ist. Schau dir mal an, was bei CVE-2024-6387 kaputt ist.
-
Ich wollte das als Anmerkung zu dem "da brauchts kein Portknocking" zufügen.
Ich versuche es nochmal anders: CVE-2024-6387 ist kein Brute Force und kein Dictionary Angriff, sondern eine Vulnerability. Das Ausnutzen braucht zwar etliche Versuche, aber das ist trotzdem konzeptionell etwas völlig anderes. Gegen das Durchprobieren von Passwörtern reicht es, den Passwort-Login abzuschalten, wenn einen die Logeinträge mit den gescheiterten Versuchen nicht stören. Gegen Preauth Angriffe insbesondere noch unbekannter Art hilft nur, die Verbindungen von vornherein zu verhindern, also beispielsweise indem man SSH auf einen unüblichen Port verlegt, SSH hinter Port Knocking versteckt oder SSH nur über ein VPN erreichbar macht, in Reihenfolge aufsteigender Sicherheit. Praktisch ausnutzbare Preauth-Lücken sind glücklicherweise sehr selten.
