Beiträge von riawie

Da kann auch keine Regel greifen.

Wie ich bereits schrieb:

"Das was Du möchtest ist nur dann möglich wenn Du nicht mehr an Termine erinnert werden möchtest."

Ich kann nicht sicher sagen wo die Dateien aus dem Chat gespeichert werden, aber die eigentlichen Chat Nachrichten werden auf jeden Fall nicht im Dateisystem, sondern in einer SQL Datenbank auf dem David Server gespeichert. Ohne das jetzt geprüft zu haben würde ich davon ausgehen das dort auch die im Chat versendeten Dateien in Form von Blobs gespeichert sind.

Bei David funktioniert die Erinnerung an Termine schon immer so das zum Zeitpunkt der Erinnerung etwas das aussieht wie eine Mail in den Eingang gestellt wird.
Wenn man diese "eMail" im Eingang abstellt erhält man anschließend weder im David Client noch am Smartphone eine Erinnerung an den Termin.

Mit anderen Worten:

Das was Du möchtest ist nur dann möglich wenn Du nicht mehr an Termine erinnert werden möchtest.

Diese Fragestellung wurde in vielen Jahren schon unzähliche Male erörtert und das Ergebnis war stets das gleiche

na, mal gut das der nicht mit der shift Taste umzugehen wusste

Zitat von wlconsult

Allerdings ist das bei den mit der Rundesendefunktion versendeten Emails offenbar nicht so: Diese haben im Ausgang alle einen scharzen Betreff. Hier war TOBIT offenbar nicht ganz konsequent in der Umsetzung.

kurios

Wobei ich sagen muss das die Rundsendefunktion mit Rundsendesteuerdatei hier eh nicht genutzt wird und meine Aussage dazu aus der Erinnerung stammt, wo ich das mal getestet hatte, aber das war irgendwann im letzten Jahr.

So oder so denke ich das Tobis nachbessern sollte was die Möglichkeit angeht Nachrichten mit leerem AN: Feld zu versenden sobald mindestens eine Adresse im CC oder BCC steht oder über Rundsendedatei versendet wird.

Allerdings werde ich als einfacher Kunde die Welle bei denen nicht lostreten, zumal wir hier gar keine Probleme damit haben da eh alle korrekt geschult sind und Massenmailings per Rundsendedatei nicht zu unserem Geschäftsmodell gehören.

wlconsult im Ausgang, CC und BCC Empfänger haben eine blaue Betreffzeile, AN: Empfänger eine schwarze. und ich kann in den Client Einstellungen nichts finden was das beeinflussen könnte.

Im Eingang ist es auch so das wenn ich Nachrichten nur in CC erhalte sie ebenfalls eine blaue Betreffzeile haben, macht ja auch Sinn, schließlich ist die Nachricht ja dann für mich mit hoher Wahrscheinlichkeit weniger wichtig wenn ich sie also nur zur Kenntnis bekomme und nicht als Hauptbeteiligter der vielleicht auch antworten soll, oder so halt

wlconsult nun ja, anhand der Farbe der Betreffs kann man aber schon sehen das die eMail Adressen gar nicht im An Feld stehen sondern im CC oder BCC Feld. Ja, ich weiß, eine weitere Farbe zur Unterscheidung von CC und BCC wäre schön

Davon abgesehen gehört es halt zur Anwenderschulung das bei Rundsendeaufträgen oder solchen an einen Adressordner im BCC: Feld immer ein gültiger eigener Empfänger ins An: Feld gehört und ebenso wie der Ausgangsordner funktioniert, also das dort je Empfänger einer Nachricht eine Zeile zu finden ist, dieses aber nicht bedeutet das dort z.B. bei 10 Empfängern wirklich 10 individuelle Nachrichten rausgesendet werden.

Prinzipiell sollte das allerdings wie weiter oben im Thread schon geschrieben vom David Client abgefangen werden und bei fehlender eMail Adresse im An: Feld ein entsprechender Hinweis, idealer Weise mit Autokorrekturangebot kommen.

Nein!

Steht auch im Handbuch welches Du in dem Fall im David Administrator durch Klick auf das eingekreiste Fragezeichen in der Menüleiste erreichst.
Dort einfach mal Indizierung in das Suchfeld eintippen und alles wird genau erklärt

Weil Regeln immer nur bei automatisch in den Eingang laufenden Mails greifen.

