Beiträge von NaN

    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...

    Mit den heutigen Anforderungen an Passwörter sind Passwörter und TOTP die gleiche Faktor-Kategorie: "etwas, das man hat". Damit unterliegen beide sowieso den gleichen Risiken. Die Aufbewahrung am selben Ort steigert das Risiko nur minimal, da immer beide gemeinsam benötigt werden. Der Vorteil des TOT-Passwort-Geheimnisses ist nicht so sehr, dass es ein zweiter Faktor ist, sondern dass es im Anmeldevorgang nicht übertragen und nicht eingegeben wird. Wenn man das Zurücksetzen von TOTP-Secrets kostenpflichtig macht, braucht man sich über die Ablage in Passwortmanagern nicht zu wundern.

    aber als E-Mail-Adresse trotzdem eine T-Online-Adresse haben.

    Und woran sollen die Kunden sonst auf den ersten Blick erkennen, was die Email-Adresse ist, wenn kein t-online.de, aol.de, gmx.de, web.de oder ähnlich bekannter und folglich vertrauenswürdiger Email-Betreiber in der Adresse steht?

    Neumodischer Kram. Praktisch jeder mit einem praktischen Beruf hat eine t-online.de Email oder etwas vergleichbares. Mit einer eigenen Domain ist man einfach nicht vertrauenswürdig. Ich musste schon mehrmals erklären, dass das meine echte Email-Adresse ist. "Haben Sie keine GMX-Adresse?"

    Ob das grundsätzlich funktioniert, hängt davon ab, welche Informationen über die Installation mit der Registrierung verknüpft werden. Wenn z.B. die MAC-Adresse der Netzwerkkarte oder die CPU-ID in die Registrierung einfließen, nützt dir ein Festplattenabbild nicht viel. Diese Werte sind dort nicht enthalten sondern kommen von der virtualisierten Maschine, in der diese virtuelle Festplatte steckt.


    Wenn man von Snapshots spricht, werden Festplattenabbilder oft relativ zu einem anderen Fesplattenabbild gespeichert, so dass nur die Veränderungen ab dem Snapshot in dem neuen Abbild vorhanden sind und alles andere aus dem alten Abbild kommt. Wenn du einen Server aufsetzen willst, braucht der Server ein komplettes Festplattenabbild. Das kannst du auf verschiedene Art und Weise bekommen, z.B. über "Appliance exportieren" in VirtualBox, s.o..


    Die Exportfunktion für Snapshots brauchst du nur dann zwingend, wenn du deinen virtuellen Server nicht anhalten kannst oder willst. Sonst kannst du, wenn du dich mit der Kommandozeile genug auskennst, auch aus dem Rescue-System heraus ein Abbild der Festplatte herunterladen.

    Danke für die Korrektur. Das muss ich mit einem anderen Hoster verwechselt haben.


    Ich glaube aber, dass der Fragesteller sowieso eine falsche Vorstellung hat, was ein Snapshot ist, und das bei der Problemstellung nicht weiterhilft. Am Ende braucht man einfach ein vollständiges Festplattenimage. VirtualBox hat eine Funktion "Appliance exportieren". Die erstellt ein OVA-Archiv, in dem ein Festplattenimage mit dem aktuellen Zustand enthalten ist. Das Archiv kann man (z.B. mit 7zip) auspacken und die Image-Datei mit vbox-img in eines der von Netcup unterstützten Formate konvertieren. Das sollte der Server akzeptieren.

    Ich denke, dass der Weg, wie das Image auf den Server kommt, nicht entscheidend ist. Vermutlich stimmt irgendwas mit dem Image nicht. Wenn hier so viel über Snapshots geredet wird, liegt nahe, dass das Image kein alleinstehendes Image ist, sondern vielmehr ein Differenzimage ist, das ein anderes Image referenziert. Das kann der Server dann ohne das Referenzimage nicht einbinden.


    Die Snapshot-Anzahl bei Netcup ist die Anzahl gleichzeitig auf dem Server bestehender Snapshots. Wenn einer gelöscht wird, ist auch wieder einer frei. Da Snapshots potenziell groß sind und von deinem gebuchten Festplattenspeicher abgehen, will man es damit i.d.R. nicht übertreiben.

    Wenn der Server die Domain noch kennt, kannst du auf dem Client die IP-Adresse des Servers in die hosts Datei eintragen und damit das Domain Name System umgehen.