Beiträge von Copro

Ich habe dasselbe Problem nach der Installation von Wordpress 5.7.1 auf einer neuen Domain in einem Webhosting 8000. Dort wird aktuell ebenfalls kein CSS geladen und beim direkten Aufruf von /wp-includes/css/dist/block-library/style.min.css antwortet der nginx mit einem 404 not found. Das Deaktivieren des nginx habe ich bis jetzt nicht abgewartet und warte einfach auch mal bis morgen

Nachdem alle anderen Probleme beseitigt wurden, bleibt eine Unschönheit im WCP die ich auf die schnelle mit der Forensuche nicht gefunden habe.

Die erste Wordpress Installation wird doppelt angezeigt. Ich habe diese auch zu Beginn einmal testweise gelöscht und erneut installiert weil ich dachte das kann nicht stimmen.

Der doppelte Eintrag blieb ... für alle neuen Installationen wird korrekt nur noch ein Eintrag angelegt.

Auf der Übersicht im WCP kann man das am einfachsten sehen im WCP unter "Anwendungen - Meine Anwendungen verwalten": (hier mit meinem Host a2e5e)
https://a2e5e.webhosting.systems/smb/app/installed

2020-06-06_WCP_Anwendungen_doppelter_Eintrag.png
Da ich mich schon daran gewöhnt habe ich das nur eine Unschönheit ist - vielleicht mag das jemand in seinem WH8000 ebenfalls mal aufrufen und bestätigen.

Nachtrag, da ich den letzten Beitrag nicht mehr editieren kann.

Mit dem Zurücksetzen der DNS Einstellungen per:

Standard DNS Einstellungen setzen für hosting [x]

verschwand der webmail A Record und dafür habe ich jetzt auch einen gültigen TXT Record für SPF

v=spf1 mx a include:_spf.webhosting.systems ~all

Woher diese ursprüngliche Konfiguration stammte bzw. durch was die ausgelöst wurde, kann ich nicht sagen.

Zitat von aRaphael

Für spf gilt im übrigen das gleiche wie für dkim

Beides ist in der Regel bei den Webhostings schon drin

Die netcup @ TXT Records für spf sehen so aus:.

Code

v=spf1 mx a include:_spf.webhosting.systems ~all

Das einzige, was man also noch selbst hinzufügen muss ist ein dmarc.

Der minimale (und in der Regel ausreichende) sieht so aus:

Code

v=DMARC1;p=none;sp=none

(_dmarc TXT)

Alles anzeigen

Interessanterweise war das bei mir nicht der Fall ... nach dem Zurücksetzen auf die Standardwerte für das Hosting mit:

Standard DNS Einstellungen setzen für hosting [x]

sind jetzt aber wie beschrieben auch die TXT Records für SPF da und ich musste nur noch den DMARC TXT Rekord ergänzen.

Vielen Dank für den nützlichen Hinweis
Auch der dubiose A Record für webmail auf den MX kam nach dem Zurücksetzen nicht mehr wieder: DNS A Eintrag für webmail in Webhosting Paket steht auf der IP des MX statt auf webmail Host

Ich habe den Eintrag in meiner DNS Konfiguration jetzt entfernt, da er für mich immer noch keinen Sinn ergibt.

Stattdessen habe ich - wo benötigt - eine eigene Subdomain eingerichtet mit Let’s Encrypt SSL Zertifkat und einem Webmailer wie Roundcube den auch Netcup einsetzt.

Ein anderer Benutzer hier aus dem Forum empfiehlt auch RainLoop Webmail und es gäbe auch noch SquirrelMail - Webmail for Nuts!, das sich aber mit der aktuellen PHP Konfiguration nicht direkt per Wizard installieren lassen wollte.

Achwo ... ein TXT Record hat noch nie irgendwas explodieren lassen... im schlechtesten Fall werden die E-Mails immer noch als Spam eingestuft.

Fangen wir doch mit dem SPF Record an - im CCP unter Domains: https://www.customercontrolpanel.de/domains.php