Steht so auch im Handbuch

Hinweis: Deine heutigen Fragen haben sich alle mit "F1" beantworten lassen

Vielleicht mal über eine Schulung bei Tobit nachdenken?

- Im David Client
- <Alt> + <o>

- "Einstellungen"

- links das ">" vor "Global" klicken

- links "Outdated" anklicken
- rechts den obersten Haken bei "konventionelle Suchfunktion anstatt der Datenbank-Suche" setzen

- Fenster mit "OK" schließen

Zukünftig dann in vollen Ordnern beim Suchen Zeit mitbringen und vielleicht ein Käffchen hohlen gehen

- rechtsklick auf den Eingangsordner
- aus dem Kontextmenü "Regeln" auswählen
- rechts auf hinzufügen klicken
- den Punkt vor "Weiterleiten und XMedia" setzen
- unten den Haken bei "Regel generell anwenden" setzen
- Weiter

- auf die Karteikarte Weiterleiten klicken
- bei "Weiterleiten an" das Ziel eintragen
- bei "Weiterleiten als" "eMail" auswählen
- bei Includedateien "Nach" rechts daneben auf das Blatt mit dem Plus klicken
- oben auf Neu klicken
- in dem Feld Betreff dieser Include einen passenden Namen geben wie z.B. "Weiterleiten als xxx@xxx.xx"
- Im Textfeld muss nun mindestens folgender David @@ Befehl eingetragen werden:
@@VON xxx@xxx.xx"@@
wobei natürlich die korrekte gewünschte Absenderadresse zu verwenden ist.
- oben "Speichern" klicken
- oben "Einfügen und schließen" klicken
- "Fertigstellen" klicken
- Dialog mit "OK" schließen

Fertig

complusit eine Hand wäscht die andere und ich war selbst schon oft der dem geholfen wurde.
Wenn ich also gerade die Zeit für sowas finde mach ich das stets gerne so ich helfen kann

Zitat von complusit

Ob man dies jetzt - so wie von riawie oder tab-soft getan - als Anlass nehmen muss seine eigene Person mit ironischen Posts über andere Forumsteilnehmer zu erheben, steht dabei auf einem ganz anderen Blatt. Wäre zumindest nicht mein Style.

complusit sorry, aber gerade diesen Eindruck wollte ich nicht erwecken.

Dennoch erwarte ich von IT Dienstleistern das sie zumindest die Basiscs der eMail betreffenden RFCs kennen und daher wissen das eMails nur dann RFC Konform sind wenn sie einen To: Header enthalten, was nun mal bedingt das bei deutschsprachigen eMail Clients das An: Feld zwingend auszufüllen ist um RFC Konforme eMails zu versenden welche anschließend nicht nur allein deswegen irgendwo auf dem Transportweg hängen bleiben oder zurückgewiesen werden.

Eine Zurückweisung der Mails ist übrigens noch der moderne freundliche Umgang damit, früher hat man derart fehlerhafte Mails schlicht stillschweigend verfallen lassen und nicht weiterbefördert.

Mir persönlich ist bewusst das der Otto Normal Bürger, und entsprechend auch die Masse der eMail Nutzer sich um solche technischen Details weder scheren noch des bezüglich fortbilden wollen nur um eMails verschicken zu können.
Entsprechend erwarte ich von eMail Clients sowie von Webmail Benutzeroberflächen das sie den Anwender auf solche Fehler hinweisen wenn sie passieren.

Da mir selbst allerdings eben aufgrund meines Wissen nie in den Sinn käme eine eMail an mehrere BCC Empfänger ohne einen Empfänger im An: bzw. To: Feld zu versenden habe ich sowas ewig nicht mehr getestet. Das muss locker schon 20 Jahre her sein das ich zuletzt bewusst und absichtlich MUAs auf RFC konformes Verhalten getestet habe. Seit dieser Zeit bin ich auch nie wieder bewusst über einen MUA gestolpert der diese Art von Anwenderfehler nicht abfängt.

Entsprechend bin ich zu Beginn dieses Threads und auch des thematisch ähnlichen von neulich zum Thema eMail Versand über IONOS als direkter IONOS Kunde nicht auf die Idee gekommen zu fragen ob bei den problematischen Mails eine gültige eMail Adresse im An: Feld steht.

