Beiträge von NaN

    Man beachte das "insbesondere" in der Auflistung von untersagten Handlungen. Das sind nur Beispiele. Allgemein gilt "Maßnahmen zu unterlassen, die zu einer Störung des Betriebs der Server von netcup führen könnten". Praktisch hat man bei den Root-Servern, obwohl die virtualisiert sind, dedizierte CPU-Kerne. Das heißt, deren CPU-Leistung steht einem exklusiv zur Verfügung und deren Auslastung stört nicht den Betrieb des Servers. Bei einem VPS wäre das anders: Dessen CPU-Leistung teilt man sich mit anderen Kunden und die Erwartung ist, dass die CPU nicht dauerhaft voll ausgelastet wird. Meine Erwartung als Kunde wäre allerdings, dass das erlaubte Maß technisch durchgesetzt wird. Da der Kunde nicht beurteilen kann, ab wann eine "Störung des Betriebs der Server" eintritt, würde ich eine Nutzung der CPU nicht als AGB-Verstoß werten. Die harte Grenze ist, dass Mining-Software ausdrücklich ausgeschlossen ist.

    Beachte die AGB:

    Zitat

    Untersagt sind insbesondere folgende Handlungen:

    [...]

    Betrieb von sog. "Mining-Diensten" für Kryptowährungen wie z.B. "Bitcoin", "Ethereum", "OneCoin" oder "Monero".
    [...]
    Betreiben von Serverdiensten , die eine besonders starke Rechnerlast verursachen; dies gilt nicht bei dedizierten und virtuellen Servern

    Falls die Verbindung nur getrennt wird, wenn ein paar Minuten nichts übertragen wird, macht dir wahrscheinlich eine "Middlebox" die Verbindung kaputt. Auch mit IPv6 und ohne NAT kann das z.B. eine stateful Firewall sein, wo die Verbindung ohne regelmäßigen Traffic rausaltert und dann irgendwann keine Pakete mehr durchgehen. Auf dem Client kannst du mit der Option ServerAliveInterval eine Zeit in Sekunden angeben, nach der ein Dummypaket zur Aufrechterhaltung der Verbindung gesendet wird, wenn in der Zwischenzeit kein anderer Traffic geflossen ist.

    vorschlagen, eine gleichlautende Domain nur mit einer anderen Endung (.com) für die E-Mails zu nehmen

    Kann man machen, aber nötig oder elegant ist das nicht. Email kannst du ganz einfach beim anderen Provider lassen (MX record nennt nur dessen Mailserver), während Web hier ist (A und AAAA mit den Adressen des Netcup-Webservers). Wenn der Webserver Mail verschicken soll, muss der entweder entsprechend in den diversen Antispam-Maßnahmen (DKIM, SPF, etc.) berücksichtigt werden oder einfach über den Mailserver des anderen Providers verschicken (SMTP-Smarthost). Das wurde aber alles schon genannt.

    Ihr könnt die Emails bei Netcup oder dem anderen Provider haben, aber nicht wirklich bei beiden für die selbe Domain. Dazu müsste einer von beiden als Backup-MX für den anderen konfiguriert werden. Letztendlich wären die Adressen nur bei einem der Provider und der andere würde die Mails nur für den anderen annehmen und weiterreichen. Abschicken geht bei entsprechender Konfiguration von beiden Providern, aber sinnvoll wäre es, auch das nur über einen der Provider zu machen. Die Webservices bei Netcup und die Emails beim anderen Provider zu haben ist aber kein Problem und je nach Mailaufkommen und Erwartung an zuverlässige Zustellbarkeit auch sinnvoll.

    Hast du dazu vielleicht einen Link

    https://openwrt.org/toh/ubiquiti/edgerouter_x_er-x_ka

    Wo läge denn der Vorteil drain, openwrt zu benutzen?

    Ich ging davon aus, dass dich irgendwas an EdgeOS stört, denn sonst hättest du das Gerät ja schon für diesen Zweck einsetzen können. Wenn dir EdgeOS zusagt, kannst du auch das nehmen. Schön an OpenWRT ist natürlich, dass es eine Menge Erweiterungsmöglichkeiten gibt. Aber viel CPU hat das Kästchen nicht übrig, wenn du den Durchsatz brauchst. Das mindert den Vorteil.

    Für den ER-X gibt es OpenWRT und das soll darauf auch NAT Hardware-offloading können und damit 2Gbps Full-Duplex schaffen. Die CPU ist davon abgesehen aber auch ohne Offloading (knapp) schnell genug für 1Gbps in eine Richtung. Da du das Gerät schon hast, würde ich es damit versuchen.

    Ich habe mal eine sehr spezifische Domain gehabt, die in keiner anderen TLD belegt war: Sogar die hat sich ein Grabber geholt. Inzwischen ist sie ihm allerdings wohl zu teuer geworden...

    Das geht und du kannst das auch mischen, also die DNS-Verwaltung deiner Domain bis auf den Letsencrypt Teil bei Netcup lassen und nur die Zertifikatausstellung über deSEC machen. Dazu legst du einen Namen bei deSEC an, wo der TXT Record für die Verifizierung landet. Auf diesen verweist du mit einem CNAME für _acme-challenge.<YOUR_DOMAIN>. Dann kannst du einen ACME Client für deSEC verwenden, um die Verifizierung durchzuführen und brauchst auf deinem Server keine Credentials für die Netcup DNS API zu speichern. So kannst du da auch nicht viel kaputtmachen.

    Das ist ein Bug, denn eigentlich gilt der CNAME nur für genau den Namen und nicht für Subdomains davon. "_acme-challenge.sub.my-domain.de." gibt es nicht, wenn du dafür nicht auch einen CNAME Record angelegt hast. (Anders ist das bei DNAME Records, die es bei Netcup aber nicht gibt.) Du solltest die TXT Records für "_acme-challenge.sub.my-domain.de." trotz des CNAME für "sub.my-domain.de." bei Netcup anlegen können und ein korrekt funktionierender Client sollte die auflösen können.

    Das ist die selbe Denkweise, die uns Zero-Rating gebracht hat: Wer was davon haben will, kann sich ja bei uns melden und unsere Spezialbedingungen erfüllen, dann nehmen wir den Dienst auch anstandslos ins Zero-Rating. Klar, und wer einen Dienst anbietet, muss dann alle Provider abklappern und schauen, welche Extrawürste die verlangen, und mit jedem extra Verträge machen. So funktioniert das Internet nicht und so funktioniert auch Email nicht. Erst recht nicht, wenn viele Provider die Ablehnung weder dem Absender noch dem Empfänger mitteilen. Die Emails verschwinden einfach, denn man will ja nicht backscattern, aber das System so konstruieren, dass schon im SMTP-Dialog abgelehnt wird, ist einigen anscheinend auch zu teuer.

    Man nimmt Email an. Im Zweifelsfall kann man die als wahrscheinlichen Spam markieren oder in einen Spam-Ordner zustellen. Dann kann der Empfänger eine Ausnahme festlegen. Aber gar nicht annehmen, nur weil mir dein Hoster nicht passt, geht gar nicht. Ablehnung hat einen inhaltlichen Grund zu haben.

    Ich denke das Problem sind die immer wieder neu gestärkten Sicherheits Standards gegen Spam.

    Die Anforderungen von T-Online sind aber keine "Sicherheits Standards" sondern "dich kenne ich nicht, von dir nehme ich keine Email an", oder schlimmer: "Der da drüben sagt, er mag deinen Postboten nicht, also nehme ich von dir keine Emails an." Mit solchen Leuten kann man nicht zuverlässig kommunizieren. Wer weiß, welche Ausrede die sich morgen einfallen lassen.

    Hast du dich bei den größeren Providern wie t-online, GMX, Web.de,gmail, hotmail via IP/domain "persönlich" verifiziert?

    T-Online benötigte nach einem Postmaster Ticket einen link zum Impressum und eine kleine Beschreibung wer wir sind und was wir machen.

    Email zerfällt langsam aber sicher in ein paar große Inseln, deren "Außenverteidigung" so unberechenbar wird, dass sich der Versuch nicht lohnt, sie zu überwinden, wenn Zuverlässigkeit das Ziel ist. Verweigerung der Annahme von Nicht-Spam, der den üblichen technischen Anforderungen genügt, nur weil dem Empfängersystem der Absender nicht gefällt, würde ich als Annahmeverzug und Fehler des Empfängers betrachten. Egal wie geplagt die Admins dieses Systems sind: so etwas ist nicht akzeptabel. Sippenhaft ist in Deutschland nicht zulässig. Man kann als Absender versuchen, darum herum zu arbeiten, aber letztendlich muss man sich fragen, wie viel Arbeit und Geld einem das Wert ist, wenn am Ende doch keine Zuverlässigkeit erreicht werden kann, weil die Betreiber in der aktuellen Konstellation niemandem Rechenschaft schuldig sind und diese Freiheit willkürlich nutzen.

    Mittelfristig würde ich versuchen, für die störrischen Betreiber, die groß genug sind, von Adressen bei diesen Betreibern zu versenden, aber nicht die eigentliche Email, sondern lediglich den Hinweis, dass Email wegen Willkür des Betreibers nicht zugestellt werden konnte und sich der Kunde bitte in seinen Account einloggen soll und für ihn bereitliegende Unterlagen dort einsehen kann.

    Die Fähigkeit, sich ein 16-stelliges zufälliges alphanumerisches Geheimnis zu merken und kryptographische Hashes darüber im Kopf zu berechnen, ist beeindruckend, aber wir Normalsterbliche müssen sowas ein Gerät erledigen lassen. Das ist für die meisten das selbe Gerät, das auch die Passwörter speichert. Ob beides in der selben App oder getrennt in einer "Authenticator App" und einem Passwortmanager gespeichert wird, ist egal. Ein Hardwaretoken könnte eine leichte Verbesserung sein, aber dann kommt jemand und empfiehlt, einen Screenshot vom QR-Code mit dem Secret zu machen, damit man bei Verlust ein neues Token aktivieren kann...