Beiträge von tab

    Mir ist klar, dass das nicht wirklich geht, aber dir ist auch klar, dass es auf Dauer nicht funktioniert, wenn Emails willkürlich nicht angenommen werden, oder? Dieser Blödsinn, dass man beim richtigen Anbieter sein muss, um Mails zustellen zu können, treibt durch die Unzuverlässigkeit die Menschen zu zentralistischen Systemen. Sippenhaft und Geiselnahme sind keine akzeptablen Antispammethoden.

    Nein, keine akzeptable Antispammethoden, aber so geht offenbar Neukundengewinnung. Auch nicht akzeptabel, aber was von dem, was derzeit so abgeht, ist überhaupt noch akzeptabel? Interessiert aber wohl eh niemanden mehr, die Ferengi könnten von uns wohl noch eine Menge lernen. Die einzige Erwerbsregel lautet: No rules.

    * A und * AAAA gilt für alle Subdomains, aber nicht für die nx-Subdomain, weil es für die einen Record mit Host nx gibt. Damit sind Wildcards wie * A oder * AAAA für die nx-Subdomain nicht relevant. Selbst wenn du nur einen nx A Eintrag hast und keinen nx AAAA, gilt auch der * AAAA trotzdem nicht mehr für die Subdomain nx. Wenn nx dann eine IPv6 Adresse haben soll, musst du den explizit setzen mit nx AAAA. Auch wenn es die selbe IPv6 ist wie bei * AAAA.

    Na, wenn du von

    @ A x.x.x.x

    @ AAAA x.x.x.x

    nicht wenigstens einen, normalerweise beide Einträge hast, dann mag das in "Unable to connect" resultieren :) , weil weder IPv4 noch IPv6 der Hauptdomain bekannt sind (per DNS). Irgendwo her sollte ja ssllabs schon wissen, wo sie nach der Domain suchen müssen. Bei der nx-Subdomain ist durch den Eintrag

    nx A x.x.x.x

    zumindest die IPv4 bekannt. Folglich kann die auch aufgerufen werden. Die Hauptdomain sollte weder mit noch ohne VPN funktionieren, außer du hast auf deinem PC

    irgendwo die Adresse drin, z.B. in der /etc/hosts Datei (Windows: C:\Windows\System32\drivers\etc\hosts).

    Da sollte Real-DD-2 mal klarstellen, was denn wirklich gewollt ist, sonst können wir da lange drüber diskutieren. Natürlich kann man beides machen, mache ich auch so, weil meine Server Mails verschicken von z.B. root@servername.meinedomain.tld und ich gleichzeitig die Hauptdomain selbst benutze (postmaster@...) um mich z.B. bei Microsoft (SNDS) für die IPs meiner sendenden Server zu registrieren. Also habe ich SPF, DMARC, DKIM für Haupt- und Subdomain(s) eingetragen. Hmm, das dürfte dort auch nicht mehr up to date sein, da stimmt nach den letten Aktionen wahrscheinlich keine IP mehr :rolleyes:. Muss ich über Weihnachten mal auf den aktuellen Stand bringen.

    OK. Dann war das nur missverständlich formuliert:

    Stimmt. Aufgrund dessen, dass der Transfer per Authcode nicht funktioniert hat, bin ich davon ausgegangen, dass es sich um zwei Webhostings im selben Account handelt. Ansonsten hätte es ja funktionieren sollen, habe ich ja selbst schon erfolgreich so gemacht. Naja, erfolgreich,.... ich fürchte das kaputte DNSSEC meiner Serverdomain rührt genau von diesem Umzug her. War jahrelang stabil, danach kaputt.

    Ja, zwischen zwei Kundenkonten geht es, das habe ich auch schon gemacht. Aber er hat ja ein Kundenkonto mit derzeit zwei Webhostings. Was man aber eventuell ändern könnte. Oder, wenn man einen anderen Kunden so gut kennt, dass man ihm die Domain anvertrauen möchte, dann ginge es auch ohne ein zweites, eigenes Kundenkonto. Aber gut, die Frage ist halt, ob einem die 5,-€ das wert sind.

    Also ich verstehe das als "auch außerhalb der reguläre Hotline-Zeiten". Zumindest solange die Wartezeiten beim regulären Support so sind wie sie sind. Die sind zumindest nicht "notfalltauglich". Aber wenn es nichts weiter Wichtiges ist, dann geh halt über den normalen Support.

    Der Support sollte dir da gar nicht weiterhelfen müssen.

    Im CCP bei der Domain unter Verwaltung steht:

    Zitat

    Information: Diese Inklusivdomain ist dem Webhosting Tarif fest zugewiesen. Der von Ihnen gebuchte Tarif sieht keine kostenlose Wechselmöglichkeit der Domain zu einem anderen Tarif vor.

    Angebot: Sie können Inklusivdomains zwischen zwei Tarifen wechseln, wenn der Tarif in den gewechselt werden soll, noch freie Plätze für Inklusivdomains mit der gleichen Topleveldomain beinhaltet. Abhängig von dem Tarif in den gewechselt werden soll, entstehen für den Wechsel unter Umständen Kosten. Die Höhe der Kosten errechnet sich aus folgenden Faktoren: Art der Topleveldomain, Mehrkosten für Verlängerung, Art des Tarifs in den gewechselt wird.

    Tipp: Zusätzliche Domains können Sie zu jeder Zeit zwischen Tarifen wechseln, ohne dass für den Wechsel Kosten entstehen.

    Für eine de-Domain fallen so einmalig 5,-€ an. Das ist die einfachste Möglichkeit. Ansonsten eben auf die Art wie von dir geschrieben. Umzug woanders hin. Dadurch könnte eine Wartezeit entstehen, während der kein weiterer Umzug möglich ist. In dem Fall musst du die Domain bis zum Ende der Wartezeit entweder gar nicht nutzen oder als externe Domain. Danach kannst du die Domain dann in dein neues Webhostingpaket umziehen oder als zusätzliche Domain registrieren. Das wäre flexibler, wenn du die Domain eventuell nochmal in einem anderen Webhostingpaket nutzen willst. Allerdings dann auch nochmal mit Kosten verbunden.

    Nein - weder noch. Mittlerweile wirken die Settings wie gewünscht/erwartet. Warum :?: Ich weiß es nicht - Und das ist das Final das größte Problem :!:

    Gleich danach folgt der Umstand, das ein Ticket nach 24 Stunden außer dem Autoreply keinerlei Reaktion erfährt :thumbdown: - auch hier stimmt die Anzeige des CCP (eigene DNS inkl IPv4 und IPv6 da NS in betroffener Zone (vor +72 Stunden eingetragen) nicht mit der Realität (DIG weist Netcup-DNS aus) überein.

    Bei kritischen Funktionalitäten wie der Namensauflösung hilft dann auch der Hinweis nicht, dass die (stellenweise echt tollen) Marketingaktionen zu längeren Bearbeitungszeiten führen. Im technischen Support? :/

    Ja, auch im technischen Support. Mehr Neukunden, mehr Fragen, bestehende und bekannte Probleme im DNS treten dann öfter auf, da einfach mehr geändert wird und auch mehr neuregistrierte Domains eigene Nameserver eingestellt bekommen. Es werden mehr Server verkauft als sonst, damit treten auch vermehrt Fehler auf. Zu alldem ist natürlich die Technik auch mehr gefragt, weil sie die Produkte ja auch bereitstellen müssen, also neue Hostsysteme aufbauen usw. Ist also schon ziemlich wahrscheinlich, dass querbeet durch alle Abteilungen zu solchen Zeiten mehr los ist. Wobei es bei wirklich dringenden Problemen (aka Notfälle ^^ ) eh ratsam ist, gleich den Notfall-Support anzurufen, jedenfalls wenn der Fehler erkennbar bei netcup liegt.

    Da hast du Recht. Da haben wir uns wohl in die Idee verrannt, dass die Mailcow über Port 24 nicht erreichbar ist, weil der Port geschlossen ist. Wird ja allerdings auch in Bild 2 so angezeigt. Aber klar ist, über den angegebenen MX und Hostnamen wird so nie eine Mail reinkommen können, weil der Sender den Namen schon gar nicht auflösen kann und somit nicht weiss, wo er die Mail abliefern soll.

    Also entweder "mail A IPv4-Adresse"

    oder gar nichts für mail eintragen, dann sollte die Wildcard greifen. Ich würde sicherheitshalber trotzdem lieber den A Record setzen, sonst würde jeder zusätzliche Record zum Host "mail", den man vielleicht irgendwann mal setzt, die Wildcard außer Kraft setzen für den Host mail und er hätte wieder keine IP-Adresse. ;)

    Mailcow läuft ja meist in einem Docker Container. Könnte eventuell sein, dass Port 25 zwar nicht auf Serverebene geblockt wird, aber nicht die Mailcow im Container erreicht. Aber da haben wir sicher viele Experten hier zum Thema Docker und Firewall. Ich gehöre da eher nicht dazu.

    Zu deiner Vermutung, dass netcup das blockt. Ich denke eher nicht, hatte ich jedenfalls bisher nie bei netcup. Bei anderen Anbietern muss man den Port 25 teils freischalten lassen, allerdings in der Regel ausgehend. Denen ist ja ziemlich egal, von wem du welche Mails empfängst. Die Sorge ist da eher, dass du Spam versenden könntest. Hast du "außen" (nicht im Docker Container) auf der normalen Betriebssystemebene vielleicht noch eine Firewall, die den Port blockt? Eventuell richtet das sogar Mailcow selbst so ein.

    Die UCEPROTECT L3 Blockliste wirst du ignorieren müssen. Das betrifft Netcup komplett, ist also nicht auf eine einzelne IP bezogen. Die benutzt aber eigentlich auch niemand, der Mails empfangen will.

    Edit: Mailcow wohl nicht Aber eine kurze Suche hat mich hierher gebracht:https://community.mailcow.email/d/4351-mailcow…xternal-network

    Da scheint die Lösung gewesen zu sein, die ufw zu disablen, weil die im Zusammenspiel mit Mailcow wohl Ärger macht.

    Das ist ein DKIM-Eintrag, den habe ich bei mir nirgends. Ich bezweifle irgendwie auch, dass der irgendeinen Sinn macht.Normalerweise hat man key1._domainkey und key._domainkey für den Webserver des Webhostingsund die Mail-Relays. Da müsste der Webmailserver die Mail schon direkt selbst versenden damit das irgendeine Funktion haben könnte. Ich gehe aber davon aus, dass der Versand per Webmail auch über die normalen Mail-Relays läuft.

    Ich teste gerade mal ... Ja, die Mail läuft über den Mailserver des Webhostings und ein Relay. von "s=mail" findet sich da nichts drin. Sieht also so aus, als ob der mail._domainkey keine Funktion hat, jedenfalls nicht für den Mailversand per Webmail.

    Nur nochmal um sicherzustellen, dass ich die derzeitige Konstellation richtig verstehe.

    1. Du hattest bei netcup einen "alten" Tarif. War das auch einer der aktuellen Tarife (Webhosting xxxx) oder wirklich ein ganz alter Tarif?
    2. Sowohl die Inklusivdomain als auch die zusätzliche Domain benutzt die netcup Nameserver (DNS-Records im CCP einstellbar)
    3. Die zusätzliche Domain ist aktuell dem neuen Webhostingtarif zugewiesen
    4. Das DNS beider Domains hat die Default-Einstellungen (ansonsten, was ist geändert)
    5. Unter welcher Adresse erreichst du die Webmail? Ist das https://webmail01.netcup.net ?

    Ansonsten, wenn alles richtig eingestellt ist, musst du eventuell nur ein wenig Geduld haben. Hat bei mir gelegentlich auch mal länger gedauert, bis meine Accounts per Webmail erreichbar waren (1-2 Tage). Da spielt wohl nicht nur (aber auch) DNS rein mit TTL usw, sondern es muss eventuell auch im Webmailserver erst einiges angepasst werden, damit der neue Mailserver deines Webhostings benutzt wird. So furchtbar falsch scheinen die Einstellungen ja nicht zu sein, wenn per IMAP alles klappt.

    Das hätte ich nicht gedacht. Dann kann ich aber pauschal sagen entweder oder weil ich davon ausgehen muss das jedes Admin-Interface so funktioniert (jetzt ganz/teilweise oder/und in Zukunft ohne Ansage).

    So Schwarzweiss würde ich das jetzt nicht sehen. Aber man muss sich eben auch mit einem Serverpanel schon etwas beschäftigen. Das ist kein Rundum-Sorglos Paket, es nimmt einem nur vieles ab bzw erleichtert manche Dinge. Ich benutze hauptsächlich Keyhelp. Unter anderem deshalb, weil ich da unkompliziert Kontakt zu den Entwicklern habe, die sich auch um Probleme kümmern und in manchen Fällen auch selbst mal in den betroffenen Server reinschauen. Hatte ich selbst zwar bisher noch nicht, kam aber schon vor.

    Auch da muss man sich damit beschäftigen (oder jemanden fragen, der sich damit auskennt), was das Serverpanel im Zweifel z.B. nach einem Neustart wieder nach seinen eingestellten Werten setzt und wo man eventuell abweichende Einstellungen am besten unterbringt, damit sie beim Neustart oder Panel-Update erhalten bleiben.

    Manche Einstellungen tangieren das Serverpanel gar nicht (eingestellte Resolver, nicht mit Keyhelp erstellte User, ...), manche werden (auch im UI) automatisch berücksichtigt und benutzt (fail2ban Jails, Swap, ...), andere erfordern zumindest ein eigenes Handling, wenn sie nach einem Neustart erhalten bleiben sollen (Firewall-Settings, die nicht über das UI eingestellt/verändert werden können, z.B. IP-Sets)