Beiträge von Synonym

Ich habe Kunden, die eine Mail von Ihrer Domain haben. So wie eigentlich jeder. Diese Kunden leiten die Mails aber weiter an z.B. T-Online oder gmail. Schrieb ich nun doch schon mehrfach.

Mein System sendet an -> email@domain.de (z.B. von Host Europe - ISPGateway)

Dieser Mailserver leitet dann weiter an name@gmail.com

Gmail prüft nun den SPF, wie oben ersichtlich. Gmail nimmt also MEINE Sender-Domain und prüft, ob die IP des weiterleitenden Mailservers (von Host Europe - ISPGateway) berechtigt ist. Was sie nicht ist. Logisch. Schließlich stehen die Mailserver von ISPGateway NICHT IN MEINEM SPF.

Siehe oben. Es wird die IP von ISPGateway gegen den SPF von meiner Domain verglichen. Nicht meine Domain gegen meine IP und nicht ISP-Domain gegen ISP-IP, sondern deren ISP-IP gegen meine Domain.

"Warum sendest nicht direkt an T-Online?"

Weil ich das nicht weiß! Wenn sich einer anmeldet oder die Adresse ändert in neue-adresse@webseite.de, dann weiß ich doch nicht, ob der die Adresse bei sich nochmal weiterleitet? Woher soll ich das denn wissen? Gibt auch genug, die im Urlaub Adressen umleiten. Das weiß doch der Sender nicht. Erst, wenn die Mail zurückkommt. Ich weiß doch auch nicht, wenn Du Deine Emails weiterleitest, ich schreibe an die gleiche wie vorher auch. Meine "gmx-Adresse" leitet auch weiter. Müsste ich nun also auch fragen, warum Du das nicht weißt. Logisch, weil das ja nicht im Bereich des Senders liegt, was der Empfänger damit macht.

Ich weiß auch nicht, was es da immer zum nachhaken gibt. Also nochmal....

Ich sende eine Mail. Absender sender@sender.de

Diese Mail geht an kunde@kunde.de

Der Kunde leitet die Mail aber weiter an google@gmail.de

Jetzt bekomme ich von Gmail den Bounce, SPF falsch.

Klar, ich weiß ja was passiert, nur nicht warum.

Schicke ich die Mail raus, dann ist das:

Original-Sender: Meine Domain / Email

IP: Meine IP

Schickt der Mailserver dazwischen die weiter, denn steht im Header

Sender: Meine Domain / Email

IP: Die des Mailservers, der weiterleitet

Google hat dann: Sender = meine Domain / Email, IP = weiterleitende Mailserver

Also fragt Google mein SPF ab. Den Record, den Du oben nanntest. Logisch, mein SPF, ist ja auch meine Domain und meine Email. Aber es wird nicht mit meiner Original-IP verglichen, sondern mit der des Mailsystems dazwischen, denn dort steht ja deren IP drinnen, denn die leiteten ja weiter.

Es kann doch nicht so schwer sein.

Mein SPF hat nichts mit dem Mailserver von ISP zu tun. Und die IP von ISP hat nichts mit mir zu tun. Google und die anderen prüfen aber mein SPF mit der IP von ISP.

So, wie schon gesagt, das Spiel geht die ganze Zeit so. Diesmal kam drei per DMARC zurück, Grund auch dort SPF falsch.

Das war ein Kennwort-Reset von einer Kundin. Auch hier, Sender-Domain und SPF ist mein System, also richtig. Geprüft wird aber gegen die IP des weiterleitenden Mailservers und das ist in dem Fall Alfahosting. Hier ging die Mail per Weiterleitung von einer Domain-Adresse des Kunden an T-Online. Hier kam nur kein Bounce von T-Online oder Alfahosting, sondern einfach der DMARC-Bericht.

Hier dann noch mal. Gleiche Kunde, zweiter Versuch des Resets. Ging natürlich auch nicht. Anderes Mail-Relay, aber wieder Alfahosting nach T-Online.

Und hier Nummer drei vom gleichen Tag. Das war eine Weiterleitung über Host Europa nach Gmail. Also exakt das gleiche wie im ersten Post oben, nur andere Adressen und anderer Kunde.

Die gefühlt 50 anderen Mails in dem Report waren alle korrekt und "pass". Alle mit meiner Domain, meinem SPF und meiner IP (v4 oder v6). Nur in diesen Weiterleitungen wird ständig die falsche IP mit dem falschen Sender verglichen.

