Beiträge von Mainboarder

    greylisting gibt in verbindung mit blacklists den spammern zeit, auf eben diesen blacklists zu landen und nicht bei dir im postfach.


    china blockieren ist eigentlich immer gut. unabhängig von dem mailthema.


    blockieren von falschen PTRs macht noch sinn, und unknown clients reject code habe ich auch 550. wenn eine adresse nicht existiert, wird das bei mir durch mehr zeit auch nicht besser.


    zusammen mit ix manitu, spamcop und spamhaus in der richtigen gewichtung (ist immer vom mailsystem abhängig), habe ich ca. 1 spammail im halben jahr

    Auch ich möchte mich mal wieder zu wort melden.
    Die neuen root-server sehe ich als produkt, was man bestellen kann, wenn es ein ambitioniertes hobby oder entsprechend mehr ist. die vps eignen sich weiterhin auch für testzwecke.
    auf meinen fall bezogen (und hier konkurriert netcup vorallem mit den vorherigen angeboten) ist mir rechenleistung wichtiger als alles andere (neben einer kurzlatenzigen anbindung)
    der vorteil für privatpersonen von einem plus von 0,3% in der mindestverfügbarkeit halte ich für zu vernachlässigen, obwohl das durchaus um einiges höhere kosten verursacht.
    wenn ich meinen server (der, der vorher 8,50€ pro monat kostete) mit dem vps 2000g7 vergleiche, so ist aus DDR4 DDR3 RAM geworden, aus dedicores vcores und aus der SSD SAS. Das RAID ist glaube ich "besser" geworden von (da bin ich mir nicht sicher) RAID 5 auf 10.
    Das sieht mir unter dem strich nach einer kaschierten Preiserhöhung aus. Ich will das aber nicht verteufeln, so funktioniert das nunmal.


    In meinem Fall bräuchte ich beispielsweise weniger RAM. Trotz Linux liegt bei mir weit über ein GB brach. Ich schätze allerdings, dass der RAM so groß bemessen ist, um swapping und damit eine geringere Latenz der platten für alle auf dem node zu vermeiden.


    mein wunsch wäre, dass man für die generation 7.1 oder 8 überlegt, ob eine wahlmöglichkeit bestimmter parameter (wie bereits vorher mit SAS oder SSD geschehen) durch den kunden nicht interessant ist. so sieht es für mich aus, als sei die wahl zwischen dedi- und vcores etwas, das durchaus von kunden begrüßt werden würde. Und sofern das machbar ist, ist auch die mindestverfügbarkeit ein kriterium, was privatpersonen meist vernachlässigen könnten

    das ist nur der dns eintrag.


    leider schweigt microsoft was man machen muss, damit man zumindest erfährt, dass emails nicht zugestellt werden. von daher ist das nur eine option, die die zustellbarkeit verbessern kann.

    Nutzt du SPF oder ähnliche Sicherungsverfahren?


    Kann mir vorstellen, dass diese Provider anhand der Header meinen, das sei spam und die Mails still verwerfen. (PHPMailer schreibt sich da rein und wird auch gern für spamversand genutzt.)


    Leider ist das stille Verwerfen zumindest bei Microsoft gang und gäbe.


    SPF o.ä. kann dagegen helfen. muss aber nicht

    An deiner Stelle würde ich eher etwas wie duplicity bevorzugen und mich damit weniger auf IMAP festlegen, sondern direkt auf die Ordnerstruktur auf dem Server.
    Ich bin mal so frech und verlinke meine Lösung: GitHub - mainboarder/Froxlorbackup: Backup your Froxlor Webhosting to another server. Encrypted, via ssh.


    Damit einen Cronjob einrichten, den Pfad zum Emailaccountordner auf dem Server angeben und dann wie es wo zum NAS gesynct werden soll.


    Dann hast du ein inkrementelles backup von einer Software, die dafür ausgelegt ist, ohne viel klimbim


    voraussetzung ist allerdings, dass das ein linuxserver ist, wo du ssh zugriff hast

    bei der denic werden auch telefonnummer und fax von inhaber und admin-c hinterlegt. diese sind auch öffentlich einsehbar für alle mit zugriff auf "das große whois".
    Dies sind insbesondere die DENIC-Mitglieder.


    die kleinere version für jedermann, die auch über ein captcha geschützt wird, enthält dagegen diese daten nicht.

    Hallo Hinti,


    ich kann dich beruhigen.
    Von deinem Server stammt die Mail nicht.


    Du erhälst gefälschte Mails. Das ist leider einfach möglich und mittels DKIM oder SPF eingrenzbar.


    Du kannst die gefälschten Mails an spamcop.net melden. Hier werden sie dann dem Provider des Verursachers mitgeteilt, welcher hoffentlich etwas dagegen unternimmt.


    Vielleicht kennst du das "Ihre Telekom-Rechnung"-Problem? Du bist jetzt genau in der Position der Telekom. In deinem Namen werden Mails verschickt und andere Mailserver lassen sie durch, weil bei dir vermutlich Schutzmaßnahmen fehlen. Selbst beim Vorhandensein können diese noch durchkommen, dann ist aber der empfangende Mailserver nicht vernünftig eingerichtet

    ich möchte dich mal aus meinem altag darauf hinweis, dass gerade im magento-bereich für das hosting monatlich für größere sachen eher ein betrag nah am dreistelligen bereich oder bereits darin verlangt wird.


    du wünschst dir scheinbar vorallem eher mehr rechenleistung. da könnte man jetzt ein neues produkt schnüren, wo mehr rechenleistung drin steckt. das kommt aber auch darauf an, wie die cloudinfrastruktur gebaut ist.
    und wie bereits erwähnt wurde, ist ein managed server hier eher etwas, was deinen technischen bedürfnissen entspricht.


    preislich etwas zwischen teuersten hosting und günstigsten managed server zu machen, scheint sich für Netcup nicht zu rentieren.


    bitte fühle dich nicht angegriffen, aber ich würde meine strategie hinterfragen, wenn ich einen so scheinbar mächtigen shop zu betreiben habe, aber damit nur um die 20€ für hosting ausgeben kann

    wenn die nicht gerade eine 0900er Supportnummer haben, würde ich dort mal anrufen und nachfragen.


    Es klingt jetzt eher so, als sei da bei denen etwas schief gelaufen. Änderungen bei der DeNIC gehen in Echtzeit und da man dir die Änderung bestätigt hat, denke ich, da wird irgendwo was klemmen.


    Also eine böse Absicht würde ich da nicht direkt unterstellen, weil es ja auch keinen Sinn macht mit der Existenz des Auth-Code2 Verfahrens. Außer, dass man seine Kunden schikaniert.

    Ich poste jetzt mal nur einen Auszug mit dem wichtigsten:


    Sagt mal...
    Man kann nicht vorab DNS Einträge zu einer Domain hier anlegen, die noch nicht hier ist, richtig?


    Das ist etwas schade, würde es doch unter Umständen etwas Stress ersparen.


    Man kann ja auch schreiben, dass die Zone inaktiv bleibt, bis die Domain hergezogen ist und nach X Tagen gelöscht wird, wenn kein Umzug erfolgt...
    Da ja am Resellerfeature für Domains gearbeitet wird, wäre das etwas, was man gleich in dem Projekt mit implementieren könnte.

    Das ging dann so weiter:


    Ich schrieb dem BSI


    Das BSI schrieb, sie haben die Telekom informiert und es wird gepatcht.


    Habe festgestellt, dass auch 1u1 und die epost betroffen sind und schrieb dem BSI.


    Das BSI schrieb, dass man als Nutzer selbst dran schuld ist, wenn man einen Browser hat, der RC4 auswählt, man aber allen De Mail Anbietern nochmal bescheid sagen will.


    "Es handelt sich bei den Cipher-Suiten um Optionen, die der Server dem Client anbietet. D.h. der vom Nutzer eingesetzte Browser muss diese Cipher-Suite auswählen. Die bevorzugte Cipher-Suite (aus Sicht des Servers) bei den Systemen der Telekom ist "TLSv1 256bits AES256-SHA" und bei 1&1 "TLSv1 ECDHE-RSA-AES128-SHA". Eine gewisse Verantwortung liegt hier auch bei dem Nutze. Denn nur, wenn der Client des Nutzers diese schwache Cipher-Suite mit RC4 auswählt, kommt diese auch zum Einsatz." (De-Mail Team, Rechtschreibfehler so im Original)


    Ich schrieb, dass die Geld dafür nehmen und eine als sicher beworbene Dienstleistung verkaufen und man dann auch erwarten kann, dass der Anbieter sein mögliches macht, das System zu sichern, zumal es in einer Richtlinie von denen explizit drinnensteht, dass man kein RC4 mehr zu verwenden hat.


    Bei den De-Mailanbietern war dann RC4 verschwunden (bei 1u1 bin ich mir gerade nicht 100% sicher), bei der epost müsste es das noch geben. Die Telekom hat aber recht vernünftige Algorithmen danach aktiviert.


    Von der epost kommt da auch bloß zurück, dass deren Spezialexperten sich bewusst dafür entschieden haben und beobachten wie groß die Verbreitung ist:


    „Der geschilderte Sachverhalt ist zutreffend: Das E-POST Portal ermöglicht derzeit noch Verbindungen auf Basis von RC4. Dies dient der Unterstützung von Browsern, die noch kein TLS 1.2 nutzen. Um gegen BEAST-Angriffe zu schützen haben unsere Experten die Verwendung von RC4 für TLS 1.0 und 1.1 ausgewählt. RC4 bietet gegenüber der Verwendung von Block-Ciphern im CBC-Modus (TLS 1.0 und 1.1 unterstützen keine anderen Modi) einen besseren Schutz.

    Der Browser gibt beim Verbindungsaufbau die TLS-Version vor. Aktuelle Browser verwenden automatisch TLS 1.2. Ein TLS-Downgrading wird serverseitig verhindert. Somit ist sichergestellt, dass immer das höchstmögliche Sicherheitsniveau für HTTPS-Verbindungen genutzt wird.

    Wir führen kontinuierliche Auswertungen über die eingesetzten Ciphersuites durch und passen unsere serverseitige Ciphersuite-Konfiguration entsprechend an. Das Nutzerverhalten in Bezug auf die eingesetzten Browser muss für die Umsetzung des RFC 7465 aber berücksichtigt werden."