Künftig werde ich sowas wohl mit Wissen um die David Schwachstelle wieder explizit abfragen müssen wenn ich sachdienlich und schnell helfen können möchte

Zitat von TAB-Soft

Dann sollte man sich mal die postman,.ini anschauen, dort kann man es nähmlich einstellen

Und das habe ich auch schon mal hier gepostet.

"https://www.david-forum.de/forum/thread/13619-cc-empf%C3%A4nger-sehen-sich-nicht-gegenseitig/?postID=70530#post70530"

Also, mal besser den Ball flach halten

PS. ganz vergessen "wer lesen kann, ist klar im Vorteil"

Sorry, aber mal abgesehen davon das die Einstellung Irrsinn ist wenn man sie vornimmt) hat sie nichts mit dem hier beobachteten Problem zu tun und hilft auch nicht es tatsächlich zu lösen.

Denn wenn man diese Einstellung vornimmt geht "jede" Mail welche an mehrere Empfänger gesendet wird individuell raus, nicht nur solche welche einzig an BCC Empfänger gehen wo das durchaus beabsichtigt geglaubt werden könnte.
Das bedeutet dann aber auch das man sich nicht mehr mit mehreren Leuten gleichzeitig über eMail unterhalten kann, denn keiner der Empfänger weiß mehr von den anderen Empfängern und gerade CC Empfänger werden ermuntert zu glauben die jeweilige Mail nicht nur in Kopie, sondern exclusiv bekommen zu haben, sie also im Zweifel gar beantworten zu sollen.
Doch selbst bei den BCC Empfängern wird mit dieser einstellung ein falscher Eindruck erzeugt.

Der einzig richtige Weg zur Behandlung des "Problems" wäre das Tobit im David Client erzwingt das man einen Empfänger ins "An" Feld einträgt, so das der Postman einen RFC konformen To: Header erzeugen kann. Gerne dann auch noch mit einer Konfigurationsoption das der Client dieses für den Nutzer übernimmt der nicht dran denkt und von mir aus auch noch konfigurabel um so vorgaben wie "To: nondisclosedrecipients@domain.tld" oder ähnlich, ganz wie es dem Betreiber des Systems belieben mag.

Derartige Konfigurationsmöglichkeiten gibt es derzeit aber nicht, weder in der David Client Konfiguration, noch in der Postman.ini in welche sie in dem Fall klar nicht gehören.

Im übrigen kann man sein Erstaunen über die Art von Fehlern welche Anwender so aus Unkenntnis heraus machen auch freundlicher ausdrücken

Zitat von complusit

Kann sein, jedoch hat das unser Kundenkreis wohl so nicht verinnerlicht gehabt.

Zumindest Ihr als Dienstleister in der Branche hättet das aber wissen können und auch sollen und den Kunden im Zweifel Licht ans Fahrrad machen das eine versandte Mail ohne wenigstens einen Empfänger im An: Feld schlicht nicht Standard Konform ist und daher eben im Zweifel erst zu prüfen ist was passiert wenn man diesen Bediener-Fehler abstellt

PS: und ja, irgendwer könnte diesen Fehler mal bei Tobit melden, denn die sollten ihren Mail User Agents beibringen das sie Mails ohne Empfänger im An: Feld nicht zum Versand akzeptieren dürfen.
Gern auch mit Abfrage ob wenn sonst einzig BCC Empfänger drin stehen die eigene Mail Adresse verwendet werden soll, oder eben eine andere...
Aber hey, ich werde das nicht als Bug melden, denn ich halte es für unproblematisch

complusit David verhält sich - so lang der Haken bei eMail Rundsendung gesetzt ist - zu 99% Standardkonform.

Das 1% rührt daher das Mails welche gar keinen Empfänger im Feld An: stehen haben allerdings nie zum Versand angenommen werden dürften

Wenn der Haken bei eMail Rundsendung nicht gesetzt ist verhält sich David nur noch zu etwa 95% Standardkonform, die Abweichung ist dann allerdings durch den Nutzer so gewollt - wenngleich er selbst z.B. durch seinen Provider (IONOS) dazu gezwungen wird - und kann daher Tobit nicht angelastet werden.

Eigentlich muss der Haken bei eMail Rundsendung am Postman Port auch nur bei direkten IONOS Kunden gelöscht werden.