Da erzeugst Du für Deine Webhosting Domain einen neuen TXT Eintrag im Reiter "DNS":

Host: @

Type: TXT

Destination: : "v=spf1 mx a a:relay.yourmailgateway.de -all"

Dann klopfst Du unten auf den grauen Button [DNS Records speichern]

Den Eintrag Destination kannst Du natürlich selbst anpassen und dafür z.B. einen Generator oder Wizard wie spfwizard.net verwenden.

Der Vorschlag oben erlaubt Mails vom MX Eintrag Deiner Domain, dem A Record Deiner Domain (ich vermute auch Skripte auf dem Webhost MTA könnten versenden) und den zig IPs des Mail-Relays relay.yourmailgateway.de dürfen Mails senden. Das -all am Ende gibt den Härtegrad der Regel an was in diesem Fall einem harten FAIL also einer Abweisung der Mail entspricht, die nicht der Regeln entsprechen. ~all für SoftFail also vermutlich einer Annahme aber Markierung der Mail und ?all für NEUTRAL also einer Annahme auch bei Verletzung der Regel.

DKIM war bei mir schon hinterlegt ... zumindest habe ich schon folgende Einträge:
key1._domainkey CNAME key1._domainkey.webhosting.systems

key2._domainkey CNAME key2._domainkey.webhosting.systems

und DMARC kommt auch noch dran ...

Ich habe gestern auch schon die SPF Einträge für die meine Domains im WH8000 SE Paket erstellt und bin heute ebenfalls auf die Schnauze geflogen als ich einem Bekannten stolz meine neue E-Mail-Adresse vorführen wollte. Den SPF Record habe ich im CCP unter DNS vorgenommen:

Host @ und TXT Eintrag v=spf1 ?a +mx +a:forward-relay.netcup.net -all

Meine E-Mail wurde von einem IONOS Mailserver ebenfalls als Spam aussortiert - und diese wurde seitens Netcup von relay.yourmailgateway.de ([194.59.206.189]) ausgeliefert.

Da der IONOS Spamfilter im Header nicht wirklich gesprächig war warum der hohe Spamwert zustande kam, muss ich heute abend mit anderes Dienste erst noch prüfen, um genauer zu analysieren woran das liegen könnte.

Die Problematik warum das MailGateway öfters mal auf RBLs auftaucht ist hier gut erklärt: Webhosting akzeptiert beliebigen Absender
Aktueller Stand der RBLs für die eine IP die in meinem Fall ausgeliefert hat: http://multirbl.valli.org/lookup/194.59.206.189.html

SPF scheint schon zu passen:
Received-SPF: pass (mx2e60: connection is authenticated)

DMARC muss ich mir noch ansehen ... das letzte Mal als ich mit Mailservern bastelte gab es das noch nicht

Super - nach Rückmeldung vom Support heute morgen funktioniert jetzt auch die Auslieferung aus dem korrekten Unterverzeichnis. Auch das Problem mit mit den Let'sEncrpyt Zertifikaten ist bereinigt. (LE SSL Zertifikat im WCP ausgewählt - Wird aber nicht ausgeliefert)

Ich werde aber trotzdem wie hier beschrieben DocumentRoot für unterschiedliche Domains die Ordnerstruktur in /www/domain/ ändern, damit bei neuen Domains dann immer die Baustellenseite aus dem Standardordner /httpdocs serviert wird und nicht eine bestehende Webseite stattdessen angezeigt wird und auf keine Fall ein Zugriff auf die dann theoretisch erreichbaren Unterordner erfolgt.

Super - nach Rückmeldung vom Support heute morgen funktioniert es jetzt und alle Domains haben ein LE Zertifikat. Auch das Problem mit der Auslieferung der Dateien aus dem falschen Ordner in httpdocs ist bereinigt. Ich freue mich schon mal - auch wenn ich gerne auch technisch gewusst hätte woran es scheitert

Muss trotzdem noch auf ein paar Knöpfe drücken und die Option wieder aktivieren

[x] Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS

Stimmt - SSL ginge dann nicht. Und wer würde schon sein Passwort unverschlüsselt über die Leitung jagen

Aber der Eintrag selbst erklärt sich damit immer noch nicht.

Kündigen hilft erstmal nichts ... weil die Domains ja irgendwie trotzdem versorgt werden müssen.

Das kann ja nicht so schwierig sein das Problem zu analysieren, da es sich ja mit frischen Domains einwandfrei reproduzieren lässt.

Und es scheint ja nicht bei allen Webhosting Paketen aufzutreten, sondern speziell WH8000 und seit kurzer Zeit verstärkt - was ja auch auf ein rate limit Problem hindeutet.

Ich habe die Tipps auch ausprobiert und konnte noch keine Besserung feststellen. Um das Zertifikat zu löschen, hat es auch nicht ausgereicht den SSL Support zu deaktivieren - ich musste zuvor eine andere Auswahl in der Zertifikat Dropbox vornehmen. Zuvor bekam ich immer die Meldung das Zertifikat würde noch verwendet.

Aufgrund der Problematik mit den verkonfigurierten httpdocs Verzeichnissen am nginx für das Basisverzeichnis kann da aber mehr im Argen sein.

Habe exakt dasselbe Problem und auch gestern schon ein Ticket eröffnet ... mal sehen was sich da tut.

Ich hatte die Vermutung, dass es sich aufgrund der SSL / Let'sEncrypt entstanden sein könnte.

Das LE Zertifikatsproblem erledigt sich zumindest nach einiger Zeit von selbst so wie es aussieht:

https://forum.netcup.de/anwendung/ccp-…t-ausgeliefert/

Der DNS A Eintrag für "webmail" in der DNS Konfiguration meiner Domains im Webhosting Paket 8000 SE steht auf der IP des MX statt auf dem webmail Host.

Der zugewiesene MX ist der mx2e60.netcup.net mit IP 91.204.46.96

Der zugewiesene Webmail Host ist webmail01.netcup.net mit IP 46.38.249.153

Macht das Sinn auch den webmail auf den MX zeigen zu lassen, denn dort kommt keine Verbindung auf Port 80 oder 443 zustande?

Sinnvollerweise sollte dort eigentlich die zugewiesene IP des Webmail Host eingetragen werden, damit man mit webmail.meinenetcupdomain.de dann auch die Webmail Oberfläche (Roundcube) zu sehen bekommt.

Evtl. hat das in der Vergangenheit ja Sinn gemacht, wenn der MX auch gleichzeitig das Webmail Frontend bereit gestellt hat ...

Da die Domains noch nicht richtig konfiguriert sind und immer noch das Let'sEncrypt Zertifikat fehlt, habe ich mich etwas mit dem Mailsetup befasst und das war das erste was mir aufgefallen ist.

Ich habe dasselbe Problem bei allen Domains aus dem Webhosting 8000 aus der Osteraktion. Es wird kein Let'sEncrypt Zertifikat ausgestellt und die 24 Stunden Wartezeit. Es waren 3 neue Domains und eine die erst frisch transferiert wurde. Bei allen nach wie vor das selbst signierte Plesk Zertifikat.

Gleichzeitig fällt mir auf, dass auch die Webhosting-Einstellungen zum Ändern des DocumentRoot Webverzeichnisses nicht sofort oder mit wenigen Minuten Wartezeit aktiv werden. Auch hier habe ich schon probiert das nginx Caching und alles was damit zusammenhängt testweise abzuschalten.

Werde also die letzte Domäne noch richtig konfigurieren und dann auch mal den Support anschreiben.

Den Punkt Konto mit einer extra Let'sEncrypt Einstellung sehe ich nicht.

Aufgrund der Hilfestellungen bin ich auch hier gelandet. Allerdings habe ich einige interessante Eier auch vorher selbst gefunden. Es war trotzdem nett zu sehen wie viele sich die Mühe gemacht haben den Rhythmus der Änderungen herauszufinden, bevor jemand einfach die API angezapft hat.