Posts by sudo

    Ok, vielleicht nicht gebeten, aber es gab keinen Wider-, sondern Zuspruch:

    Quote

    This SBL listing has been set up in agreement with the Internet provider responsible for this IP range

    Die IP ist z.B. auch bei der Blockliste Spamhaus gelistet und dort steht dazu (https://check.spamhaus.org):

    GMX hat also Spamhaus sogar explizit drum gebeten, die IP zu listen, da diese für den Versand von Mails genutzt wird, die dort (beim Absender GMX) als Spam erkannt wurden.


    Du hättest aufgrund der umfangreichen Nutzung von Spamhaus dieses Problem somit vermutlich auch bei vielen anderen Empfängern.


    Die Prüfung von Blocklisten ist eine Art erste Instanz zur Blockade von besonders unerwünschten Mail-Versendern und lässt sich bei den meisten Providern nicht individuell konfigurieren (das passiert schon vor dem klassischen Spamfilter).

    Die werden bei Hetz*ner DNS nach Prio sortiert.
    Ich habe es geändert und es wird zurückgeändert:

    Dein DNS-Provider hängt aus irgendeinem Grund die Domain an das Ende des DNS-Eintrag-Ziels. So wie es im Bild ist, sieht es theoretisch gut aus. Wie du verhindern kannst, dass dein Provider hinten nochmal die Domain dran hängt, statt den Record so auszuliefern, wie er im Screenshot dargestellt ist, weiß ich leider nicht, da ich deren Panel nicht kenne. Aber da kann dir sicher jemand anderes hier helfen, den Provider nutzt ja so mancher.



    Am besten setzt du die DNS-Einstellungen der Domain mal auf die Voreinstellungen zurück, nachdem sie dem Webhosting zugewiesen ist.

    Ich glaube hier geht es um eine externe Domain, oder zumindest eine Domain, die externe Nameserver nutzt, daher geht das nicht.

    Nein, denn z.B.

    mxe965.netcup.net.deinedomain.tld

    ist ja was ganz anderes, als nur

    mxe965.netcup.net


    mxe965.netcup.net ist eine von netcup betriebene Domain, mxe965.netcup.net.deinedomain.tld zeigt auf deine eigene Domain. Da greift dann der Wildcard-Eintrag (*) – der zeigt auf deinen Webserver, damit beliebige Subdomains auf diesen verweisen, aber nicht auf den Mailserver, der hat eine eigene IP.


    Gleiches gilt für mail.deinedomain.tld.deinedomain.tld – das ist schon näher dran: Aber es müsste eben nur auf mail.deinedomain.tld zeigen – dafür existiert ein eigener DNS-Eintrag, der auf die IP des Mailservers zeigt.


    EDIT: Und die Priorität spielt in diesem Fall keine Rolle, weil beide Einträge falsch sind und auf den Web-, nicht auf den Mailserver, deines Hostings zeigen. Daher schlägt die Zustellung so oder so fehl.

    Deine MX-DNS-Einträge sind falsch:


    Du hast da

    mail.deinedomain.tld.deinedomain.tld

    und

    mxe965.netcup.net.deinedomain.tld


    Richtig wäre:


    mail.deinedomain.tld

    und

    mxe965.netcup.net


    Danach kann es dann natürlich wegen DNS-Caching wieder etwas dauern, bis es funktioniert.

    Die könnten auch die Mail erstmal fertig entgegennehmen und diese dann prüfen vor dem weiterleiten.

    Dann hätten wir hier (von einem anderen Kunden) dazu eine Beschwerde: "Warum wird die E-Mail nicht direkt abgelehnt?". Man kann es vermutlich nicht jedem recht machen.

    Woher kommt eigentlich die scheinbar als selbstverständlich angenommene Behauptung, dass das eine absichtliche Handlung sei (also die Beschränkung der I/O-Leistung) und nicht nur ein (temporäres) Problem?

    Beim "webmail"-DNS-Eintrag kannst du das Proxying (die Wolke) eigentlich an lassen. Wo du es ausschalten musst, ist beim "mail"-DNS-Eintrag, denn damit verbindet sich der Webmailer via IMAP / SMTP und Cloudflare proxied (jedenfalls in den meisten Tarifen) kein IMAP / SMTP (weswegen es zu dem genannten Fehler kommt). Beim Webmailer selbst hingegen ist es kein Problem, da die Verbindung mit diesem ja via HTTP / HTTPS stattfindet.

    Die DNS-Einträge der Domain werden noch auf das alte Hosting verweisen, wenn du die Domain also aufrufst, landest du auf dem alten (gesperrten) PPA-Hostingtarif. Das ist die Meldung, die erscheint, wenn ein Tarif in PPA deaktiviert ist.


    Beachte hier den dritten Punkt:

    https://helpcenter.netcup.com/de/wiki/webhosting/ppa-abkuendigung/#wie-geht-es-mit-meinen-domains-weiter


    Danach kann es einige Stunden dauern, bis du beim Abruf der Domain auf dem neuen Hostingserver landest.

    Ich sehe den Fehler, weiß aber nicht, wie dieser bei deiner Anwendung zu lösen ist. Dennoch hilft es vielleicht, erst einmal festzustellen, was hier nicht stimmt.


    Deine Anwendung versucht auf /assets/… zuzugreifen. Der Pfad müsste jedoch so beginnen:

    Code
    /var/www/vhosts/hostingxxxxxx.a1234.netcup.net

    wobei „hostingxxxxxx.a1234.netcup.net“ durch die Standarddomain deines Hostings zu ersetzen wäre.


    Bei vielen Webanwendungen kann man diesen Pfad z.B. in einer Konfigurationsdatei definieren.


    Wenn du dich per FTP oder SSH einloggst, dann befindet sich dein Root, also „/”, unter diesem Pfad. Wird jedoch eine PHP-Anwendung vom Webserver ausgeführt, entspricht der Root, also „/”, dem Root vom ganzen Webhostingserver, so dass immer obiger Pfad mit übergeben werden muss.

    Genau, falls es daran nicht liegt, schau mal in /var/log/plesk/panel.log – dort sollte der Fehler auch geloggt werden, inkl. der PHP-Datei, welcher diesen auslöst. Es wird vermutlich irgendeine Extension sein.

    Hi, poste am besten mal die genaue Fehlermeldung von Plesk. Das Plesk Panel nutzt ein eigenes PHP (sw-engine), das kannst du nicht einfach ändern. Aber vielleicht kommen wir mit der genauen Fehlermeldung dem Problem ja auf die Schliche.