Ich persönlich suche ja eigentlich auch irgendeine "kreative" Möglichkeit, also so was wie mein bisheriges "jeden zweiten Wert vertauschen". Der Obfuscator wäre eine fertige Lösung, der alles extrem kompliziert macht, geht in dem Fall aber nicht wirklich. Das was das "verschleiert" werden soll, ist ja im Grunde nur eine Variable mit Daten, in dem Fall halt viele Daten. Der Rest vom Script ist ca. 100x größer und völlig egal. Das beruht ja ohnehin auf den öffentlichen Klassen, die man überall downloaden kann.

Urheberrecht? Kann ich mir nicht vorstellen. Im Grunde sind das ja auch nur öffentliche Daten, aber eben zusammengesucht. Hundestrände: Da kann man die nehmen, die schon in den Maps sind. Ich kann aber sagen, 20% fehlen und von den vorhandenen Daten sind 50% falsch. Ich suchte mir das halt alles selbst zusammen, über die Orte und Gemeinden, deren Satzungen etc. Dann hat man Daten wie "Nordstrand Abschnitt 17b". Toll, also erst mal den Nordstrand finden und dann noch, wo der Abschnitt 17b ist. Genau deswegen sind ja bisher die Daten so oft falsch, weil die Leute bisher einfach den Nordstrand genommen haben und einfach einen Pin da rein setzen. Ob das dann aber 17b oder 12a ist, egal. Steht in den Maps ja auch nicht, muss man suchen über Gebäude, Straßen, Verformungen an den Lüsten, Routen von Schiffen etc.

Also ist das alles eigentlich nur eine Liste an Koordinaten für etwas, was auf den einzelnen Gemeinden selbst in Text steht. Nee sau Arbeit, aber wirklich geheim oder neu ist das ja nicht.

Und kopiert wird so was sehr gerne, vor allem von Blogs, die eben so was darstellen wollen. Die klauen ja schon die Texte und schreiben um. Im Text steht ja quasi auch jeder Strand drinnen, aber eben als Textform mit eben "Abschnitt 17b". Ist halt einfacher, wenn man eine Seite hat, auf der 288 Strände der Ostsee in einer Liste stehen, als die selbst suchen zu müssen. In der Map sind ist dann die genauen Positionen. Sehe ich gut mit einem Hundestrand am Bodensee. Ich war eigentlich der Erste, der den erwähnte, denn es ist kein "offizieller", aber geduldet. Der hat auch keinen Namen oder so, sondern heißt einfach nur "zwischen Meersburg und Überlingen". Der Uferbereich da ist aber 25 km lang und nur ca. 2 km sind Strand und davon nur 500 Meter Hundestrand. Das wurde in Textform auch übernommen, aber ohne genaue Position und zeug erfunden wie "feiner Sand". Naja, da gibt es keinen Sand. Da gibt es groben und großen Kiesel. Ich selbst hatte keine Karten, die anderen versuchten es und lagen völlig falsch. Naja, wenn man den Uferbereich nicht kennt, dann ist das halt Mist. Auf den normalen Maps sieht man den auch nicht wirklich, denn der ist nur ca. 12 Meter breit und daneben ist eine Böschung mit Bäumen, Böschung zur Straße hin. Man sieht also im Luftbild eigentlich nur Bäume und dann Wasser. Mittlerweile habe ich da Positionen und nun tauchen die auch bei anderen auf. Das ist aber eine einzelne Koordinate und eben keine Liste von 500.

Und das mit den Polygon dito. Viele regionale Tourismusbüros und offizielle Seiten haben solche Karten, aber eben nur für ihre Region selbst und das dann auch noch als Bild, das eher eine Strichzeichnung ist. So wirklich erkennen, wo da die Region genau aufhört und eine andere anfängt, kann man da nicht. Das geht mit meinen Polygonen aber, denn das ist genau der Sinn von denen. Aber auch hier. Einen groben Umriss für das Allgäu kannste mit 20 Datenpunkten machen, dauert 2 Minuten, fertig. Meine Polygon hat 6 Stunden gebraucht. Warum? Weil das viel genauer ist. Weil das Allgäu nicht nur das klassische Allgäu in Bayern ist, sondern da auch noch Bayerisch Schwaben mit tangiert, Oberschwaben-Allgäu in BW, z.B. Orte wie Wangen / Lindau etc, die zwar auch zum Allgäu gehören, aber touristisch dem Bodensee zugeordnet werden. Genau diese Anhängigkeiten sind in den Polygonen. Sieht man z.B. oben in meinem Bild mit den Regionen. Je dunkler blau die sind, desto mehr Überlagerungen gibt es mit anderen Regionen. Wobei meine Polygone bisher auch nur der Anfang sind, also primäre Grundebene, um Deutschland abzudecken. Alleine das vorhandene Allgäu hätte ja noch einige weiter in sich: West, Ost etc.

