-
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
DSLR-Forum Fotowettbewerb neu erfunden!
Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen. -
Neuer Partner: AkkuShop.de
Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2024
Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
Thema: "Sprichwörtlich"
Nur noch bis zum 30.04.2024 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang
WERBUNG
E-Mails bei abonniertem Thema
- Themenersteller c_joerg
- Erstellt am
c_joerg
Themenersteller
Da bekomme ich aber im Verhältnis kaum E-Mails...
Ich hatte auch schon mal 6Heute war Rekordtag... 5x
Gast_18092
Guest
Der Zusammenhang ist
Also einfach hier weniger schreiben dann gleicht sich das Verhätnis mit den anderen Foren an.
Kann man machen......
Steht doch im Posting weiter oben. Es ist zwar etwas nervig, aber Du kannst davon ausgehen, das man auf der Fehlersuche ist.
Das Forum wird in der Freizeit, auf eigene Kosten und Risiko des Betreibers betrieben. Wenn der Fehler behoben ist, werden wir das schon merken...
Momentan werden bei mir die Mehrfachmails etwas weniger.
c_joerg
Themenersteller
Neuer Rekord von Mr.Click: 32 in Worten zweiunddreißig!
https://www.dslr-forum.de/showpost.php?p=15891510&postcount=2269
https://www.dslr-forum.de/showpost.php?p=15891510&postcount=2269
Hier irrst du dich. Nach Angaben des Betreibers ist es durchaus als kommerziell zu verstehen. Was aber hier eigentlich egal ist.
So ein Problem kann man nicht so ganz einfach fassen, vor allem wenn es kein reproduzierbarer Fehler ist und dieser in unterschiedlichen Ausprägungen auftritt.
Zuletzt bearbeitet:
Ich wollte damit nur die Erwartungshaltung mancher User auf Störungsfreiheit in diesem für User kostenlosen Angebot unterstreichen.
Nur mal so, damit das Thema nicht untergeht...
Auch ich bekomme immer mehrfache Benachrichtigungsmails. Eine Zeitlang habe ich das mit einem Schulterzucken hingenommen, auch weil es meist bei zwei gleichen Mails blieb. Als es am Sonntag dann 31 pro Nachricht wurden und die ganze Inbox geflutet wurde, habe ich alle Benachrichtigungen gestoppt. Nach einem Versuch heute, für ein Thema wieder Benachrichtigungen einzuschalten, kamen dann gleich wieder zwei gleiche Mails.
Auch ich bekomme immer mehrfache Benachrichtigungsmails. Eine Zeitlang habe ich das mit einem Schulterzucken hingenommen, auch weil es meist bei zwei gleichen Mails blieb. Als es am Sonntag dann 31 pro Nachricht wurden und die ganze Inbox geflutet wurde, habe ich alle Benachrichtigungen gestoppt. Nach einem Versuch heute, für ein Thema wieder Benachrichtigungen einzuschalten, kamen dann gleich wieder zwei gleiche Mails.
Auch ich bekomme Nachrichten mehrfach, manchmal zwei, drei, manchmal fünf mal - manchmal auch dutzendfach.
Was recht neu ist: jetzt bekomme ich auch rückwirkend Benachrichtungen
Heißt: es trudelt plötzlich ein Duplikat einer Benachrichtigung ein, die mir bereits Stunden zuvor zugestellt wurde, und die ich bereits gelesen habe.
Gerade eben zb habe ich ein Duplikat Benachrichtigung für eine neue PM bekommen - mit dem Absendedatum heute 00:02.
Die Verzögerung hat vermutlich nichts direkt mit der Board-Software zu tun, da beide EMails etwa Zeitgleich vermutlich beim EMail-Server des Board-Providers eingegangen sind.
Die Verzögerung fand dann dort statt - es kann natürlich damit zusammenhängen, dass das Forum wegen der Duplikate jetzt mehr emails schickt und deswegen irgendwann gedrosselt wird.
Falls es hilft, hier die Header-Zeilen aus den Emails
Beide EMails liefen über smtprelaypool.ispgateway.de, theoretisch könnte die Verdoppelung auch dort stattfinden.
Die Message-IDs beider Nachrichten sind jedenfalls identisch.
~ Mariosch
Was recht neu ist: jetzt bekomme ich auch rückwirkend Benachrichtungen
Heißt: es trudelt plötzlich ein Duplikat einer Benachrichtigung ein, die mir bereits Stunden zuvor zugestellt wurde, und die ich bereits gelesen habe.
Gerade eben zb habe ich ein Duplikat Benachrichtigung für eine neue PM bekommen - mit dem Absendedatum heute 00:02.
Die Verzögerung hat vermutlich nichts direkt mit der Board-Software zu tun, da beide EMails etwa Zeitgleich vermutlich beim EMail-Server des Board-Providers eingegangen sind.
Die Verzögerung fand dann dort statt - es kann natürlich damit zusammenhängen, dass das Forum wegen der Duplikate jetzt mehr emails schickt und deswegen irgendwann gedrosselt wird.
Falls es hilft, hier die Header-Zeilen aus den Emails
1. Original (kam pünktlich) schrieb:
2. Duplikat (kam 20h später) schrieb:
Beide EMails liefen über smtprelaypool.ispgateway.de, theoretisch könnte die Verdoppelung auch dort stattfinden.
Die Message-IDs beider Nachrichten sind jedenfalls identisch.
~ Mariosch
Ich bekomme auch seit einigen Wochen alle Benachrichtigungen mindestens doppelt, teils noch häufiger.
Aktuelles Besipiel: Heute habe ich per Mail eine Nachricht über den Eingang einer PN erhalten - 14:49 +14:49 + 15:50 - also dreifach. Die letzte PN habe ich aber gestern 9:06 Uhr bekommen - geht immer um den gleichen User als Absender!
Woran kann das liegen?
Aktuelles Besipiel: Heute habe ich per Mail eine Nachricht über den Eingang einer PN erhalten - 14:49 +14:49 + 15:50 - also dreifach. Die letzte PN habe ich aber gestern 9:06 Uhr bekommen - geht immer um den gleichen User als Absender!
Woran kann das liegen?
Zuletzt bearbeitet:
Derlei Probleme sind von fähigen Leuten in einem vertretbaren Zeitrahmen zu identifizieren und dann in der Regel leicht zu beheben. Es gab jedoch seit zwei Monaten dazu keinerlei Auskunft mehr - daher würd ich mal davon ausgehen, dass hier keinerlei Interesse besteht sich der Sache anzunehmen.
Die Mitteilung über Deine Antwort auf meinen Beitrag habe ich dann auch mehrmals per Mail bekommen:
19:57
19:57
21:04
Für den Fall, dass hier ein "Qualifizierter" dem nachgehen möchte ...
Die Mails werden laut Header mehrfach von der VBulletin-Software bei smtprelaypool.ispgateway.de eingeliefert. Von dort werden dann über unterschiedliche Relays (die teils auch in völlig unterschiedlichen IP-Adressbereichen liegen) an die Empfänger-Server geforwardet.
Mögliches Szenario wäre:
Es wird eine Art Cloud-Lösung für das Load-Balancing verwendet, welche dynamisch Instanzen startet/stoppt, je nachdem welche Lasten gerade anliegen bzw. ggf. werden sie nach festem Zeitplan gestartet/gestoppt.
Jede Instanz führt dann für sich die angelegten Cronjobs - darunter dann auch eben jener Cronjob, der die Mails abarbeitet. Je nachdem wieviel Instanzen gerade am Werk sind, bekommt man dann die entsprechende Anzahl an Mails zugesandt.
Mögliches Szenario wäre:
Es wird eine Art Cloud-Lösung für das Load-Balancing verwendet, welche dynamisch Instanzen startet/stoppt, je nachdem welche Lasten gerade anliegen bzw. ggf. werden sie nach festem Zeitplan gestartet/gestoppt.
Jede Instanz führt dann für sich die angelegten Cronjobs - darunter dann auch eben jener Cronjob, der die Mails abarbeitet. Je nachdem wieviel Instanzen gerade am Werk sind, bekommt man dann die entsprechende Anzahl an Mails zugesandt.
Das siehst du falsch. Aber was soll ich machen, wenn ich keine Ahnung habe, wo ich ansetzen soll. Und wenn die Leute im Rechenzentrum mir sagen, sie wissen auch nicht, woran das liegt, muss ich denen glauben, denn mehr Ahnung als die habe ich ganz sicher nicht.
Danke. Ich gebe das morgen mal weiter. Vielleicht hilft das den Kundigen ja, dir Ursache zu finden.
Bist du dir da sicher?
Ich hab nur Stichprobenartig in die E-Mails reingeguckt - vorhin kam zb wieder mal eine Benachrichtigung 11x zeitgleich an.
Im Quelltext der Mails finde ich keine Zeile bzgl des Einliefern von VBulletin bei smtprelaypool.ispgateway.de.
Die erste Received-Zeile, die ich sehe, ist die Einlieferung der EMails an den jeweilige Relay-Server (smtprelay<XY>.ispgateway.de) - übergeben von smtprelaypool.ispgateway.de
Vielleicht übersehe ich eine Zeile, in der die Einlieferung bei smtprelaypool.ispgateway.de dokumentiert ist? Falls ja, wäre es nett, wenn du die konkrete Header-Zeile hier kurz zitieren könntest.
@Scorpio: es wäre interessant und ggf der Fehlereingrenzung dienlich, wenn du ggf Details zur EMail-Anbindung durch vBulletin hier nennen könntest - konkret, wie werden die eMails an den Server übergeben? mail()? Sendmail? SMTP?
Für mich sieht es so aus, als wenn vBulletin die EMail nicht via SMTP, sondern vermutlich über sendmail oder direkt über die interne PHP Mail-Funktionen (die letztlich auch über sendmail laufen) rausschickt.
Was ich derzeit nicht nachvollziehen kann, ist wie die EMail vom Webserver zu smtprelaypool.ispgateway.de gelangt.
Müßten sich dann nicht die Message-IDs unterscheiden? Tut sie aber nicht, alle Duplikate haben die gleiche
vBulletin ist leider nicht Open Source, damit ist der SourceCode etwas schwer aufzutreiben.
Ich habe was im Internet gefunden, was nach dem Source Code der v4.2.2 Version aussieht, dort wurde die MessageID von vBulletin selbst generiert, und zwar nach dem Schema:
Da steckt also die Zeit auf die Mikrosekunde mit drin - wenn das mehrere Cron-Instanzen wären, dann müßten die auf die Mikrosekunde genau synchronisiert sein und auch alle wirklich zeitgleich die EMail generieren, was ziemlich unwahrscheinlich ist.
Voraussetzung ist natürlich, dass das wirklich der SourceCode von vBulletin 4.2.2 war, den ich gefunden habe, und das die (ältere) vBulletin Version des Forums das nicht doch anders macht (das Format würde aber passen).
Damit blieben meiner Meinung nach als mögliche Übeltäter der relaypool oder das was-auch-immer die EMails zwischen dem / den Webservern und dem relaypool transportiert....
~ Mariosch
Code:
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13])
by mein.mailserv.er with ESMTPS id 07JJTuF9011548
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
for <meine@mailadresse.de>; Wed, 19 Aug 2020 21:29:57 +0200 (CEST)
(envelope-from noreply@dslr-forum.de)
Received: from [85.236.41.132] (helo=smtprelaypool.ispgateway.de)
by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.92.3)
(envelope-from <noreply@dslr-forum.de>)
id 1k8TmS-0000Eg-Kv
for harald@netmini.de; Wed, 19 Aug 2020 21:29:52 +0200Bzgl. der Mail-IDs:
Kommt drauf an, wie die Benachrichtigung von vorn bis hinten implementiert ist. Wird die Mail z.B. mit allen Metadaten erst erzeugt, gespeichert und später von einen Cronjob nur noch versendet, könnte so etwas durchaus entstehen.
Ansonsten:
Ist natürlich nur ein von mir kurz erdachtes Szenario wie es aussehen könnte. Die Tatsache dass es offenbar bei manchen Leuten schon zu bis zu 30 Mails gekommen ist, lässt mich auch etwas daran zweifeln. Das müsste schon eine extreme Lastspitze gewesen sein, damit das System derart viele Instanzen cloned. Andererseits scheint das Problem ja seit dem Umzug auf einen neuen Load-Balancer entstanden zu sein. Dadurch wäre es recht naheliegend dass es damit zu tun hat.
Frage die bei mir hier entsteht: War vorher auch ein Load-Balancing vorhanden mit dem es die Probleme noch nicht gab? Oder ist es an dem Stichtag erstmalig eingesetzt worden?
Wie Vbulletin mit den Benachrichtigungen verfährt müsste man halt wirklich im Code sehen. Habe allerdings die Befürchtung, dass der installierte Code ggf. geschreddert ist, da es ja Closed-Source ist und da wird der Code für die Kunden oft mit verschiedensten Techniken unleserlich gemacht.
Was mich nebenbei etwas wundert:
Braucht es tatsächlich Load-Balancing? Die Nutzerzahlen von Foren wie diesen sind seit einigen Jahren stark rückläufig. Gleichzeitig kann man heute eine Single-Server heute mit beinah aberwitzigen Leistungsdaten haben.
Problem ist häufig - wenn Webseiten zäh werden, wird oft einfach ein dickerer Server genommen, aber PHP/MySql und Konsorten dann mit ungeänderten Konfigurationen betrieben, die die Hardware nicht ansatzweise ausnutzen um am Ende schafft der 3mal so dicke Server kaum mehr weil der Leistungszuwachs nur durch die zügigere Abbarbeitung einer schnelleren CPU zustandekommt. 64GB Ram nützen nichts, wenn der Webserver dann nicht mehr als 32 Threads startet um möglichst viele gleichzeitige Requests bedienen zu können. RAM lässt sich aber auch sparen, indem man Webserver und PHP nur mit den nötigen Modulen kompiliert und startet. Da würden sich manche wundern, was ein Server mit 8GB wegpacken kann, wenn man zielgenau konfiguriert.
Häufiges Problem ist auch die Blockierung von Threads durch zu lange Keep-Alive-Timeouts. Das ist relativ doof - die Standardeinstellung ist häufig 5s. In dieser Zeit wird nach dem vollständigen Laden einer Seite aber oft nicht weitergeklickt - dennoch wurde auf dem Server der Thread für die Zeit blockiert. 1s reicht völlig um alle Resourcen einer Seite möglichst ohne neuen Verbindungsaufbau zu laden und danach steht der Thread direkt neu zur Verfügung.
Und zum Schluss noch:
Durch die veraltete VBulletin-Version muss scheinbar ein Uralt-PHP 5.3 eingesetzt werden. Allein PHP hat im Vergleich zu dieser alten Version derart an Performance zugelegt, dass ein Upgrade wohl deutlich spürbare Entlastung bringen würde.
HTTP2 wird auch nicht genutzt... der technische Stand ist leider von Vor-Vorgestern...
Vom Gefühl her würd ich sagen, dass das Problem nicht dadurch entsteht ob der mail()-Befehl, eine SMTP-Implementierung oder ein anderweitig gebauter sendmail-Aufruf verwendet wird.
Es geht vermutlich eher darum wie das insgesamt gehandled wird.
Sehr unwahrscheinlich ist dabei, dass direkt beim POST-Request an 'newreplay.php' die Mails an die Abonnenten versandt werden.
Schon eher möglich ist, dass 'newreplay.php' zwar die Abonnenten ermittelt und gleich in eine DB schreibt. Ein regelmässig aufgeführter Cronjob liest die dann aus und arbeitet diese ab.
Oder aber 'newreply.php' kümmert sich darum noch gar nicht, sondern ein Cronjob ermittelt welche Abonnenten informiert werden müssen und versendet dann entweder direkt oder schreibt auch erst wieder in eine DB die dann wiederum ein weiterer Cronjob abarbeitet.
Es geht vermutlich eher darum wie das insgesamt gehandled wird.
Sehr unwahrscheinlich ist dabei, dass direkt beim POST-Request an 'newreplay.php' die Mails an die Abonnenten versandt werden.
Schon eher möglich ist, dass 'newreplay.php' zwar die Abonnenten ermittelt und gleich in eine DB schreibt. Ein regelmässig aufgeführter Cronjob liest die dann aus und arbeitet diese ab.
Oder aber 'newreply.php' kümmert sich darum noch gar nicht, sondern ein Cronjob ermittelt welche Abonnenten informiert werden müssen und versendet dann entweder direkt oder schreibt auch erst wieder in eine DB die dann wiederum ein weiterer Cronjob abarbeitet.
Da sehe ich eine Empfangsbestätigung von main.mailserv.er, dass smtprelay01.ispgateway.de eine Email eingeliefert hat, sowie 5 Sekunden davor die Einlieferungsbestätigung von smtprelay01.ispgateway.de, übergeben von smtprelaypool.ispgateway.de.
Was ich da nicht sehe, ist wie die E-Mail bei smtprelaypool.ispgateway.de gelandet ist.
Das wundert mich etwas.
Verdiene mein Geld ja selber im Bereich Webanwendungen und habe mal nachgeguckt, wie die Header der EMails so aussehen, die von unseren Servern verschickt werden.
In allen finde ich als ersten Eintrag sowas wie:
Received: by lokaler.server.name (Postfix, from userid 33)
Die Webanwendung nutzt dabei die eingebaute mail() Funktion von PHP und übergibt die Mails an einen lokalen Postfix, der dass ganze dann an den zentralen E-Mailserver weiterreicht.
Auf meinem lokalen Entwicklungs-PC werden die EMails dagegen direkt aus PHP via SMTP verschickt, dann findet sich da immer so eine Zeile in der Email:
Received: from localhost (provider.url [ipadresse])
by zentraler.email.server (Postfix) with ESMTPSA id xyz
for <empfaenger@email.adresse>; Fri, 14 Aug 2020 15:58:17 +0200 (CEST)
Sowas vermisse ich bei den DSLR-Forum Emails, was mich echt wundert - aber es kann natürlich sein, dass ein nicht-Postfix-Mailserver die Received-Zeilen für die Einlieferung anders handhabt...
ich hab nochmal den gefundenen Sourcecode durchgeguckt - in der Tat gibt es da auch eine Queue, in der EMails statt versendet zu werden, komplett mit Headern in die DB abgelegt werden, zum späteten Versenden via Cronjob.
Wenn du interessiert bist, schicke ich dir gerne den Link zu den Sourcen, die ich gefunden habe.
Es handelt sich auch nicht um irgendwelche zwielichten Seiten, die liegen auf github.com
Ich vermute allerdings, dass die dort eigentlich gar nicht öffentlich zugänglich sein sollten.
Damit am Ende nicht noch das Forum wegen einem Link auf die Sourcen Ärger kriegt, verzichte ich lieber aufs öffentliche Posten.
Darauf deutet es hin, nachdem ich nochmal durch die Sourcen bin.
newreplay.php ruft die wohl die Funktion build_new_post() in functions_newpost.php auf, welche sich um das verifizieren und speichern des neuen Beitrags kümmert und dann die Funktion exec_send_notification() in der gleichen Datei aufruft.
In dieser wird vbmail_start() aufgerufen, was im Hintergrund die MailQueue aktiviert und dafür sorgt, dass die einzelnen vbmail() aufrufe statt direkt versendet zu werden, in der DB landen.
Jedenfalls dann, wenn das in der Config aktiviert ist, was ich natürlich aus der Entfernung nicht sagen kann - ist aber anzunehmen.
Beim Versenden der MailQueue (aufgerufen durch einen Cronjob) fordert das Script allerdings zuerst einen Write-Lock auf der Mailqueue Tabelle an - sofern das konfiguriert ist.
Unter der Annahme, dass dem so ist, sollte es eigentlich auch unmöglich sein, dass der Cronjob auf mehreren Instanzen gleichzeitig aktiv wird und dieselbe eMail mehrfach verschickt...
Aber natürlich basiert meine Vermutung auf vB 4.2.2, während das Forum auf vB 3.8.7 läuft, vielleicht fehlenen in der Version noch solche Features...
~ Mariosch
WERBUNG