Test? Erster!
(Bezieht sich auf die Wartungsarbeiten.)
Klappt, jetzt warten wir mal auf die Behebung des Strota-Problems beim Mailversand von netcup aus. Nachdem mittlerweile auch die zweite Testmail von heute in der selben Warteschleife kreist wie die erste von vorgestern, erwäge ich ansonsten Strafzölle auf von Strota bei mir eingehende Mails, die ganz im Gegensatz zur Gegenrichtung ganz normal zugestellt werden. Wo bei UCEPROTECT kann man denn spammende Mailanbieter melden? 
.
Von welcher Absenderadresse? Netcup? Oder wessen Kunde sollst du hier angeblich sein, wer migriert hier angeblich die Webmail-Dienste zum Mitbewerber?
So, habe jetzt gerade eben die gleiche Mail bekommen. Nal wieder auf eine "info@"-Adresse., mal wieder versendet über das rote H, Standort Finnland, der Link geht nach Russland, jedenfalls gehört die IP zu einem russischen Anbieter. 
Hat jemand schon mal diese Phishing-Mail bekommen (kam auf eine Domain, die bei NC liegt)?
Von welcher Absenderadresse? Netcup? Oder wessen Kunde sollst du hier angeblich sein, wer migriert hier angeblich die Webmail-Dienste zum Mitbewerber?
Wenn ich mal so ins Blaue spekuliere ... Strota sagt ja was von rate limit und netcup kann es sich nicht erklären. Wie lange läuft denn eigentlich die Mail vom netcup-Webhosting schon über relay.yourmailgateway.de?
Weiss Strota, dass das die gesammelten Mails aller netcup-Webhostingkunden sind und nicht igendein einzelner Absender. Jedenfalls würde ich mir erwarten, dass netcup hier Kontakt zu Strota aufnimmt und versucht, das Strota klar zu machen. Ob das was hilft weiss ich zwar auch nicht, aber zumindest könnte man so eventuell einmal die tatsächlichen Gründe für die Abweisung miteinander abklären.
Jedenfalls sieht es ja so aus, dass wirklich alle netcup-Webhostingkunden derzeit davon betroffen sind. Und ich dachte hier vor gar nicht langer Zeit gelesen zu haben, dass sich die Zustellbarkeit verbessert hätte.
Und wenn am Ende gar keine Einsicht seitens Strota zu erkennen ist, dann kann man ja auch mal dezent andeuten, dass auch die Zustellung von Strota Mails an netcup-Kunden nicht zwingend selbstverständlich ist.
Trotzdem, man sieht hier schon einen Unterschied. Ich habe mir von Strota-Account jetzt mal an meinen Mailserver geantwortet und rspamd meint
RBL_SENDERSCORE_REPUT_9 • SenderScore Reputation: Good (90-100). (-1) [81.169.146.221:from]
Der Unterschied wird wohl nicht grundlos sein. Außer natürlich wenn Strota die geblockten Mails an die Senderscore -Liste meldet und die Reputation des Mail-Gateway deswegen so im Keller ist
Nach Rücksprache mit dem Support;
Str*** blockt, man weiß aber nicht warum.
Umzug auf einen anderen Node ist (technisch) "nicht weiteres möglich".Man empfiehlt mir einen Managed Private Server mit dedizierter IP.
Faktisch kann also von Netcup aus an Str*** keine Mails versendet werden.
Nach dem ganzen Theater denke ich ohnehin, dass es besser ist zumindest für Mails einen verlässlicheren Anbieter zu nehmen.
Ja, aus dem Webhosting heraus kommt von mir auch nichts bei Strota an. Ich warte mal, ob es nur Greylisting ist, aber wenn es bei dir abgelehnt wurde, dann gehe ich hier zunächst auch mal davon aus.
Habe mir dann selbst eine Mail aus dem Webhosting zu meinem Mailserver geschrieben. Die kommt vom selben Absender problemlos an. Naja, was man halt so problemlos nennt...
Aus dem Nachrichten-Quelltext:
Received: from relay.yourmailgateway.de (relay.yourmailgateway.de [188.68.63.102])
rspamd auf meinem Mailserver sagt dazu:
RBL_SENDERSCORE_REPUT_1 • SenderScore Reputation: Bad (10-19). (3.5) [188.68.63.102:from]
Das könnte dann schon ein möglicher Grund der Ablehnung seitens Strota sein. Auf einer Blacklist ist die IP aber nicht, jedenfalls auf keiner von denen, die mxtoolbox.com checkt.
Mail von meinem Mailserver (netcup VPS) geht bei Strota problemlos durch. Das Problem liegt liegt also recht eindeutig beim Mail-Gateway von netcup (oder seinen Benutzern 
)
Habe nicht unbedingt behauptet, dass das meine Meinung ist... ich habe wie gesagt DNSSEC über netcup erfolgreich aktiviert, funzt und darf gerne auch so bleiben
Momentan läuft der Betatest einer komplett neuen DNS-Verwaltung. Wann diese soweit ist, dass sie die derzeitige Verwaltung ersetzt, weiss ich nicht.
Bisher ist DNSSEC leider auch ein wenig Glücksache. Ich hatte Domains, da war DNSSEC aktiviert und auch nach Jahren noch ok. Allerdings hatte ich auch einige (wenige) Domains, da war DNSSEC irgendwann komplett kaputt, was dann soweit ging, dass DNS-Abfragen zu der Domain von manchen Resolvern (die DNSSEC prüfen) nicht mehr erfolgreich waren. Sprich, die Domain war dann halt für viele User nicht mehr erreichbar. So etwas möchte man natürlich bei einer wichtigen Domain möglichst nicht haben.
Ich habe daraufhin dann DNSSEC vorsichtshalber bei allen Domains deaktiviert, bzw. für die wichtigen die Nameserver auf deSEC umgestellt. Nur bei einer unbenutzten Domain habe ich DNSSEC aktiviert gelassen um zu sehen, ob es Fortschritte gibt oder ob das Risiko weiterhin besteht. Bisher ist bei dieser Domain nichts passiert. Da die Probleme aber relativ selten aufzutreten scheinen - auch wenn es hier im Forum anders rüberkommen mag - ist der Test mit einer einzelnen Domain natürlich im positiven Sinne wenig aussagekräftig. Naturgemäß wird hier im Forum eher von den Fällen berichtet, bei denen Probleme auftraten.
Alles anzeigenBei dem Thema DNSSEC bin ich vor geraumer Zeit mal auf diese kritischen Beiträge gestoßen (Thomas Ptacek ist u.a. bei Hacker News sehr umtriebig und hat früher auch viel auf Reddit gepostet) - paste die Links hier mal rein, falls es jemanden interessiert und nicht bereits bekannt ist... nette Bettlektüre auf jeden Fall (leider nur in englischer Sprache verfügbar und aus einer sehr amerikanischen Perpektive heraus argumentiert):
https://sockpuppet.org/blog/2016/10/2…l-the-internet/
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
https://sockpuppet.org/stuff/dnssec-qa.html
Hey netcup! Great news for you! No need to try any longer to get your DNSSEC straight! Just skip the check box in the DNS-Editor and remove this completely bad and useless feature once and forever. 
Letztendlich muss DNS einfach funktionieren. Wirklich 100% sicher wird das nie werden. Da muss dann jeder für sich selbst überlegen wieviel Arbeit man sich für 0,5% mehr Sicherheit machen möchte.
Der Anbieter kann nur die Möglichkeiten anbieten, jeder kann dann gern clientseitig entscheiden, ob er sie nutzen will oder nicht. Ich benutze weder die DNS-Server noch die Resolver von Cloudflare und Google. Wenn ich natürlich eine Website von Cloudflare, Google, Microsoft oder sonstigen "No-Rules" Anbietern aufrufe bzw aufrufen muss, dann habe ich in puncto Datenschutz sowieso verloren. Da ist DNS dann schon weitgehend irrelevant.
Welche (Mehr-)Arbeit durch die Benutzung von deSEC im Vergleich zu Cloudflare bei mir anfällt, erschliesst sich mir aber erst einmal nicht. Ich sehe das eher als 0,5% weniger Arbeit für 0,5% mehr Sicherheit, wenn wir bei der fiktiven Zahl mal bleiben wollen.
Das ist also genauso praktisch bzw etwas unpraktischer als bei deSEC, da dort DNSSEC grundsätzlich aktiviert ist und die restlichen Schritte sind natürlich identisch.
In der derzeitigen Lage - und auch schon vorher - bevorzuge ich in puncto Datenschutz einen deutschen eingetragenen Verein jederzeit vor einem US Techgiganten. Germany First
Nö, der Link aus dem letzten Post geht auf die Seite, die unter "jetzt Deal sichern" in deinem Screen verlinkt ist. Und da steht es einmal oben und dann nochmal weiter unten unter "Leistungen Webserver und Datenbankserver". Immer abhängig vom ausgewählten Standort. Bei Standort Nürnberg steht da "1 .de Domain". Manassas wäre "1 .com Domain" und Wien "1 .at, .de oder .eu Domain"
Ja, zumindest steht da 1 .de Domain.
Wo genau finde ich das denn?
Bei mir finde ich diesen Punkt im CCP nicht.
Es ist ein Hosting 1000 aus der laufenden Aktion.
Schon klar, aber anhand der Werbung dafür hätte ich eine etwas üppigere Menge erwartet. Zumindest aber ein Cloudsystem (ok, ich will nur caldav und carddav davon benutzen, aber eben oneklick)...
Ich kann mich an ein früheres Webhostingpaket sonstwo erinnern, bei dem eine mindestens 3stellige Auswahl da war...
Ja, beim 1000er gibt es keine "int" Version., da hängt alles am Standort, sieht man jeweils wenn man den Standort auswählt in den Produktdetails
Nürnberg: 1 .de Domain
Wien: 1 .at, .de oder .eu Domain
Manassas: 1 .com Domain
Die 1-Klick Apps waren bei netcup - zumindest vor Jahren, als mich das noch interessiert hat - noch einige mehr als jetzt, aber nicht 3stellig und alles andere als aktuell. Wie es jetzt mit der Aktualität ausssieht weiss ich nicht, musst du halt bei Bedarf selbst testen. Nextcloud auf einem Webhosting 1000 wird wohl auch, hmm, schwierig. Die von dir benötigten Teile davon mögen funktionieren oder auch nicht. Auf einem 2000er hatte ich Nextcloud vor Jahren mal am Laufen. Oneklick war das damals aber definitiv nicht.
Es gibt zwei Varianten mit Standort de, "Nürnberg int, Deutschland" und "Nürnberg, Deutschland. Der erste ist der mit den alternativen Domains. Hier steht in unter Konfiguration, wenn man diesen Standort auswählt (hier am Beispiel Webhosting 4000 NUE int MAR25 :
Hinweis: Mit dieser Standort-Konfiguration sind zwei Alternativ-Domains (wahlweise mit der Endung .at, .com, .li, .ch, .eu oder .de) im Tarif inkludiert.
Installierbare Apps sind solche, die mit 1-Klick Installation verfügbar sind. Nextcloud gehört laut deiner Aussage nicht dazu (ich habe nicht nachgeschaut,halte es aber für wahrscheinlich ) Du kannst natürlich trotzdem Nextcloud installieren mit dem Nextcloud Installer (von Nextcloud) Du kannst sicher noch ein paar Tausend andere Apps installieren, aber halt nicht "mit einem Klick in Plesk/WCP" und ohne dich selbst damit befassen zu müssen.
Das würde doch die Mailzustellbarkeit drastisch verbessern , insbesondere zu Microsoft-Adressen. Dann kann ich meinen Account bei der grünen Mailbox kündigen und die 2,50 € in 2,5 "migrierte" Mailadressen investieren. Guter Deal! 2,5 gut zustellbare Adressen statt momentan > 50. Aber dafür von den US-amerikanischen Geheimdiensten zuverlässig archiviert! Muss man dann halt abwägen.
Ja, habe ich schon vor einigen Tagen mitbekommen. Frechheit sowas. Naja, mal sehen, wie viele sich erpressen lassen und wie viele den Hoster wechseln. Was ich sowieso schon seit Jahren geraten habe. Die ersten Absetzbewegungen sind mittlerweile aber schon zu bemerken. Da sieht man mal wieder, was an einem Webhosting-Paket den Kunden am Wichtigsten ist. Als sich einiges im Bereich Web zum Schlechteren geändert hat, haben sie gemeckert aber wollten nicht wechseln. Offenbar ist Mail vielen wichtiger, jedenfalls ist das Geschrei jetzt deutlich lauter.
Sieht si aus, als ob PHP da Zugriffe außerhalb der document root machem will und nicht darf -> open_basedir Einstellung checken und die zweite Variante mit WEBSPACEROOT wählen.
Hätte der Scammer nun aber Spam verschickt würde das gesamte Produkt gesperrt werden.
Das könnte dann auch ein root Server sein mit 50 Projekten.
Ich glaube, dass die Lösung ein schnelleres und selektives Sperren wäre:
Spam vom Mailaccount -> smtp ausschalten (anderes Passwort)
Spam vom Server direkt -> A Record umbiegen
Wo liegt das Kundenpostfach bzw der smtp-Server?
Auf dem Server selbst? Dann wird es nicht gelingen, nur das Passwort zu ändern.
Gerade bei einem Root-Server ist es natürlich sehr schwierig, selektiv den Postausgang für nur ein Postfach oder einen Kunden zu sperren. Der Server ist weitestgehend eine Blackbox für netcup, da kann man bestenfalls den smtp-Port ausgehend sperren, soweit das die Netzwerk-Infrastuktur überhaupt hergibt. Selbst dann sind aber alle Kundenpostfächer und auch die administrativen tot.
Wird der Spam über einen netcup-SMTP-Server versendet, dann wäre es möglich, selektiv zu sperren. Das kann dann aber eigentlich nur ein Postfach in einem Webhosting oder einem Reseller-Webhosting sein. Ist es ein Webhosting des Kunden bei netcup, dann wird sowieso dieses Webhosting gesperrt werden und nicht der Server, womit die anderen 49 Kunden nicht betroffen wären.
Falls du mit "Spam vom Server direkt" z.B. eine gehackte CMS-Installation meinst, den A-Record kann netcup auch nur dann umbiegen, wenn die Nameserver der betroffenen Domain auch bei netcup liegen. Den A-Record der Serverdomain umzubiegen wird wohl nicht viel bringen, da ist dann höchstens das Serverpanel betroffen. Und das geht auch nur, wenn die Serverdomain netcup-Nameserver verwendet. Das ist bei mir z.B. nicht so, da müsste netcup dann schon die Nameserver erst wieder auf die netcup-Server zurücksetzen. Außerdem ist dann die gehackte Website immer noch zu erreichen über den A-Record der Kundendomain.
Spannende Frage, kriegt man auf dem ARM Server ein Ubuntu? Ich bin echt *'*++POi'++ darüber, dass die mir beides Verkaufen, ohne den geringsten Hinweis dazu.
Debian (12) Bookworm arm64 / Minimal, ...
Ubuntu 22.04 LTS arm64 / Minimal, ...
Ubuntu 24.04 LTS arm64 / Minimal, ...
Das sind die für ARM verfügbaren offiziellen netcup-Images, die über das SCP installiert werden können. Ausgeliefert werden derzeit alle Server mit Debian 12.
Ich finde es aber ein wenig schwach von Plesk, dass die nichts für Debian 12 anbieten. Wäre allein schon ein Grund für mich, kein Plesk auf meinen ARM-Servern zu verwenden.
Edit: Wie von abo geschrieben, kannst du aber natürlich auch anderes selbst installieren.
Auf ARM läuft Plesk nur unter Ubuntu 22.04
OMG . Da bin ich ja mit Keyhelp wirklich besser dran. Da geht das mit Debian 12 problemlos.
Yes, you can have email hosted somewhere else. But you will have to set the DNS records temporarily to the values asked by the popup window. Once the external domain is connected to netcup, you can set the DNS records completely to your liking. I know this is not the way it should be, I think it's possible to lose some mail this way, because for a period of time the MX records will point to a mail server, that will not accept incoming mails because the user (mail address) doesn't exist (on this server).
So, I think this should be handled in a better way. I'm pretty sure it is possible to prove ownership of the domain in another way, e.g. a TXT-record defined by netcup, that needs to be set in the DNS. Some others do it that way. But for the time being we have to live with it here at netcup.