Und die Daten sind halt auch nicht frei erfunden, sondern von den jeweiligen Bundesländern, Städten, Ministerien, Landesvermessungsamt, Statistisches Bundesamt der Länder etc. zusammengetragen und dann mühevoll in den Karten erfasst.

Es wird ganz normal per SMPT über meinen Mailserver gesendet. Der Mailserver bzw. die entsprechende Domain hat einen SPF, der explizit meinen Mail-Server per Name, allgemein meine MX als auch meine A-Records freigibt. Also alles richtig.

HE leitet die Mail dann weiter und Google prüft dann den SPF, aber eben den SPF meiner Absender-Domain GEGEN die IP von HE. Und klar, in meinem SPF steht die IP von HE nicht als berechtigt drinnen, warum auch?

Und nein, kein Fake. Die Mail wurde um 9:57 verschickt, an die ch-Adresse und um 9:57 Uhr kam ebenfalls der Fehler direkt zurück, von:

Received: from [80.67.18.34] (helo=mx17.ispgateway.de). Der Bounce selbst ist aber von Google (host gmail-smtp-in.l.google.com [74.125.133.xx]). HE reicht den dann wohl durch.

Ich glaube kaum, dass das alles Spammer sind, die Bounce-Mails faken und dann ein Support-Ticket öffnen oder anrufen, weil sie auf eine Mail warten.

Aber wie gesagt. Es wird nicht meine IP mit meinem SPF verglichen, sondern die IP von HE mit meinem SPF.

Schicke ich direkt an die Adresse von Google geht das. Nur mit der Weiterleitung nicht und das haben eben sehr viele Nutzer und ich kann als Sender nicht wissen, ob das Ziel weiterleitet oder nicht.

Habe ich doch schon in einem anderen Fred mal geschrieben. Mit 1und1 ebenso, wenn eine Weiterleitung da ist. Da kommt dann der DKIM-Bereicht zurück, dass eine Mail abgelehnt wurde, weil die IP nicht zugelassen ist. Auch dort immer, das ist nicht meine IP, sondern eine von einem 1und1-Mail-Server, der (wohl) weiterleitet. Sieht man dort im Bericht ja nicht, nur eben, dass das nicht meine IP ist und daher eben "fail".

Die scheinen also alle in "meinem Namen" weiterzuleiten, was dann das Ziel veranlasst, meine Sender-Domain mit der IP des Mailservers zu vergleichen. Aber der Mail-Server ist dann halt nicht meiner, somit eben falsch.

Da es ja immer angedeutet wird, mein System wäre irgendwie falsch oder SPF bzw. DKIM sei so wichtig, nun mal eine Frage dazu.

Wie ist denn damit umzugehen?

Mail delivery failed: returning message to sender

  websxxxx@gmail.com
    (ultimately generated from skiclub@xxxxration.ch)
    host gmail-smtp-in.l.google.com [74.125.133.xx]
    SMTP error from remote mail server after pipelined end of data:
    550-5.7.26 The MAIL FROM domain [belegungskalenderxxxx] has an SPF
    550-5.7.26 record with a hard fail policy (-all) but it fails to pass SPF
    550-5.7.26 checks with the ip: [80.67.18.xx]. To best protect our users from
    550-5.7.26 spam and phishing, the message has been blocked. Please visit
    550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more
    550 5.7.26 information. g6-20020a05600c4ec600b114fbc7e32811si8292183wmq.42 - gsmtp

Mein System (Belegungskalender) verschickt also eine Mail. Diese geht an eine Adresse der Schweiz (Skiclub). Diese leiten dann irgendwie weiter an eine Adresse von Gmail. So, nun prüft da wohl Gmail den SPF (ist doch Gmail, der prüft, oder?) Die IP, für die geprüft wird, ist die 80.67.18.xx. Diese gehört zu "Host Europe", ist deren Mailserver. Diese hat mit mir und meinem SPF nichts zu tun, folglich ist das falsch und "hard fail".

Der Bounce kommt zurück von "ispgateway", also Host Europe. Wer prüft da denn nun genau was und wie und warum wird da gegen meine SPF eine IP geprüft, die ich gar nicht habe und mir nicht gehört?

Müsste nicht eigentlich die "ch-Adresse", also der Mailserver von Host Europe den SPF von mir prüfen und dann, nach der Weiterleitung, Gmail den SPF von der "ch" bzw. Host Europe als Weiterleiter??? Hier wird aber, wie erwähnt, die IP des Mailsservers von der ch-Domain gegen meinen Domainnamen geprüft. Das kann natürlich nicht funktionieren, denn HE ist in meinen SPF nicht als Sender freigegeben. Warum auch, ist ja nicht mein Mailserver.

