Ok, vielleicht nicht gebeten, aber es gab keinen Wider-, sondern Zuspruch:
QuoteThis SBL listing has been set up in agreement with the Internet provider responsible for this IP range
Ok, vielleicht nicht gebeten, aber es gab keinen Wider-, sondern Zuspruch:
QuoteThis 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):
QuoteDisplay Moremout-xforward.gmx.net
If your email was blocked by this SBL, please do not contact Spamhaus; we cannot help you. Contact GMX directly, as described below.
If you have been referred to this page it will be due to one of the following reasons:
A) The email message(s) you are sending has been erroneously classified as spam by GMX. As a result your email was delivered by GMX mail systems that exclusively delivers emails that have been internally classified by GMX as spam.
In this case please contact GMX directly using the following link to resolve the issue:
https://postmaster.gmx.net/en/case?c=uar
B) You found non-delivery reports (NDR)/ "bounces" in your mailbox for messages other than your own. This indicates that a third party has sent these emails through your mailbox without your consent. Please take the following steps to re-establish the security of your GMX mailbox:
i) Check your computer for viruses:
Perform a thorough anti-virus scan on all computers which have been used to access the mailbox.
ii) Choose a new password for the affected mailbox.
Again, please DO NOT contact Spamhaus regarding this SBL listing - you will not receive an answer and this listing will not be removed. Your only resolution path is through GMX, as indicated above. Thank you.
Removal Procedure
This SBL listing has been set up in agreement with the Internet provider responsible for this IP range, and it will not be removed. If you are inconvenienced by this listing, please carefully read the explanation and instructions above.
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).
Bei den beiden MX-Einträgen schreibst du z.B. statt "mxe965.netcup.net" -> "mxe965.netcup.net."
Man beachte den Punkt am Ende.
finnvweiss Ich habe es gerade gegooglet: Hänge mal einen Punkt hinten ans Ziel. Das sollte das Verhalten lösen.
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?
Probier mal den Check mit https://whatsmychaincert.com/ das hilft meist gut.
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.
There are two speed test servers you can also ping:
There is https://lg.netcup.net/ as well (but it is Nuremberg, Germany only).
Hab mal ein bisschen im JS-Code geschaut, hier kommt das her:
https://wordpress.github.io/wordpress-playground/architecture/host-your-own-playground
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:
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:
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.
Lösche das Verzeichnis mit den falschen Berechtigungen und lasse dieses dadurch anlegen, dass du im CCP den Dokumentenstamm einer Domain auf den gewünschten Pfad zeigen lässt (ohne dass dieser bereits existiert). Wird das Verzeichnis über diesen Weg neu angelegt, erhält es die korrekten Rechte.
Bei diesen genannten DDNS Client benötige ich einen WebServer mit PHP. (https://github.com/stecklars/dynamic-dns-netcup-api)
Das Skript benötigt keinen Webserver, sondern lediglich PHP-CLI, die Kommandozeilenversion von PHP, die sich einzeln installieren lässt (und auch nur in dem Moment Ressourcen verbraucht, in dem das Skript gerade läuft).
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.