Beiträge von Synonym

    Ja aber irgendwas muss nun ja anders sein als vor dem Update. Ich meine, Mail-Header wurden vorher ja auch gepostet.

    Was versteckt sich denn hinter "#1327576". Leider sagt mit die FW so rein gar nichts.

    Ja Chris, so schaut das leider aus, hatte es mir schon fast gedacht... wollte nur mal nachfragen.... SRS nutzen die nicht. Bleibt eigentlich nur noch den SPF-Record zu löschen, aber das will ich nicht wirklich bzw. kann ich eben nicht. Habe jetzt schon damit begonnen, die Zieladressen hier in den Kundensätzen zu ändern, wenn es mir denn möglich ist, aber bei allen anderen Kundenanfragen, also von Besuchern, kann ich rein gar nichts machen - außer löschen :(

    Das hier ist aktuell kein Spam oder keine Blacklist oder so, das ist der SPF-Record.

    Mein System hat SPF aktiv und sendet an einen anderen Server. Das geht alles ohne Probleme. Nur wenn jetzt der andere Server ein einen dritten Weiterleitet, z.B. an Web.de, dann passiert folgendes: Web.de prüft die Sender-Email, was ja meine ist. Ruft also meinen SPF ab. Da die Mail aber weitergeleitet ist, ist die IP die vom Weiterleitungsserver. Und mein SPF sagt dann, nee, die IP darf nicht in meinem Namen senden.

    Erst also:
    Meine Mailadresse
    Meine IP

    Geht dann an den bekannten Empfänger. Der leitet aber weiter.

    Und nach der Weiterleitung
    Meine Mailadresse
    Fremde IP

    Weg dann an web.de und die prüfen. Rufen also den SPF meiner Domain und den MX ab. Ermitteln die IP und stellen dann fest, dass die SenderIP (Weiterleiter) nicht zu meinem SPF passt.

    Das kann ich aber nicht ändern, denn ich weiß ja nicht, was der Empfänger mit der Mail macht. Die Weiterleitung ist mir, wenn es fehlerfrei geht, ja unbekannt.

    Das ging bisher alles fehlerfrei. So wie ich das aber zwischenzeitlich gelesen haben, haben web.de und gmx.de am 25.5. ihr SPF-Prüfung auf "strict" umgestellt. Und dieses "SRS" soll eigentlich genau das verhindern, indem der weiterleitende Server nämlich als Absender sich selbst einträgt, meine Adresse also ersetzt. Dann würde es ja wieder passen. Fremde Adresse und fremde IP.

    Und die whitelist würde in dem Fall hier bedeuten, dass web.de nicht meinen Server listet, sondern den Weiterleitungsserver und für den keine SPF-Prüfung durchführt (was ja letztendlich bei mir landet, wegen der Adresse).

    Lösung drei wäre wohl, SPF zu deaktivieren, aber das ist keine wirkliche Lösung. Warum soll ich das Scheunentor aufmachen? Und zudem brauche ich SPF für einige Anbieter, die ohne die Mails automatisch als Spam einstufen (z.B. Hotmail, Live, teilweise auch AOL).

    Hallo zusammen, seit ca. 3 oder 4 Tagen kommen bei mir zahlreiche Mail mit "Reject due to SPF policy" als Fehler zurück. Sie wie es ausschaut sind es allesamt Weiterleitungen an web.de oder gmx. Hat einer einen Tipp. wie sich das schnell, einfach und unkompliziert verhindern lässt? Die beiden Mailanbieter waren bisher die einzigen, die immer fehlerfrei funktionierten und jetzt ist das die Hölle.

    Mailheader:

    Wenn ich das ja richtig sehe, dann wurde die Mail an kundendomain.com bei "unbekannter-hoster.de" übergeben. Dort scheint es nun eine Weiterleitung nach weiterleitungs-empfaenger@web.de zu geben, wo der Fehler dann passiert. web.de lehnt den Empfang ab und der "unbekannter-hoster.de" schickt die Fehlermeldung an meine Mailadresse.

    Die angegebene IP im Bounce, also das http://postmaster.web.de/error-messages?ip=83.137.100.199&c=spf, ist von "unbekannter-hoster.de". Das ist nicht meine Server-IP.

    So, was nun tun? Am Server kann ich nicht viel machen, habe keinen Paketzugriff mehr.....

    Edit: Nach schnellen Recherchen gäbe es da als Lösung wohl "SRS" (Sender Rewriting Scheme). Wenn ich das aber richtig verstanden habe, dann muss diese Umschreibung der Weiterleitungsserver tätigen und nicht der Erstsender. In meinem Fall also "unbekannter-hoster.de" und bei den anderen Mails noch viele andere Anbieter.

    Lösung zwei wohl eine Whitelist, die muss aber beim Empfänger sein, also web oder gmx und die werden ja wohl kaum für weiß der Geier wie viele tausende Domains eine Whitelist anlegen.

    Hm....

    Alex, Du sagst es war die Firewall. Wurde an der denn auch was geändert mit dem Update auf vb 5.2.2 ??? Wollte eben wieder einen Post aufmachen, weil ich da bei was Unterstützung brauche und es geht wieder nicht. Diesmal steht da kein base64 oder sonst was drinnen, sondern ein Mail-Header . Soll ich nun hergehen und in den 39 Zeilen Header-Code das Zeichen suchen, das Probleme macht???

    Fehler-ID diesmal: #1327576

    So, Post ging jetzt raus, aber das ist kein Zustand. Diesmal war die Lösung, bei den ganzen "Return-Path Received From" vor den folgenden Doppelpunkt einen Unterstrich zu setzen.

    Danke Seo-Nw, hat sich erledigt.... :hurra:

    Und es tut was es soll. Die statischen -40px noch ersetzt durch die Div-Height und es ist perfekt.

    Das Forum ist echt wie ein Spickzettel. Man überlegt, wie man was mit 100% Inhalt möglichst kurz schreibt und danach kennt man die Lösung, die man vorher suchte. Bei Spickzetteln kannte man in der Regel die Antworten auch, ohne den Zettel nutzen zu müssen :smile:

    Hallo zusammen,

    diesmal habe ich noch nicht gesucht, ich frage gleich ;) Lässt sich aber schwer erklären, was ich suche. Ich habe da ein Menü, das responsive vertikal aufgebaut ist, also

    Punkt A
    Punkt B
    Punkt C
    Punkt D

    Klickt man z.B. "Punkt B" an, dann öffnet sich darunter, also zwischen B und C das Submenü.

    Punkt A
    Punkt B
    - Punkt B.1
    - Punkt B.2
    - Punkt B.3
    - Punkt B.4
    - Punkt B.5
    - Punkt B.6
    - Punkt B.7
    Punkt C
    Punkt D

    Scrollt man weiter und klickt dann auf "Punkt C", dann schließt sich Punkt B und Punkt C geht auf.

    Punkt A
    Punkt B
    Punkt C
    - Punkt C.1
    - Punkt C.2
    - Punkt C.3
    - Punkt C.4
    - Punkt C.5
    - Punkt C.6
    Punkt D

    Mein Problem hier ist nun, dass in dem fiktiven Beispiel das Submenü von "Punkt B" recht lang gewesen sein kann und sich durch das Schließen dessen, der eigentliche "Punkt C" deutlich nach oben schiebt, teilweise samt Submenü aus dem Anzeigenbereich hinaus.

    Gibt es da eine einfache und fertige Lösung, dass sich ein Menüpunkt, z.B. "Punkt C" maximal bis Bildschirmanfang schiebt bzw. andersrum, dass der Bildschirm automatisch hochspringt, bis Punkt C vollständig zu sehen ist? Denke da gerade irgendwie an ScrollTo() aber tappe komplett im Dunkeln.

    Mit Ankern müsste es gehen, aber ich wollte da jetzt nicht extra überall welche einbauen, denn diese Punkte sind eigentlich keine Links, nur Text.

    Hat einer eine einfach Lösung?

    Danke und Gruß,
    Ingo

    Anmerkung noch, vor allem bei den responsive-Ads. Google berechnet die Größe anhand der Größenangaben des Ad-Codes bzw. der umliegenden Box und vom Viewport. Das Problem dabei ist nur, dass das umliegende Div in der Regel eine Breite hat, aber keine Höhe. Z.B. Sidebar. Die Breite wird da in der Regel definiert, die Höhe nicht, denn die Höhe richtet sich nach dem Content.

    Dazu kommt, dass das responsive-Ad selbst keine Größenangaben hat, also einfach nur so ausschaut:

    HTML
    <ins class="adsbygoogle gslot1"
    style="display:block"
    data-ad-client="ca-pub-xxx"
    data-ad-slot="xxx"
    data-ad-format="auto">
    </ins>

    Hier kommen dann die Probleme zusammen. Es gibt keine Höhe im CSS, keine Größe im Ad und der Viewport ist womöglich kleiner als der Content lang ist. Letzteres wird immer extremer, je kleiner der Schirm und ja länger der Inhalt wird.

    Ergebnis: Google liefert z.B. in einer Sidebar, die 300px breit und theoretisch 2000px lang sein könnte nur ein Ad aus, das max. 300px breit und nur wenig länger ist als der Viewport, ab Beginn des Ads gerechnet. Es kommen dann z.B. sehr gerne Anzeigen im Format 300x250px, obwohl 300x600px ja auch problemlos passen würde. Scrollt nun der User etwas nach unten, weil der Text ja viel länger ist, dann sieht der das Ad gar nicht mehr.

    Gegenangriff... Google nicht die volle Kontrolle überlassen und Größen der responsive-Ads definieren. Bei mir im Falle von *** Link veraltet *** z.B.

    HTML
    <style type="text/css">
    .gslot1 { display:inline-block; width: 200px; height: 600px; } .gslot2 { display:inline-block; width: 300px; height: 600px; }
    @media (max-width:1000px) { .gslot1 { width: 190px; height: 600px; } .gslot2 { width: 200px; height: 600px; } }
    @media (max-width:768px) { .gslot1 { width: 100%; } .gslot2 { width: 200px; height: 600px; } }
    @media (max-width:600px) { .gslot1 {  } .gslot2 { width: 100%; } }
    @media (max-width:480px) { .gslot1 {  } .gslot2 {  } }
    </style>

    Somit wird Google überhaupt erst mitgeteilt, wie groß das Ad überhaupt sein darf. Danach kommen wesentlich häufiger größere Ads als vorher, denn der Viewport ist dann zweitrangig.

    Leider müssen die Angaben aber direkt in den <head>, im .css funktionieren sie nicht.

    Edit: Der Viewport, der gerne kleine Anzeigen brachte: [ATTACH=CONFIG]n105363[/ATTACH]


    Mit den Größenangaben kommen fast immer lange Anzeigen:
    [ATTACH=CONFIG]n105364[/ATTACH]

    Alex, ich schreibe jetzt nicht, dass ich das ja schon sagte, denn das hatte ich ja schon geschrieben. Aber ja, es stimmt.

    Ich habe auch zig mal Empfehlungen von Google getestet, aber eben wirklich als Test und nicht direkt live gesetzt. Und egal was es war, 160px zu 300px, Textanzeigen zu Multimedia, 3 Block rein, wo nur zwei waren.... Egal was, es ging bis auf einmal immer nach hinten los. Auch gab es Vorschläge, wo ich direkt sagte "nein danke!"

    Zitat

    "Ich weiss nicht, bzw kann mit schlecht vorstellen wofür das gut sein soll."


    Auf jeden Fall für Google. Ist doch klar. Du hast mehr Anzeigen auf der Seite, die Klicks bleiben in etwa gleich, je nach Position der Anzeigen, der Klickpreis fällt und das für alle. Der fällt aufgrund der Menge für die oberen Ads und auf Grund der Menge und Position noch viel deutlicher für die unteren Ads..

    Zitat

    Auch dsa Google das vorgeschlagen hat zur "Umsatzsteigerung" kann ich nicht nachvollziehen


    Google sagt nur, dass es möglich ist. Im Kleingedruckten steht aber auch, dass es weniger werden kann. Es gibt Seiten, wo die Tipps von Google funktionieren, habe eine davon. Das ist aber keine dynamische Seite sondern 100% Handarbeit und statisch. Da kann man dann halt auch auf das Wort, den Absatz genau, die Anzeigen platzieren, was bei einem CMS in der Regel ja nicht geht.

    Wenn die Anzeigen dann nur einen Absatz zu hoch oder tief sind, dann kann das 50% der Klicks kosten. So gesehen passt es also schon, wenn Google sagt, 3ten Block einbauen, und man den dann eben auch zielgenau platzieren kann. Und es kommt noch auf die Blöcke an sich an. 3 von den 300x600px, (welcher laut Google zu "den besten gehört") bringt nicht viel, eher weniger. Die Nutzer werden werbeblind. Sehe ich bei mir sehr gut. Habe aber leider keine andere Möglichkeit. Da wo ich anders kann, da sind andere Blöcke eingebaut, kleinere, weniger aufdringlich und die liefern bessere Ergebnisse.

    Anmerkung noch.... Mit am besten laufen bei mir "Linkblöcke" direkt unter der Navigation.

    Und wegen Tests. Muss gerade mal nachsehen, aktuell läuft ja wieder einer seit Wochen. Das Ergebnis kenne ich aber wohl schon.

    Edit: Tests.... Danke schon mal....
    "Fehler
    Derzeit liegt eine technische Störung vor. Bitte versuchen Sie es später erneut."

    Ich glaube, Google weiß warum. Ich soll das Ergebnis nicht sehen und es vergessen.

    Und, Google hat ja schon wieder was neues. Nennt sich "Anzeigen in einem Block mit Contentempfehlungen zulassen (Betafunktion)". Das sind also die Contentempfehlungen, die schon länger als das Wunderwerk vermarktet werden nur, dass da nun auch Werbung von fremden Webseiten drinnen sein kann und das im Layout der fremden Seite.

    Huch, habe mir das eben selbst noch mal angesehen und eigentlich ja.

    "max-width" greift immer. height:auto fehlt, wenn der Platzhalter da ist und kommt erst, wenn das Bild ersetzt wurde. Ohne JS kommt es dann also nie, aber das ist auch egal, denn ohne JS fehlen die Bilder ja auch alle. Dann ist mir das egal, ob die Platzhalter sich anpassen oder nicht.

    Jetzt wäre nur noch die Frage, ob der IE8 das height:auto auch für die normalen Bilder setzt oder die Regel ganz ignoriert. Gut, wenn ganz, dann ist das auch nicht so schlimm. Dann gibt es halt keine Größenanpassung in der Höhe, aber wer so einen alten Browser hat, der ist selbst schuld. Wobei, per IE<9-Hack müsste das ja auch gehen. Dann ruckelt es bei dem zwar, aber nur bei den Lazy-Bildern.

    HTML
    img {
        height: auto\9;
    }

    Auch grad mal geschaut, der Edge kann :not() auch :)

    Echt, Brett vorm Kopf. Da macht man Tage rum, sucht und tut, postet dann und dann fällt einem was ein, was man sich wünscht und stellt fest, dass es das schon gibt.....

    :not() funktioniert ! Dann zuckt es halt im IE < 9, aber das ist mir wirklich egal.

    Aus

    HTML
    img {
      max-width: 100%;
      height: auto;
    }

    wurde einfach

    HTML
    img:not(.b-lazy) {
      max-width: 100%;
      height: auto;
    }
    img.b-loaded {
      max-width: 100%;
      height: auto;
    }

    Muss nur noch rausfinden, ob der IE 8 nun die ganze Anweisung ignoriert oder nur das ":not(.b-lazy)"

    Hm, oder sogar nochmal anders...

    HTML
    img {
      max-width: 100%;
    }
    img:not(.b-lazy) {
      height: auto;
    }
    img.b-loaded {
      height: auto;
    }

    ja das ist eine gute Frage. Irgendwas passt dem da nicht oder interpretiert er falsch. Hängt jedenfalls mit gif; base_64 zusammen (also ohne Unterstrich).

    Als Antwort kommt ja das hier:

    403 Forbidden
    Sorry ***meine IP***, your request cannot be proceeded.
    For security reason, it was blocked and logged.

    If you think that was a mistake, please contact the
    webmaster and enclose the following incident ID:

    [ #3191723 ]


    Keine Ahnung, wer das auslöst, könnte aber durchaus die Firewall sein. Und VB macht aus dem 403 dann einfach einen normalen Fehlerpopup oder ein "ungültige Zeichen im JSON".

    Danke Dir erstmal :)

    Hm, habe ich da nun einen Knoten im Kopf oder kommt das aufs Gleiche raus???

    So wie es jetzt ist, also mit dem "height: auto;" wird das 1x1px ja auf 100x100 hochskaliert. Das gibt ja die Probleme, dass es dann, wenn es ersetzt wird, nur noch die echten 100x75px hat.

    Wenn ich das nun mit "height:1px, width:1px" im IMG-Tag mache, dann kommen doch zwei neue Probleme, oder?

    1. das height="" im IMG-Tag wird ja durch das height:auto; gar nicht beachtet. ich müsste das height:auto hier also auch entfernen. Sobald das height:auto; da ist, kann ich im height="" angeben was ich will, die Höhe wird immer in Abhängigkeit des Formatfaktor berechnet und der Faktor ist eben unterschiedlich. Einmal 4:3, einmal 16:9 etc. und der Platzhalter eben 1:1.

    Da gab es ja mal eine Bug-Meldung, aber anscheinend ist das so gewollt:
    "img {height:auto} is overriding height attribute in <img /> · Issue #1899"

    2. Zusätzlich würde das aber doch auch ergeben, dass die Layoutverschiebung dennoch besteht, oder? Wenn da vorher ein Bild mit 1x1px ist, dann floated der Rest ja ganz anders, und verschiebt sich wieder, wenn das echte 100x75px - Bild kommt. Wäre dann sogar noch schlimmer, weil die Breite auch nicht stimmt, so "verschieben" sich nur ein paar Zeilen, die dann unter das Bild rutschen.

    Sage ja, Knoten im Kopf. Vielleicht habe ich Deine Antwort aber auch falsch verstanden.

    Am einfachsten wäre was wie eine negierte CSS-Klasse, also im Sinne von img {} überall anwenden, aber nicht, wenn img die class="lazy" hat.

    Hm, sehe da was. Gibt es ja: *** Link veraltet ***

    Ich habe keine Ahnung, aber es wird noch seltsamer. Das hier geht.

    Sinnloser Text mit , Komma und Punkt. Hm... data:was für ein Unfug ist das gif; base64 test.

    Alex geht mal her und editiere in diese Zeile,,,, ein Komma rein.

    ^^ ich sagte EIN Komma ;)
    Sorry
    ^^ Ja ist das hier ein Chat oder wie?

    Versuche das mal Alex. Nimm mal meinen Post oben drüber, gehe auf bearbeiten und entferne mal beim roten Text den Unterstrich, so dass das Ding wieder base64 heißt. Gehe dann auf "Vorschau".

    Ja, ist echt komisch, jetzt ging es. Schau mal den Post im Coders Corner an. Oben ist ein HTML-Code mit "data:image/gif;base_64", das war das Problem. Musste base64 mit base_64 ersetzen, dann ging es. Genau genommen lag es an data: gif; base_64, denn nur in der Kombi kamen die Fehler, aber auch nur in dem kompletten Post. Nur den Code wo anders posten geht auch. VB, nene, mit dem Ding werde ich noch kirre.....

    Da wird man ja echt kirre. Wollte eben senden und jetzt ging es hier auch nicht. Dann an der rot markierten Stelle den Unterstrich rein und es geht wieder.

    Hallo zusammen,

    ich frage mal wieder nach was nach. Hänge da irgendwie fest und drehe mich im Kreis.

    Folgendes:

    HTML
    <img class="f_rechts b-lazy" src="data:image/gif;base_64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-src="https://beispiel.rocks/beispiel.rocks/domin /bilder/kunden/6557/hauptbilder/klein/6557.jpg" width="100" height="75" alt="Ansicht Ferienwohnung 6557" />

    Da wird also erst mal ein Platzhalterbild eingebunden (1x1px) und dann per Lazy-Load das eigentlich Bild von data-src nach src verschoben, wenn es im Sichtbereich ist. Das funktioniert auch soweit sehr gut.

    Nur habe ich nun ein Problem mit den Größenangaben direkt beim IMG in Verbindung mit dem Platzhalter und meinem CSS.

    Das

    HTML
    width="100" height="75"

    wird benötigt, ist aber nicht immer gleich. Die Größen sind abhängig vom Bild und können sich leicht variieren, je nachdem ob quer oder hochkannt, 4:3 oder 16:9 oder sonst was.

    So, im CSS habe ich fürs responsitive Layout

    HTML
    img {
      max-width: 100%;
      height: auto;
    }


    Das brauche ich auch, damit sich die Bilder dynamisch an den Platz anpassen und zwar auch in der Höhe.

    Und genau dieses "height: auto;" ist mein Problem. Auto ist zwar der Defaultwert von height, aber sobald das da ist wird die Höhenangabe height="75" im IMG-Tag ignoriert. Das führt nun dazu, dass das Platzhalterbild von 1x1px hochskaliert wird auf 100x100px, was natürlich höher ist als es soll und somit das Layout verschiebt. Sobald dann das echte Bild nachgeladen ist passt wieder alles, denn dort stimmt die Größe dann.

    Umgehen kann ich das nur, wenn ich das "height: auto;" im CSS weg lasse, aber dann funktioniert die automatische Höhenanpassung bei Bildverkleinerung nicht mehr.

    So, was nun tun? Einen einmal gesetzten height-Wert im CSS kann man ja nicht wieder entfernen. "None" oder so gibt es ja nicht und "auto" ist bereits der Standard.

    Ich hasse vBulletin, vor allem das neue Update! Ich kann keine neuen Threads mehr erstellen.

    Wollte gerade was in Codes-Corner erstellen und die "Vorschau" ansehen. Ging nicht, kam die Meldung "Fehler beim Laden der Vorschau". Dachte gut, vielleicht Session abgelaufen oder die Vorschau geht echt nicht. Also alles gelöscht und noch mal neuen Thread erstellt. Dann Ohne Vorschau direkt posten wollen. Geht auch nicht. Meldung: "Fehler beim Speichern des Inhalts: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data"