So. vielleicht kann das ja einer erklären. Alex? Wäre ja alles so wichtig etc. Das Problem da habe ich ständig, auch mit T-Online und Web.de, wenn da Mails weitergeleitet werden.

So, und wenn man ein wenig sucht, dann landet man unter anderem auch im Forum von DomainFactory. Dort gibt es einen Thread mit 7 Seiten und genau dem gleichen Problem, allerdings schon über einem Jahr alt:

Huch, nicht wahr? Das ist die gleiche IP, wie bei mir in der Meldung.

Und die Lösung, die die Mods dort empfehlen ist entweder, bei seiner eigenen Domain den SPF auch für MX von domainfactory zu erweitern oder den "hard fail" zu entfernen oder "keine Weiterleitung" zu nutzen. Die beiden ersten Sachen kommen für mich nicht in Frage und die dritte Möglicheit obliegt nicht mir. Ich habe nur das Problem, dass meine Mails nicht ankommen, genau wegen dem SPF und weil da eben Original-Sender-Domain mit einer fremden Mailserver-IP verglichen wird.

Naja, Du jägst auch an die 300 bis 400 kB an JS und CSS-Daten inline mit raus pro Seite, was Du vorher nicht hattest Also nix mit Cache, sondern nun extra pro Zugriff.

alte Seite: 52.167 Byte

neue Seite: 493.125 Byte

Selbst wenn das komprimiert wird, ist das dennoch das 9-fache.

Also wenn Du eine Idee hast, wie das anders geht, gerne

Die Maps gehen ja nicht ohne Javascript. Also ohne JS braucht es dann auch kein Polygon. Das ganze intern per PHP lösen oder so geht ja nicht wirklich. Das muss ja in die Map und entsprechend auch zoom- und verschiebbar sein. Also da ein statisches SVG erzeugen und drüberlegen funktioniert nicht. Naja, technisch schon, ergibt aber keinen Sinn, passt dann ja nicht zur Karte. Daher braucht das JS ja das GeoJSON, damit es dann, je nach Zoom oder Position, das Polygon als SVG berechnen kann.

Dass das aktuell direkt im Quelltext steht, ist nur aus der Not und zum Test heraus. Später soll das mal per Ajax abgerufen werden, so wie die ganzen Pins für die Unterkünfte auch. Das ändert aber nichts an dem Datenstring. Denn auch bei einem externen Request stehen die dann ja als Klartext in der Antwort.

Dachte schon an eine Lösung per Cookie, aber das ist halt so eine Sache. Per PHP Cookie setzen und dann per JS auslesen. Aber das sind bis zu 25 kB an Daten, also zu viel für Cookies.

Also im Prinzip bist Du schon auf dem richtigen Weg, nur wohl nicht ganz. Diese Obfuscator habe ich schon versucht und kam damit nicht ans Ziel, also nichtmal ansatzweise. Kann aber auch sein, dass ich das Online-Teil falsch benutzt habe, denn hier in Deinem Artikel hatten die genau das gleiche Problem. Bei denen war ja anfangs das "Hallo SUS" auch leserlich, der Rest verschwurbelt. Bei mir quasi genauso, alles unleserlich, aber ausgerechnet die Variable mit den Koordinaten blieb unberührt. Naja, es wurden die Leerzeichen unkenntlich gemacht. Also genau so, wie in dem Artikel. Dass es da noch eine andere Option gibt, hatte ich nicht gewusst.

Aber ich bin mir nicht sicher, ob mir das weiterhilft. Es geht mir ja nur um die Daten, nicht um das Script selbst. Also die Daten in der "var polygon".

Die sind also in der Datenbank und werden von PHP verarbeitet. Intern für diverse Dinge genutzt wie Umkreisberechnungen etc. Dann sollen die aber auch in die Map mit aufgenommen werden und das ist dann eben Javascript. Also schreibe ich die als "var polygon" in den Quelltext und JS nutzt die dann in seinem Programm weiter. Genau diese Stelle ist das Problem, diese, wo die Daten öffentlich einfach so 1zu1 sichtbar sind.

Mit dem Obfuscator kam ich ja noch nicht so weit, aber ich glaube, da zwei Probleme zu sehen.

1. muss diese "Verschwublung" PHP selbst machen. So wie es scheint, braucht der Obfuscator aber Node.js. Das muss aber PHP on-the-fly machen, also direkt aus den Originaldaten beim Seitenaufruf. Bei jeder Seite andere Daten.