PS: das jemand eine Mail ohne einen einzigen Empfänger im An: Feld verschicken wollen würde kam mir bislang nicht in den Sinn. bei Massenmailings ist es international üblich die Adresse des Absenders, oder wenn es sich um eine öffentliche Mailingliste handelt die der Mailingliste dort einzutragen (bei verdecken Listen natürlich nicht, sondern weider die des Absenders )

wulff Ihr sitzt - in Bezug auf diesen Thread - hier aber auf der anderen Seite vom Tisch

Eigentlich wärt Ihr damit genau die welche sich mal bei IONOS beschweren könnten und sollten, denn Ihr habt hier als einziges ne direkte Vertragsbeziehung mit dem Laden.
Alle anderen hier im Thread möchten nur unter anderem auch IONOS Kunden per eMail erreichen können

Was ich ja nett finde ist das IONOS wenigstens beide Seiten gleich schlecht behandelt

NoHopeNoFear naja, das ganze ist letztlich ein ziemlich komplexes Ding, im Grunde macht IONOS ja nichts anderes als alle anderen auch, nur mit sehr sehr geringen Toleranzen und zum Teil auch mit irrsinnigen Parametern, wie z.B. ob BCC in der Mail verwendet wird. Soll heißen da gibt es eine Liste von Bedingungen, jede davon addiert wenn sie erfüllt ist eine gewisse anzahl von Punkten auf das Konto der jeweiligen Mail und wenn dann zu viele auf dem Konto stehen wird die Mail nicht angenommen.

Am Ende bekommt man nie eine ganze Liste der Dinge welche an der konkreten Mail bemängelt werden.

Wenn es aber bei einem Eurer Kunden nur einen speziellen Nutzer betrifft darfst Du schon mal schlicht davon ausgehen das seine Absenderadresse bereits zu viele negative Punkte bei IONOS gesammelt hat.
Da mag jede einzelne Mail von der Beschaffenheit her gerade noch o.k. sein und das Fass nicht sofort zum überlaufen bringen. Der Umstand das er zu oft welche schickt welche das Fass nur gerade eben nicht zum überlaufen bringen (und das kann durchaus auch unterschiedliche Empfänger betreffen) triggert dann aber halt doch den Filter.

Im Grunde kannst Du da nur den oben auch schon geposteten Support Link nehmen und Dir alles was da sonst so als Zurückweisungsgründe genannt wird anschauen um zu sehen das die Mails des Kunden so wenig wie möglich von den da aufgeführten möglichen Parametern triggern.

Im Zweifel kann man zum durchbrechen solcher Ketten übrigens auch mal einen einzelnen Absender im David via Sende Methode auf smarthost für das Ziel verbiegen, oder eben umgekehrt nur den einen Absender auf nur das eine Ziel auf Direktzustellung, je nach dem was da standard in der Installation ist

Ich weiß, das ist wenig befriedigend, aber am Ende verraten Dir gerade die Admins der Freehoster eh nicht was sie da im SPAM-Filter wie gewichten und wir werden es von außen nicht wirklich herausfinden.

PS: das ich es jeweils so ausführlich beschreibe soll vor allem den Mitlesern dienen deren Kenntnissstand wir ja nicht kennen
Diese Probleme mit IONOS aka Web.de bzw. GMX haben ja recht viele zur Zeit...

NoHopeNoFear ist definitiv ein Problem was auf Seiten von IONOS (GMX / Web.de) zu verantworten ist und in freidrehenden Mail Server Admins auf einem Feldzug gegen SPAM begründet liegt.

Einzige Abhilfe ist derzeit auf dem David Server die eMail Rundsendung zu deaktivieren:

Im David Administrator: David \ System \ Ports > David Postman > Eigenschaften > Dienste > eMail-Rundsendung

Allerdings ist das dann ein Verstoß gegen gängige RFC und man muss damit rechnen im Einzelfall bei verschiedenen anderen Providern dafür abgestraft zu werden wenn man deswegen 5 einzelne eMails für 5 Empfänger einliefert.

Der Haken wirkt sich auch nicht nur auf BCC Empfänger, sondern auf alle Empfängerfelder.
Sobald der Haken nicht mehr gesetzt ist jagt der David für jeden Empfänger einer eMail eine einzelne Mail raus, auch wenn er die nicht direkt sondern über Smarthost zustellen soll.

