Beiträge von Alex07

    das liegt an PHP. Es ist nur eine Warnung, die spuckt er natürlich aus. Dein PHP ist neuer als "erlaubt" und er sagt das es mit neueren PHP Versionen eben nicht mehr funktioniert.

    Wegen der IPv6, die ist in deinem DNS eingetragen, also die vom Server. Die sagt dann Hallo, wenn deine Seite angefordert wird. Auch kann jetzt per IPv6 sozusagen "angefordert" werden.

    Die Zukunft wird so aussehen, das einige ganz auf IPv6 umswitchen werden und IPv4 gar nicht erst mehr anbieten. Die IP Adressen aus dem V4 Bereich sind auch richtig teuer geworden, da wird sich in der Zukunft das für die Provider nicht mehr lohnen. ( Meine Meinung ) Ich würde gerne auch lieber auf IPv4 verzichten, das ist aber unmöglich und da habe ich eben auch 2 für GLUE Records.

    Hi Catcat,

    IPv6 hast du bei allen deinen Domains freigeschaltet. Es macht auch Sinn, denn die IPv4 sind begrenzt. Ich habe zB 2 IPv4 die selber auflösen, allerdings ist IPv6 die Zukunft. Also alle deine Domains sind auch per IPv6 erreichbar.

    Das ist übrigens neu. Vorher war das nicht. Auch DNS läuft auf v4 UND v6. Deine Domains ebenfalls.

    Problem in der Zukunft wäre, dass deine Webseite sonst nicht aufgelöst werden KÖNNTE. Deswegen das +V6.

    kombiniertes mit "webmail" und "www". Die gehen auch. Unterschied hier halt nur, auch die haben alle keine Weiterleitung

    Das ist extra so. Ich schrieb ja schon das es das Default Zertifikat ist. Im Skeleton ist es noch nicht. Muss ich erst überlegen ob das Sinn macht.

    Es ist Default für eigentlich alles, was nicht ausgeliefert werden kann. Demzufolge ist auch ein canonical drin.

    Plesk ist eigentlich ausgezeichnet, es gibt nichts Besseres. Aber halt doof, wenn man Umwege gehen muss.

    Oder blockiert Plesk da komplett? Wenn ja, warum?

    Ich hatte es gestern probiert und bin gescheitert. Es liegt nicht an Certbot, bei Plesk musst du verstehen, alles was nicht über Plesk läuft, kann zu Fehlern führen. Dann auch der Certbot. Ist leider so, es arbeitet mit der internen Plesk DB. Beim nächsten safe Update wäre es dann wieder raus. Deswegen muss es über Plesk laufen.

    Ich hatte gestern auch schon da Limit ausgereizt von Lets Encrypt. Meinst du es hat funktioniert bei dem Host? Nee, eben nicht. Dann ist es besser das so zu lösen. Da wird es auch in Plesk hinterlegt.

    Sollte jetzt funktionieren. Das Problem ist der Hostname. Dafür geht kein Lets Encrypt. Habe mir nun eins gekauft und als Standardzertifikat eingesetzt.

    Das ist nun ein Trick mit Plesk, denn anlegen kann ich die Domain trotzdem nicht :( , somit auch bei Plesk kein valides SSL.

    Ich habe nun das als Standard, Plesk Zertifikat habe ich entfernt. Ist also eine Lösung, um auch den Hostnamen mit SSL abzusichern. Muss jetzt noch ein paar Sachen anpassen....

    Nein. Gestern habe ich das versucht mit Lets Encrypt und Plesk. Das hat aber leider nicht geklappt. So habe ich das entfernt und wird auch jetzt korrekt umgeleitet auf ohne SSL.

    Ich habe keine Ahnung warum das nicht geklappt hatte. Aber ich war dann pragmatisch und habe SSL da komplett entfernt und wie gesagt sollte der auch auf ohne umleiten.

    :)

    SSL wäre natürlich besser, aber nu ist es so ohne.

    Ich bin auch weiter...

    Das wusste ich auch noch nicht.

    Aus dem Hostnamen (FQDN) zur IP-Adresse des anliefernden Systems muss für Betroffene die Domain und entsprechend die Website des Betreibers mit unmittelbarer Kontaktmöglichkeit einfach recherchierbar und nachvollziehbar hervorgehen (RFC 1912, FCrDNS, EU-Richtlinie 2000/31/EG Artikel 5).

    Also Onkel Alex hat noch was zu tun.

    Voraussetzung ist, dass der FQDN tatsächlich mit ALLEN IPs, also bei mir sind es 4, hin und zurück auch auflöst. Es reicht also nicht einfach ein revers Eintrag einer IPv6, ne umgekehrt MUSS es auch passen. Da hatte ich tatsächlich IPv6 bei einer nicht Vorwärts aufgelöst, Rückwärts schon.

    Bitte auch darauf achten!

    Dann der Hostname, er muss erreichbar und Daten zur Kontaktaufnahme enthalten. Also quasi ne kleine Webseite, nur für den Hostnamen mit Beschreibung, Kontakt und ich werde da auch Abuse Mail des Hostnamens hinterlegen. ( Das muss mit der FQDN übereinstimmen, in meinem Fall wäre es abuse@host.***.de oder abuse@****.de

    postmaster geht auch, andere EMail Addis sind NICHT zulässig. Also alex@fgdn** nicht und auch nicht abuse@seo-nw.de

    Wieder was gelernt.

    DMARC -> Du hast den Wink nicht verstanden. Du redest oben nämlich überall von DMARK.

    Nee schon verstanden.

    Wegen Marke, das ist das einzige was fehlen würde. Es ist aber valide und das SVG musste in einem speziellen Format vorliegen. Auch funktionieren die Reports. Also es funktioniert schonmal. Ich meine auch das es etwas bringt für Mailtrust, deswegen habe ich es drin. War etwas kompliziert umzusetzen.

    Soll ich das editieren? Ist vielleicht besser....

    DMARC, also DMARC

    Hoppla :D

    Klar, umgangssprachlich meinte ich das über PHP. Mit PHP(Mail) geht es nicht, wenn das nicht über den SMTP Log-in/Auth geht, meine ich. Es sollte schon da über SMTP gesendet werden, sonst passt es net.

    Aber gut, ich finde das Thema auch grade mega spannend. BIMI war ehrlich gesagt auch neu für mich. Es funktioniert, bin da aber sozusagen noch im Debug Modus.

    Durch den Serverwechsel musste ich auch Hotmail bzw M$ anschreiben. Da ist die Reputation erstmal ausreichend. Mails kommen dahin an. T-Offline habe ich auch angeschrieben, sowie andere Provider.

    SPF steht für Sender Policy Framework und ist eine Art der E-Mail-Authentifizierung, die verwendet wird, um den Absender zu identifizieren und sicherzustellen, dass er das Recht hat, E-Mails von dieser Domain zu versenden. Dazu wird ein DNS-TXT-Eintrag hinzugefügt, um die autorisierten Absender Domänen zu überprüfen. Dies hilft, bösartige E-Mails zu verhindern, die vorgeben, von deiner Domain zu stammen, auch bekannt als Spoofing oder genutzt zum Phiching.

    DMARC steht für Domainbased Message Authentication Reporting and Conformance. Dies ist ein weiterer E-Mail-Authentifizierungsstandard, der verwendet wird, um den Ursprung einer Nachricht zu überprüfen und sicherzustellen, dass sie während der Übertragung nicht verändert wurde. DMARC erfordert zwei DNS-Einträge: einen DKIM-Eintrag, der die Identität des Absenders verifiziert, und einen zusätzlichen TXT-Eintrag, für die Richtlinie des Absenders.

    DKIM steht für DomainKeys Identified Mail und ist eine Art der Authentifizierung, um die Identität des Absenders zu überprüfen. Dazu wird eine kryptografische DKIM-Signatur in den Header einer E-Mail-Nachricht eingefügt, die dann mit einem öffentlichen Schlüssel verglichen wird, der im DNS-Eintrag einer Domain gespeichert ist. So wird sichergestellt, dass nur autorisierte Absender e-Mails von einer Domain aus versenden.

    BIMI steht für Brand Indicators for Message Identification und ist ein E-Mail-Authentifizierungsstandard, der es Marken ermöglicht, ihr Logo in der Mailbox der Empfänger/innen anzuzeigen. Dies hilft den Empfängern, die Echtheit einer E-Mail zu überprüfen und sie visuell zu identifizieren. Dazu muss ein BIMI-Eintrag zu einer Domain hinzugefügt werden.

    Auch das geht wieder mit DSN Einträgen. Diese werden dann von den E-Mail-Empfängern verwendet, um den Absender zu authentifizieren und sein Logo im Posteingang anzuzeigen. BIMI ermöglicht es den Absendern auch, verschiedene Logos für unterschiedliche Nachrichten zu verwenden, was ihnen bei der Personalisierung von E-Mails hilft. Dies trägt auch zum Schutz vor Phishing- und Spoofing-Versuchen bei, da es den Nutzern ermöglicht, legitime E-Mails schnell zu erkennen von der gefälschten Mail.

    Insgesamt tragen alle diese E-Mail-Authentifizierungsstandards zum Schutz vor Phishing, Spoofing und anderen Cyber-Bedrohungen bei, indem sie die Identität der Absender überprüfen und eine einfache Identifizierung und Authentifizierung von E-Mails ermöglichen. Durch die gemeinsame Verwendung von SPF-, DMARC-, DKIM- und BIMI-Einträgen in den DNS-Einträgen einer Domain, können E-Mail-Versender sicherstellen, dass ihre E-Mails ordnungsgemäß authentifiziert werden und die vorgesehenen Empfänger erreichen. Dies verbessert die Zustellbarkeit von E-Mails und schützt vor bösartigen Angriffen und Spam, sowie gefälschten Mails.

    Das SMTP Protokoll ist erforderlich, PHP Mail reicht da leider nicht

    SMTP wird gebraucht, um sicherzustellen, dass all diese E-Mail-Authentifizierungsstandards richtig umgesetzt werden. Außerdem ist es wichtig, die DNS-Einträge auf dem neuesten Stand zu halten und Änderungen zu überwachen, um sicherzustellen, dass E-Mails sicher versendet werden können. Die ordnungsgemäße Umsetzung der SPF-, DMARC-, DKIM- und BIMI-Protokolle hilft, sowohl Absender als auch Empfänger vor böswilligen Angriffen zu schützen.

    Gleichzeitig hilft es auch den E-Mail-Anbietern, E-Mails zu authentifizieren und die Nutzer/innen vor dem Erhalt unerwünschter oder schädlicher Nachrichten zu schützen.

    Wie kann ich meinen E-Mailversand testen?

    Es gibt sicherlich noch weitere Testtools, diese sind aber ganz brauchbar. https://mxtoolbox.com/ fällt mir da auch noch ein, ist ganz brauchbar.

    BIMI is schon geil, ich meine auch AOL zeigt das an. Zu den technischen Details... hmm fragt einfach. Ich habe es bei mir mit BIMI und DMARC so eingerichtet, das ich von den großen Providern wie Google, Yahoo Mail usw. auch täglich einen Bericht erhalte. Das wusste ich leider bisher auch noch nicht, dass es geht. Enttäuschenderweise versenden alle großen Provider diesen in ZIP oder GZ Format. Da habe ich immer ein bissl Bammel....