2. Muss dann am Ende, wenn die Daten in die Map sollen, die Variable "var polygon" wieder den Originalwert enthalten, also den original GeoJson-String. Alles andere geht da nicht, da gibt dann die Map-Klasse sonst Fehler aus. Sichtbar ist der dann dort ja nicht, ist ja nur eine Variable. Sichtbar ist er nur beim Übergang von PHP nach JS. Es scheint aber so zu sein, dass die dann nach dem Obfuscator auch nicht die Originaldaten hat, sondern diese berechnet werden müssen. Also nicht im Sinne von decode -> encode.

Witzigerweise, dieses rot13. Der Klassiker aus 1995 So was in der Art, also PHP muss es "unkenntlich" machen und JS wieder "lesbar". Im Grunde ist dieses GeoJSON ja nur ein String und keine Koordinaten im technischen Sinne. Also ein String, der zufällig 98% Ziffern enthält. Dooferweise wandelt aber rot13 keine Ziffern um, nur Buchstaben. Und performant ist das auch nicht, da bei 500 Koordinaten, alle jeweils mit LAT und LON und dann jeweils 9-10 Stellen, das Zeichen für Zeichen zu machen. Das sind ja, ohne die Leerzeichen, Anführungszeichen, Punkte und sonstiges Zeug alleine schon 10.000 Ziffern. Da kommt schon was zusammen und läuft ja in Echtzeit. PHP könnte das recht gut, aber JS scheitert daran. Das verdoppelt oder verdreifacht die Script-Ausführung und so lange das nicht ausgeführt ist, gibt es halt auch nix anderes.

Sagt mal, gibt es einen eleganten, einfachen und vor allem kostenlosen Weg, ein Javascript bzw. enthaltene Daten vor Fremden zu schützen? Problem ist, die Daten stehen da ja quasi als Reintext drinnen und können schlicht binnen Sekunden kopiert werden. Finde ich weniger schön. Mir geht es nicht um das ganze Javascript, nur um Daten, die es für die Verarbeitung braucht.

In dem Fall speziell Koordinaten für Google Maps bzw. Leaflet. Über die Koordinaten werden Polygone generiert, aber auch einfach Standorte auf der Karte gezeigt, z.B. "Hundestrände an der Nordsee". Da steckt jeweils verdammt viel Arbeit drinnen, vor allem in den Polygonen. Das können schon mal an die 500 Datenpunkte sein, für eine einzige Region in Deutschland und bekanntlich gibt es da sehr viele.

Im Grunde erzeugt das quasi solche Karten:

Das ist nun eine Übersicht aller erfassten Regionen. In der Nutzung sind die jeweils alleine. Die Daten für die Polygone müssen aber halt ins Javascript und stehen mehr oder weniger so im Quelltext (Beispiel für die Schwäbische Alb):

Wie man sich nun denken kann, das ist ein Kinderspiel, sich die Koordinaten zu kopieren.

Wie kann ich die nun schützen? Hat da einer eine Idee? Mir ist klar, irgendwo müssen die Daten wieder "normal" werden, sondern kann Leaflet die nicht anzeigen. In der Datenbank selbst stehen sie als Binärdaten für Geo-Objekte. Abgerufen werden sie als GeoJson und übergeben. Leaflet verarbeitet die dann zu SVG weiter und zeigt sie an. GeoJson muss es aber zu Beginn bleiben und am Ende, also bevor Leaflet das verarbeitet, muss es auch wieder GeoJson sein.

Aber der Weg dazwischen ist eigentlich völlig offen und im Prinzip auch genau die Stelle, wo einfach kopiert werden kann.

Aktuell fange ich schon an, das Array nach einem bestimmten Muster vor der Übermittlung zu verändern, z.B. jede zweite Koordinate mit der vorherigen vertauschen. Das ganze dann kurz vor der Anzeige wieder zurückrechnen. Das geht, einfach so kopieren ist auch nicht mehr, kommt dann nur Mist bei raus, aber es ist sehr rechenintensiv. Da muss das GeoJson, das ja schon fertig ist, erst wieder in ein normales Json umgewandelt werden, dann zerpflückt werden, dass man nur die "Coordinates" hat, das Array dann durchlaufen werden und die Koordinaten getauscht. Später dann, vor der eigentlichen Nutzung das ganze Prozedere per Javascript wieder rückwärts. Und wenn man nicht ganz doof ist, dann sieht man auch die Funktion, die den "Koordinaten-Swap" ausführt.

