Die DNS-Konstruktion mit dem CNAME war in Ordnung. Mach dir keine unnötigen Probleme, besonders nicht wenn andere sie lösen sollen.
Edit: Was verwirrt dich an der Antwort? Ich habe zweimal erklärt, dass der CNAME auf den MyFritz-DynDNS nicht dein Problem ist, aber du baust dir dein DynDNS trotzdem selbst und das liefert dir eine falsche Adresse. Deinem eigentlichen Ziel bringt dich das nicht näher, und das hätte es selbst dann nicht, wenn es funktioniert hätte.
Der DNS-Teil ist nicht das Problem und der Wechsel von CNAME+MyFritz einerseits zur "API-Lösung" andererseits ändert nichts an der Zertifikatssituation. Der Raspberry Pi braucht ein Zertifikat für die Domain, mit der er angesprochen werden soll. Zertifikate werden auf Domainnamen ausgestellt. Die IP-Adresse, und ob der Browser die über einen CNAME und einen A-Record oder direkt über einen A-Record erfährt, spielt für das Zertifikat keine Rolle. Du brauchst einen ACME-Client für den Raspberry Pi und beantragst darüber ein Zertifikat für deine Subdomain und installierst das in dem Server auf dem Raspberry Pi. Weil das Zertifikat spätestens nach drei Monaten erneuert werden muss, sollte der ganze Vorgang automatisch laufen, sonst wirst du die Erneuerung früher oder später vergessen.
Ich verstehe das so, dass nicht die Fritzbox das freigegebene Gerät ist. Wenn das Gerät einen ACME Client hat oder man einen installieren kann, dann wäre das die naheliegendste Möglichkeit. Der Name, auf den das Zertifikat ausgestellt werden muss, ist die Subdomain mit dem CNAME, nicht die MyFritz-Adresse. Der Browser erfährt gar nichts von der MyFritz-Adresse. Er löst die Subdomain auf und bekommt eine IP-Adresse. Deswegen ist es auch praktisch kein Unterschied, ob man das mit CNAME oder direkt per API mit A- oder AAAA-Record macht.
Wenn man es sich einfach machen möchte, kann man die Subdomain mit Zertifikat im Webspace einrichten, um von dort per HTTP-Redirect auf die MyFritz-Adresse weiterzuleiten, oder die MyFritz-Adresse als alleinigen Inhalt eines Frames im Webspace ablegen. Beides setzt aber voraus, dass der Aufruf der MyFritz-Adresse keinen Zertifikatsfehler produziert. Dazu muss das freigegebene Gerät ein Zertifikat z.B. von Letsencrypt für die MyFritz Adresse haben, kein selbstsigniertes. Die Fehlermeldung oben sieht so aus, als wäre das nicht der Fall. Wenn man sich darum noch kümmern muss, kann man es auch gleich mit der richtigen Domain machen.
die Google Captchas sind mir plötzlich neu
Das heißt, dass Google dich unter den anderen Clients in dem Adressbereich nicht wiedererkennen konnte. Wahrscheinlich bist du so ein Cookielöscher. 
Der Apple iOS Mail Client verwendet nicht IMAP-IDLE sondern eine Apple-spezifische Extension, mit der der IMAP-Server den zentralen Apple Push Notification Service nutzen kann, um den Client zu benachrichtigen. Apple macht das, weil IMAP-IDLE ein schlimmes Protokoll ist und die iPhones nicht mit den vielen langlebigen TCP-Connections belastet werden sollen. Stattdessen soll eben nur die eine Push-Verbindung mit der iCloud bestehen und alles andere nur bei Bedarf passieren. Die Apple-spezifische Push Technik muss der Server untersützen, damit das funktioniert. Alternative Clients umgehen diese Voraussetzung teilweise, indem sie Server einsetzen, die im Auftrag des Clients IMAP-IDLE mit dem IMAP-Server machen und dann die Push-Notification in Richtung Client absetzen.
Hab Integrale komplett vergessen...
Macht nichts. Das Integral ist fast nur zur Verwirrung. Man muss kaum rechnen. Erklärung: Du kannst das aufteilen in eine Summe aus x³cos(x/2) mal die Wurzel und 1/2 mal die Wurzel. Die Wurzel ist spiegelsymmetrisch um die y-Achse. x³cos(x/2) ist punktsymmetrisch um den Nullpunkt, das heißt, dass sich die erste Hälfte des Integrals im Bereich von -2 bis 0 und im Bereich von 0 bis 2 aufhebt, also gleich 0 ist. Bleibt nur das Integral von 1/2*Wurzel. Die Wurzel beschreibt einen Halbkreis mit dem Radius 2. Das Integral ist also die Hälfte der Hälfte der Fläche eines solchen Kreises. Die Kreisfläche ist Pi mal Radius zum Quadrat. Also ist das Ergebnis 1/2*1/2*Pi*4=Pi. Schönes Restwochenende.
"the first digits". Ja, aber wie viele davon?
8-64
Ob ein Webhostingpaket reicht, hängt von der Ursache des Fehlers ab. Die Fehlermeldung kommt vom Reverse Proxy Nginx, der fehlerhafte/zu große Header vom Webserver bekommt. Es kann sein, dass man das mit größeren Puffern lösen kann. Dafür bräuchtest du in der Tat einen eigenen Server, weil diese Einstellung nicht individuell konfigurierbar ist. Die Fehlermeldung kann auch von einem Fehler im Bereich des Webservers ausgelöst werden, und der Fehler in dem Bereich kann bei einem größeren Webhostingpaket oder einem eigenen Server mit mehr Ressourcen verschwinden oder nicht. Was du brauchst kommt darauf an, was dort schiefgeht. Wenn du dir sicher bist, dass es kein Fehler an sich ist sondern nur zu große Cookies, dann hilft nur ein Server.
so long as the email boxes and storage allocation are not exceeded
That's the limit, but note that there is also a rather low limit how many emails you can send per hour, so using a web hosting account for too many email accounts may not be a good idea after all.
Sie kommen nicht wieder sondern sind einfach dageblieben. Es stört mich nicht so sehr, dass ich Handlungsbedarf sehe. War nur eine Antwort auf die Frage, ob palminator93 mit dem Problem alleine ist.
Das "Problem" mit Resten von ehemaligen Domains in diversen Teilen der Konfigurationsmenüs habe ich auch. Es handelt sich um zwischenzeitlich aufgeschaltete Zusatzdomains (bei Netcup bestellte zusätzlich bezahlte Domains, nicht inklusive, nicht extern), die es nicht mehr gibt.
Grundsätzlich können sie das – oder besser gesagt ein Nutzer, welcher dort eindringt oder das Gerät dazu bringt, Befehle für ihn auszuführen – aber, selbst ohne Root-Rechte. Wie einfach das ist, wenn nur Zugriff auf eine Shell besteht, zeigt etwa dieses Script: How to send e-mail from bash. Das geht auch problemlos am eigenen Mail-Gateway vorbei
Mir ist bewusst, dass SMTP keine Accounts voraussetzt. Das hatte ich auch schon in Kommentar #3 erwähnt. Aber erstens ist es schwer, von der Position der IoT Geräte im Netz unangemeldet irgendeine Email erfolgreich auszuliefern. Zweitens ist das dann kein Problem für die Reputation des Mailservers, was es zu keinem Problem für Netcup macht, und das macht es zu einem wesentlich kleineren Problem für mich. Drittens, nicht ganz unwichtig, können die Geräte im Normalfall Mail nicht ohne Smarthost verschicken. Das heißt, wenn ich von denen Mail bekommen möchte, dann muss ich ihnen einen SMTP-Account geben, und da würde ich gerne einen nehmen, mit dem man nicht unangenehm auffallen kann.
Alles, was es dafür bräuchte, wäre ein Häkchen im Bereich Ausgangskontrolle "Mails an die eigene Adresse für die Ausgangskontrolle nicht als ausgehende Mail zählen" und die entsprechende Funktionalität.
Du lässt ja auch nicht alle Programme als root laufen, obwohl die das, was über die Rechte eines normalen Users hinausgeht, einfach sein lassen könnten. Meine Fritzbox, Wetterstation, Webcam, Waschmaschine, Staubsauber, Kühlschrank, UPS, Kontaktformular, etc. müssen halt nicht Mail an irgendjemanden als an mich schicken können. Also warum soll ich ihnen mehr Rechte geben als nötig, die im Fall, dass die Geräte/Programme nicht so sicher wie gedacht sind, missbraucht werden können? Einen Mailaccount, der nur an sich selbst Mail verschicken kann, könnte ich z.B. bedenkenlos auch da eintragen, wo ich nicht der einzige mit Zugang zur Konfiguration bin.
Man könnte das Feature m.M.n. relativ einfach implementieren, indem man den SMTP Server so konfiguriert, dass die Postausgangskontrolle nicht auf Emails angewendet wird, die ausschließlich an die eigene Adresse* verschickt werden. Dann könnte ich als Nutzer die maximale Anzahl ausgehender Emails pro Stunde auf 0 stellen und bekäme damit (fast) das, was ich mir wünsche. Fast, weil das Ausgangslimit auch Weiterleitungen betrifft, und selektiv per Filter weiterleiten wäre schon praktisch.
*) Die Adresse, mit der man sich am Server angemeldet hat. Das kann auch ein Alias sein.
So mache ich das bisher. Mit den Zugangsdaten der zusätzlichen Adresse kann das Gerät aber prinzipiell an beliebige Empfänger Emails verschicken, nicht nur an mich. Wenn diese Zugangsdaten in die falschen Hände geraten, wird mein Account dadurch möglicherweise zur Spamschleuder, was ich natürlich nicht möchte. Bisher kann ich den Versand nur mengenmäßig einschränken, aber ein ausgehender Filter oder eine Einschränkung auf bestimmte Empfängeradressen sind nicht möglich.
Was ich möchte, ist im Grunde kein Email-Versand, sondern Email-Annahme mit Zugangsdaten. Eigentlich könnte das Gerät die Mail einfach unauthentifiziert einliefern, aber dabei muss man unausweichlich mit allen Problemen rechnen, die man auch sonst hat, wenn man Emails so von dynamischen Adressen und ohne besondere Konfiguration (Reverse-DNS, etc.) beim Empfänger abliefert. Das wird regelmäßig schon im SMTP-Dialog abgewiesen. Davon abgesehen erwarten die Geräte, die Emails versenden wollen, Zugangsdaten für einen Smarthost und liefern aus genannten Gründen nicht direkt an den MX der Empfängeradresse.
Ich stehe gerade wieder davor, einem Gerät eine "Email-Adresse" zu geben, damit es seinen Status mitteilen kann. Dafür will das Gerät einen SMTP-Account haben. Es wäre schön, wenn ich dem Gerät (und allen, die die Accountdaten darüber ergaunern) damit nicht automatisch die Möglichkeit geben müsste, beliebige Empfänger zu behelligen. Wenn man zu den Email-Adressen bei Netcup SMTP-Logins generieren könnte, die nur Mail an diese/eine bestimmte eigene Adresse schicken können, wäre das sehr beruhigend.
Dann sollte statt
trim(shell_exec("openssl rand -base64 48"));dieses gehen
trim(base64_encode(shell_exec("head -c 48 /dev/urandom")));Du kannst den openssl Befehl, der nicht installiert oder nicht im Pfad ist, durch andere Zufallszahlenquellen ersetzen. Kommt drauf an, welche Befehle vorhanden sind:
Die Ausgabe von
openssl rand -base64 48sind 48 zufällige Bytes, die base64-kodiert einen 64 Zeichen langen zufälligen String ergeben. Den erzeugt man auch mit
head -c 48 /dev/urandom | base64oder mit
dd if=/dev/urandom bs=48 count=1 status=none | basenc --base64Probiere es mal ernsthaft aus auch nur eine komplizierte Zeichenkette per Guacamole auf den Netcup Server zu bekommen.
Ok, vielleicht lernst du heute noch was: pastebin.com und wget/curl existieren. Man muss den Key nicht auf den Server schieben. Wenn man Console Access hat, kann man sich den auch von irgendwo runterladen. Das ist ein öffentlicher Schlüssel. (Darfst den aber auch passwortgeschützt auf deinem eigenen Webspace ablegen, wenn dir Pastebin zu öffentlich ist.)
Musst ihm ja nicht weiter helfen.
Ich fand den "hast du genug Ahnung für einen VPS" Kommentar überflüssig, aber seine Reaktion darauf war für mich trotzdem das Ende meiner Hilfsbereitschaft.
