AWS SES finde ich jetzt auch nicht so teuer. Hab's selber aber noch nicht ausprobiert. Verand über SMTP soll da auch funktionieren.
Mein ISP erlaubt den Verand von 1000 Mails/Stunde über deren Relay-Server. Das reicht mir aktuell für meine privaten Mails... 
Wir versuchen nur den oder die möglichen Fehler zu finden.
In dem Fall ist netcup aber der falsche Ansatz für die Fehlersuche.
Habt ihr mal in die Header der Mails geguckt, die im Spam gelandet sind? Da wird doch häufig der Grund für die Spam-Einstufung reingeschrieben.
Oder verwendet ihr neumodische TLDs? Die werden generell schlechter bewertet. Ich sehe das bei einem Bekannten sehr häufig, der eine .online-Domain verwendet.
Vor allem, da dieser Kunde seine Mails via GSuite versendet und bei uns nur die Domain hat, welche wir von netcup haben.
Was hat dann netcup damit zu tun, wenn GSuite die Mails versendet? Wo die Domain registriert wurde ist doch beim Mailversand völlig egal.
Hast du zufällig einen Link zu einem Beitrag mit UCEPROTECT?
Das ist meines Wissens nach der Längste Thread zu diesem Thema: https://forum.netcup.de/netcup-intern/…evel3-gelistet/
Ansonsten einfach mal „UCEPROTECT“ in die Suche eintippen.
Was sagen denn so Seiten wie https://www.mail-tester.com oder https://mecsa.jrc.ec.europa.eu/de/?
Zu UCEPROTECT solltest du einige Posts hier im Forum finden. Da ist eigentlich alles gesagt.
Auf Windows haben wir restic versucht, was dann aber doch nicht ganz überzeugt hat (einige Files konnten nicht gebackupt werden und das eine oder andere mal hat sich der Backup-Job aufgehängt).
Verwende restic und das klappt wunderbar.
Was für Dateien konnte denn nicht gebackupt werden?
Der Support hat mir jetzt gesagt wie ich zu den Logdateien komme.
Was hat er denn genau gesagt?
Dass wir von den PHP-Error-Logs sprechen wäre eine gute Info ganz zu Anfang gewesen.
Ein kurzer Test mit
<?php
throw new Exception('Das ist ein Fehler');lässt folgendes in die Datei logs/[domain]/error_log schreiben:
[Wed Jan 24 16:40:54.095854 2024] [fcgid:warn] [pid 2115] [client XXX.XXX.XXX.XXX:0] mod_fcgid: stderr: PHP Fatal error: Uncaught Exception: Das ist ein Fehler in /var/www/vhosts/hostingXXXXXX.aXXXX.netcup.net/httpdocs/[domain]/test.php:3
[Wed Jan 24 16:40:54.095890 2024] [fcgid:warn] [pid 2115] [client XXX.XXX.XXX.XXX:0] mod_fcgid: stderr: Stack trace:
[Wed Jan 24 16:40:54.095893 2024] [fcgid:warn] [pid 2115] [client XXX.XXX.XXX.XXX:0] mod_fcgid: stderr: #0 {main}
[Wed Jan 24 16:40:54.095896 2024] [fcgid:warn] [pid 2115] [client XXX.XXX.XXX.XXX:0] mod_fcgid: stderr: thrown in /var/www/vhosts/hostingXXXXXX.aXXXX.netcup.net/httpdocs/[domain]/test.php on line 3Versuchen wir es mal anders herum. Poste doch mal einen Screenshot wie es stattdessen bei dir aussieht.
Gibt noch andere Wege, aber das ist vermutlich der Schnellste.
Mein Weg war auf "Auto-Login WEB" zu klicken, auf die gewünschte Domain und dort gibt es dann "Logs".
Das ist wohl wahr, nicht aufgepasst. Eine Rubrik Webhosting sehe ich aber auch nicht.
WCP (Webhosting Control Panel) - netcup Kundenforum
Also bei mir gibt's einen Button mit Logs. Sieht das bei dir etwa anders aus?
Das SSL-Zertifikat ist beim anderen Anbieter eingerichtet und aktiv, aber auf der Domain, auf die weitergeleitet wird, ist das Zertifikat ja nicht vorhanden.
Das ganze läuft so ab:
Du rufst https://example.com auf. Dein Browser baut eine sichere Verbindung mit dem Webserver von example.com auf. Dafür benötigt der Webserver ein Zertifikat für example.com. Anschließend gibt der Webserver mit dem Statuscode 302 an, dass jetzt https://example.net aufgerufen werden soll. Also baut dein Browser eine neue Verbindung zum Webserver von example.net auf und das ganze Spiel geht von vorne los. Von wo du kommst, spielt absolut keine Rolle beim Aufruf von https://example.net.
Sonst müssten Seiten wie https://bitly.com/ ja für jede Domain, auf die sie weiterleiten möchten, ein Zertifikat haben. Das ginge gar nicht.
Oder ist dein Ziel, dass oben in der Adresszeile vom Browser die ursrüngliche Domain stehen bleibt?
EDIT:
Siehe das Ergebnis: https://www.ssllabs.com/ssltest/analyz…&hideResults=on
Failed to communicate with the secure server
Das hat nichts mit netcup zu tun. Dafür musst du den blauen Anbieter konaktieren und fragen, wie das genau geht.
Kannst du in den Headern der Mail vielleicht die Gründe für die Spam-Kennzeichnung rauslesen?
Alternativ kannst du dir auch eine eigene Roundcube-Instanz auf deinem Webhosting installieren. Allerdings musst dann vermutlich auf so Sachen wie das Administrieren der Sieve-Filter verzichten.
Am besten konfigurierst du die IPv4 auch statisch
Macht es eigentlich Sinn für Teamspeak auch einen AAAA-Record anzulegen ?
IPv6 ist die Zukunft und daher immer sinnvoll. 
Ich könnte mir vorstellen, dass der TS-Client erstmal nach einem SRV-Record guckt und erst danach nach einem A-Record. Vielleicht sorgt das für die Verzögerung.
Oder ist da zufällig noch ein AAAA-Record auf der Domain aktiv? Und dann wird erst ein Timeout abgewartet und dann die IPv4 als Fallback verwendet?
Diese beiden Optionen dauern mit Sicherheit unterschiedlich lange, wenn das Ticket zunächst an die entsprechende Stelle weitergeleitet werden muss …
Das stimmt. Hatte nur gehofft, dass der Support das vielleicht hinbekommt, bis ich Feierabend habe. Bisher wurde das Ticket aber nur an die zuständige Abteilung weitergeleitet. Glaube auch kaum, dass da heute noch was passiert.
Habe jetzt Feierabend und installiere gerade alles neu. Bin gerade mega gefrustet deswegen. Nicht mal zwei Wochen zwischen den beiden Ausfällen.
EDIT: Support hat geantwortet und mir wurde versichert, dass der Fehler auf dem Node jetzt nachhaltig gelöst wurde. Immerhin. Und ich bin nach wie vor vom Backup von OPNsense begeistert. Aber hoffentlich brauche ich das jetzt nicht wieder so schnell.
So langsam beruhigt sich mein Puls auch wieder... 
Beim Ausfall am 6. Januar konnte ich zumindest schon mal das OPNsense-Logo sehen. Auch die verschiedenen Boot-Optionen wurden mir angezeigt. Aber ich konnte keine Auswahl treffen.
Jetzt habe ich das Gefühl, dass die virtuelle Festplatte nicht mehr lesbar ist. Bin aber auch gerade noch auf der Arbeit und kann nur sporadisch reingucken. Am schnellsten wäre es vermutlich einfach wieder OPNsense zu installieren und das Backup einzuspielen. Oder der Support sorgt irgendwie dafür, dass die Festplatte wieder gelesen werden kann.
Genauere Recherchen sorgen nur für eine längere Downtime, vermute ich.
Server wollte nicht mehr booten. Keine Ahnung was genau der Grund war, aber jetzt kann ich mit Sicherheit sagen, dass Backups bei OPNsense echt klasse funktionieren. Drei Klicks und alles lief wieder.
Schon wieder ein Ausfall. Und wieder startet der Server nicht mehr. So langsam macht's keinen Spaß mehr.
Bildschirmfoto 2024-01-19 um 13.06.25.png
Oder hat hier jemand ne Idee bevor ich den Server wieder neu aufsetze?