Nur welche Möglichkeiten gibt es noch? Habe da durchaus zwei Tools gefunden, die verschlüsseln mit verschiedenen Routinen. Aber das ist irgendwie auch Quatsch, denn der Key zur Entschlüsselung muss im Javascript mit hinterlegt sein, in Klartext. Zudem sind das Eigenentwicklungen von Leuten und keine offiziellen Module oder Klassen. Dann hatte ich schon versucht, die Koordinaten zu komprimieren, mit zip, bz2 oder sonst was, aber da scheint es kein Gegenstück in Javascript zu geben, jedenfalls nichts Offizielles, das auch überall funktioniert.

Einer hat wohl dafür eine Lösung, aber das ist dann Overkill. Der erzeugt aus solchen Daten Bilder mit farbigen Punkten. Also z.B. ein Bild mit 100x100 Pixel und jedes Pixel hat 12 verschiedene Farbmöglichkeiten, 10 für die Ziffern 0 bis 9 und zwei für die Zeichen "Punkt und Komma". Ok, damit kann man nix anfangen, aber der muss das auch wieder Pixel für Pixel zurückrechnen und sich dabei auf die Farberkennung des verwendeten Browsers verlassen. Sehr fehleranfällig und noch rechenlastiger also.

Hat einer eine Idee, wie man solche Datenbestände in Javascript schützen kann?

Jo, das ist aber doof. Im Grunde ist mir das auch egal, wie und wann Google die abruft. Bedeutet ja dann auch noch lange nicht, dass die Seite selbst dann auch abgerufen wird. Aber hin und wieder ist das schon nützlich oder zumindest etwas, was halbwegs bei Google funktionierte. Habe auch Seiten, bei denen ändert sich über das Jahr hin nichts und dann 5-10 neue Artikel binnen 8 Wochen. Schön, wenn man das eben direkt melden kann, einfach, ohne Umwege per Indexing-Api oder so.

Bei meiner großen sende ich bisher halt einmal am Tag ne Sitemap. Gut, ändert sich auch jeden Tag was, aber so wichtig sind die Änderungen eigentlich nicht. Ich habe da aber den Eindruck, dass der Bot dann irgendwie kontinuierlicher kommt. Bei anderen Seiten, wo ich nichts melde, nur eine neue erstelle und fertig ist teils nach Wochen und auch Monaten im Status der Seite immer noch die Meldung "nicht verlinkt" bzw. "nicht in Sitemap gefunden". Klar, wie auch, wenn die nicht mehr abgerufen wurde.

Und gerade auch dieses manuell einreichen ist ja oft so ein Problem, siehe hier: Sitemap konnte nicht abgerufen werden Da mit bin ich nicht alleine, was die Zugriffe hier auf die Seite belegen. Und das passiert sehr gerne, auch wenn eine Sitemap vorher schon über Jahre hinweg funktionierte.

Im Grunde war das aber nur ein Post, weil ich durchaus denke, dass dann im Dezember einige dumm schauen werden, wenn das plötzlich nicht mehr geht. Ich glaube kaum, dass da jeder den Google-Blog gelesen hat

Das mit den alten Sitemaps geht sogar so weit, dass hier in der ABM, ich meine die GSC, sehr oft die Warnung steht, von wegen "gesendete Seite nicht gefunden". Naja, als die gesendet wurde, war die Seite da. Ich kann nix für, dass Google Wochen braucht und mittlerweile das Angebot gar nicht mehr da ist. Hätten die schlicht die neue Sitemap mal gelesen, hätten sie gemerkt, dass die bemängelte URL da gar nicht mehr drinnen steht. Ich habe da halt recht hohe Fluktuation, gerade im Bereich Angebote, Lastminute, Feiertag. Da gibt es Seiten teils nur einige Tage oder 1-2 Wochen, dann sind die wieder weg.

Wenn das so geht, wäre das schön. Hier leider nicht wirklich. Ich habe Domänen, da wurde die Sitemap Tage und Wochen nicht neu verarbeitet. Gut, an denen ändert sich auch nicht ständig was, aber wenn mal, dann dauert das halt ewig, bis das mal bemerkt wird. Und bei meinen "Vergleichsportalen" ist das ähnlich. Das eine pinge ich täglich, die anderen alle nicht. Bei den anderen ist es genauso, dass die Sitemap teils über eine Woche alt ist, bis die mal erneuert wird. Die ältesten, die ich gerade auf die Schnelle gefunden habe, sind vom 4. und 8. Juli. Die, die ich pinge ist von gestern, also gestern 22 Uhr oder so.

Naja, das war ja nur ein Zugriff. Ob Google das dann machte, war eine andere Frage. Meine Erfahrung damit ist, wenn man zu oft oder zu schnell pingt, dann ruft Google die einfach nicht ab.