Das genaue Verhalten und was dazu in den RFCs - welche ja im Grunde die Gesetze des Internet sind - steht zu erklären würde hier aber den Rahmen sprengen.

Nur kurz so viel dazu:
Bei gesetztem Haken schickt der David Server jede eMail mit mehreren Adressen welche über smarthost ausgeliefert wird als eine Mail mit einer Empfängerliste im SMTP Envelope auf die Reise. Der smarthost guckt dann für welche Empfänger dieser Mail er eine Kopie an welchen Server auf die Reise schicken muss und wenn mehrere davon auf einem Zielserver zu Hause sind, oder über einen gemeinsamen Weiterleitungsserver erreicht werden schickt er die auch wieder als eine Mail gebündelt mit einer Liste im SMTP Envelope weiter. Der nächste Server macht dann das gleiche, so lang bis die Empfänger erreicht sind.

Ist der Haken nicht gesetzt schickt der David Server jede eMail für jeden Empfänger einzeln mit genau nur dieser einen eMail Adresse im SMTP Envelope auf die Reise und der Smarthost leitet die dann auch so 1 zu 1 weiter an den nächsten Server auf dem Weg zum Ziel weiter.

Im ersten Fall werden die Transportwege zwischen den beteiligten Servern so effizient wie möglich genutzt und auch die Zielmailserver haben so wenig wie möglich mit diesen Mails zu tun, auch wenn viele ihrer Nutzer eine Kopie der Mail erhalten sollen. Im zweiten Fall erfolgt die Übertragung so ineffizient wie maximal möglich und alle beteiligten Server haben den maximal möglichen Aufwand mit jeder einzelnen Mail.

In Beiden Fällen haben alle Kopien der eMail die gleiche Message ID, prinzipiell können also Zielserver die Kopien für mehr als einen Nutzer erhalten also die Duplikate sehr leicht erkennen und den Absender dafür abstrafen...

Ich habe für unseren Mailserver ganz bewusst entschieden den Haken auf keinen Fall zu löschen, denn wenn ich das mache kommen unsere Mails bei wichtigen Kunden nicht mehr an weil deren Mailserver uns berechtigt für das nutzen von SPAM Methoden abstrafen.

Wer hier Mails an mehrere GMX oder Web.de Adressen schicken will muss die so sie nicht alle im An Feld stehen dürfen einzeln raussenden.

complusit GMX und Web.de gehören zu IONOS und die Server werden auch beide vom gleichen Team betrieben, dort scheint es einen Admin zu geben welcher bei der Konfiguration und Pflege der SPAM Filter Einstellungen ziemlich frei dreht.
Ich hab immer wieder mit solchen Bratpfannen von Admins zu tun und muss mir schon seit Jahren immer mal wieder nen Kopf drum machen wie ich deren jeweilige Kopfkrämpfe umschiffe
In manchen Fällen hab ich gar schon bei den jeweiligen Providern kostenlose Accounts geklickt um dort Mails nach Anmeldung einzutüten.
Wichtig ist halt das man versteht wo das Problem an sich liegt und nicht versucht wie arnes es dem völlig falschen Beteiligten anzuhängen, denn dann bekommt man das nie gelöst :o

Im Fall von Strato ist es so das unterschiedliche Kunden zum Teil von unterschiedlichen Mailservern versorgt werden, die Zuordnung ist zwar eigentlich dynamisch, aber doch eher träge, so das es also passieren kann das mails von einem Kunden bei Auslieferung über smarthost immer von der gleichen IP beim eigentlichen Ziel eingeliefert werden, während das bei einem anderen Kunden immer eine andere IP ist.

Wenn nun einer der beiden Kunden sich die Smarthost IP mit einem SPAM Versender teilt kann es entsprechend sein das der eine Kunde nichts mehr an IONOS senden kann, während es der andere mit identischen eigenen Einstellungen weiterhin ohne Probleme kann.

In solchen Fällen sollte man sich als Strato Kunde mit der Fehlermeldung an Strato wenden damit die ihre Mailserver IP von der SPAM Liste runter bekommen.
Bis das passiert ist kann man versuchen das ganze mittels Sende Methode und Direktzustellung zu umschiffen. Diese Umschiffung wird aber halt nur dann klappen wenn der eigene Internetanschluss die dafür notwendigen Voraussetzungen erfüllt