Und sparen tun die sich so ja auch nichts, denn man muss / soll ja nichts an seinen Systemen ändern. Der Aufruf darf weiterhin erfolgen, nur wird der eben direkt ignoriert

Zugegeben, gibt es schon ein paar Wochen. Auch wer es vorher schon möglich, bezahlte Links etc. zu melden. Neu ist da nun eigentlich nur, dass man nun auch Spam melden kann. Also Spam im Sinnen von Spam-Aktivitäten oder Spam-Inhalte. Ebenso, und das ist das interessante, Seiten mit Content von geringer Qualität. Im Grunde könnte man da bei vielen Suchanfragen die komplette erste Suchergebnisseite melden. Oder Seiten, deren Texte sich lesen wie von einem chinesischen Kleinkind geschrieben und dann von einem Inder erst ins Englische und dann ins Deutsche übersetzt.

https://search.google.com/search-console/report-spam?hl=de

Wobei da auch wohl wieder nur Google selbst weiß, was der Unterschied zwischen "Spam-Verhalten" und "Spam-Inhalte" ist.

Bisher war es ja üblich, dass vor allem CMS einen Ping sendeten, wenn eine Sitemap neu erzeugt wurde. Das klappte auch sehr gut. Manuell ging es ja auch recht einfach, wenn man schlicht die URL des Endpunktes und als Parameter die eigene Sitemap anhing.

Das ist bald Geschichte, Google wegen einer neues Sitemap anpingen geht nicht mehr. Google begründet es wegen "zu viel Spam" und stellt den Endpunkt für die Sitemap-Übermittlung ein. Wann genau ist unbekannt, voraussichtlich Mitte Dezember 2023.

Also das da geht dann nicht mehr:

www.google.com/webmasters/sitemaps/ping?sitemap=https://www.domain.de/pfad-zur-sitemap

Ab dann geht es, so wie Google sagt, nur noch per Eintrag in der Robots.txt oder als manuelle Meldung in der Search Console. Wobei da ja nur letztere übrig bleibt, denn die robots.txt ist ja keine Änderungsübermittlung, sondern nur eine Angabe, wo die Sitemap zu finden ist.

Bei Google kannste in der Search Console meiner Meinung nach alles ignorieren. Wenn man da rein schaut, wirft das alles mehr Fragen auf, als es beantwortet. Inkl. seltsamen Impressionen im 7-Tages-Takt, die keinen Sinn ergeben, aber Faktor 6-10 höher sind als normal.

Bei den WebVitals muss Du allerdings bedenken, dass dort nur die Seiten aufgeführt werden, zu denen ein Userbericht vorliegt. Um den zu haben brauchen die Seiten genügend Zugriffe über eben einen Chrome oder eine andere Software, die die Daten auch sendet, also das da: https://developer.chrome.com/docs/crux/ . Der manuelle Test ist ja nur, wie der Name sagt, manuell. Das geht mit allen Seiten, ist aber eben nur ein User. Die WebVitals sind aber die Durchschnittswerte zahlreicher Besucher einer Seite in den letzten 90 Tagen.

Und das mit den anderen Daten. Dito. Kann man einfach vergessen. Die Search Console ist eine ABM, mehr nicht. Produktsnippets habe ich laut GSC auch 230, müssten aber 1600 sein. Das habe ich aber über JSON-LD selbst eingefügt. Schon vorher tauchte aber bei der Domain der Punkt "Shopping-Tab-Ergebnisse" auf. Um die zu sehen und zu bearbeiten, soll ich das "Merchant Center" verwenden. In dem ist, welch Wunder, aber nichts enthalten, weil ich auch keine habe.

Und "mobile friendly" ist wieder was anderes als WebVitals. Du meintest aber ja die Mobilfreundlichkeit, zumindest machste ja den manuellen Test davon. Kannste auch knicken. Die beruht auch auf Userdaten und den Google-Bot. Aber das ist eine extra Prüfung, nicht der normale Zugriff. Bei mir sind da 983 gültig und 0 ungültig. Ergibt also in Summe 983. 983 von über 16.000 bzw. über 3.000, die im Index sind.

Und gleich nochmal knicken, denn das "mobile friendly" wird ja im Dezember abgeschafft: https://developers.google.com/search/blog/20…in-search?hl=de . Dafür gibt es dann eine neue Metric in den WebVitals.

Und das "Verhalten von Seiten" ist eine Mischung aus WebVitals und Mobile-Friendly.

Da kannste auch schlicht so was nehmen wie die "Navigationspfade". Stimmt auch hinten und vorne nicht. "Rezessionen"??? Habe ich angeblich 102. Genau genommen sind das 1600, denn bei jedem Produkt sind welche. Aber Google sagt ja, es sind nur 983 Produkte. Aber selbst dann müssten es auch 983 Rezessionen sein.

Für mich ausgedrückt: Ich sehe mich in der GSC auch immer wieder mal um, klicke hier und da, mache dort einen Test oder warte anderswo mal wieder "2 Minuten". Mit dem Ergebnis, dass alles, was ich da herausfinde, absolut nichts mit dem übereinstimmt, was in der GSC selbst steht oder eben die anderen Tools sagen oder das auch nur Ansatzweise mit der Realität stimmt. Nach etlichen Stunden weiß ich also auch nicht mehr als vorher, habe nur neue Fragen. Und wenn man denkt, das betrifft nur "große" Seiten, dann nee. Meine kleine mit genau 31 Seiten hat auch überall völlig falsche Werte.

"im Index sind". Na, laut GSC sind es ja 7200, aber laut Indexabfrage 3000. Huch, schon wieder was, was sich widerspricht und beide Daten von Google stammen.

Der Bing-Chat kann nun auch Fotos als Eingabe nutzen. Allerdings ist das etwas komisch. Mit manchen kommt er sehr gut klar, sagt einem sogar, wo man einen Joghurt kaufen kann, dessen Becher gerade auf dem Tisch des Testbildes stand oder interpretiert das Fernsehbild als Teil des Zimmers. So hat mein Wohnzimmer an der Wand angeblich ein Fenster, durch das man in den Nachbarraum sehen kann. Dort befindet sich ein Tisch und ein Regal. Ähm, ja. Das Fenster ist der TV gewesen. Tisch und Regal waren da aber wirklich - halt im Bild des TV-Bildes

Bei anderen hat er aber keine Ahnung. Z.B. bei einem eindeutigen Bild von einem Schloss. Die Frage, was das für ein Schloss ist, konnte er nicht beantworten und meinte nur, man soll die Google-Bildersuche nutzen. WTF??? Google-Bildersuche? Ok, die Bing-Bilder-Suche konnte es auch.

Manchmal stellt er sich auch etwas doof an und fragt nach, was auf dem Bild ist, damit er einem sagen kann, was drauf ist. Hä?

Guck ein paar Posts weiter oben, da gibt es sogar ein Bild dazu Es kann aber sein, dass das im Free-Account nun neu ist. Der Premium hat das schon, seit es quasi KI gibt.

Ich nutze das auch gerne, damit Abwechslung in den Satzbau kommt oder eben wenn der sich irgendwie "wirr" anhört.

Naja, ich habe hier 16 GB, und vor dem Start waren noch 1,5 frei (Lief gerade Ranktracker, der den fast komplett beanspruchte). Nachdem der dabei war Texte zu erstellen, war der RAM am Anschlag von 16 GB, CPU-Last aller 12 Cores am Anschlag, ging aber.

Edit: Eben noch mal versucht. Diesmal waren 5 GB frei. Programm gestartet, kein Unterschied, 5 GB frei. Dann das LLAMA Full ausgewählt, dann schnappte er sich von den 5 GB ganze 3 GB. Bei der Textgenerierung selbst ist kein Unterschied mehr, der geht dann nur hier auf 100% CPU-Last. Die restlichen 2 GB bleiben ungenutzt.

Und ja, CPU-Last. Das ist das Problem der alten Ryzen, die müssen jede Berechnung per AVX2 doppelt machen. Erst die neueren Modelle ab Ryzen 3000 können das in einem Durchlauf. Sollten also, rein logisch gesehen, in Sachen AVX2-Berechnung doppelt so schnell sein.

Was für eine Funktion ist das denn genau bzw. wo zu finden? Oder ist die da hier damit gemeint? https://languagetool.org/insights/de/beitrag/umformulieren/ Die gibt es nämlich eigentlich schon "immer", zumindest schon längere Zeit in der kostenpflichtigen Version. Wobei das nicht bei ganzen Texten geht, sondern nur mit Sätzen bzw. Abschnitten, daher die Frage.

Hast mal ein Beispiel, welche Domain da so gut profitiert? Ich sehe hier auch auf einigen Seiten deutliche Bewegungen, aber das gleicht sich alles gegenseitig aus. Z.B. der ganze Bereich "Nordsee" einer Domain ist um die +30 Plätze, dafür der Bereich "Ostsee" -30. Im Grunde also nichts gewonnen, nur umverteilt. Wobei das auch eher Änderungen in den hinteren Bereichen sind, also so zwischen Platz 30 bis 100. In den vorderen ist es eigentlich das übliche +-1.

In Summe geht es allerdings eher gen Abstieg.