Ich kann nicht E-Mails an GMX/WEB senden

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

Nun kann ich es wohl auch nachvollziehen, woher bei uns die Übertragungsfehler wohl resultieren mögen. Denn auch bei uns (auch bei mir...) werden durchaus Mails ohne AN-Empfänger versandt. Wenn z. B. Händleranfragen rausgehen, sollen z. B: nicht alle anderen wissen, wer mit im Boot ist....

Dass es dann am fehlenden AN lag, wäre ich niemals drauf gekommen....

Werde ich mal beobachten, weil es kommt garantiert mehrmals die Woche vor, dass wir solche Anfragen versenden. Aber nur sehr selten diese Problematik....

Danke für die Infos!

Es ist doch wirklich unfassbar was Leute in der EDV so alles zu Tage bringen

Wer verschickt den Briefpost ohne "AN" Adressaten, ich jedenfalls nicht

Und wer sich die Logfiles mal richtig anschaut findet auch den Fehler

Aber "riawie" hat es ja auf den Punkt gebracht, nun sollten es wohl alles jetzt geschnallt haben.

wünsche ein schönes Wochenende

Die Frage ist doch eher: Warum nimmt sich ein großer Provider die Freiheit, solche Mails automatisch nicht zuzustellen, statt lediglich den SPAM-Score zu erhöhen und dem Empfänger die Entscheidung zu überlassen? Das AN:-Feld leer zu lassen halte ich für ein verzeihliches Versehen, zumal mWn weder Outlook noch David den Absender über seinen Fauxpas informieren. Zumindest kann ich nachvollziehen, dass ein normaler Anwender so denkt: Von den Empfängern soll niemand einen anderen Empfänger sehen können, also bleibt das AN:-Feld leer und alle kommen in BCC:. Von Admin-Seite kann man das anders sehen, aber als Anwender muss man sich eigentlich nicht mit RFCs, Headern etc. herumschlagen - und das ist auch gut und richtig so.

Danke Nordtech, gerade wollte ich gegen TAB-Soft lospoltern...

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"

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

So, dann mal zum Schluß:

Ich habe in keiner Schulung von Tobit gesehen, gelernt, dass Emails ohne "AN" geschrieben oder versendet werden.

Genau so wenig versende ich meine Briefpost ohne Adressaten

Und ich könnte mir vorstellen, dass die Provider jetzt so langsam auf solche Unart reagieren.

Nach dem Motto aus dem Leben, ein par machen etwas falsch und alle müssen daruter leiden.

Da ich bei meinen Kunden auch die User betreue, ist dort auch noch niemand auf die Idee ggekommen solche

Email´s zu erstellen, geschweige denn so zu versenden.

Bei mir und meinen Kunden ist das Problem bis jetzt nicht auf getaucht (IONOS Kunde(n))

PS. Ich sende mit "AN" und "CC" und wenn der Bedarf besteht, mit Verteilerliste ...

Nett sein kann ich natürlich auch

Für mich ist dass Thema damit druch.

Zitat von riawie

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.

Das sehe ich auch so wie riawie. Und es ist ja auch nicht jeder User, der Tobit im Alltag benutzt in Ahaus geschult worden. Die allermeisten werden ja noch nicht mal durch das Systemhaus in die Benutzung eingewiesen.

Also wir halten fest: Bislang brauchte man das AN Feld bei IONOS nicht auszufüllen - ab jetzt muss man es tun. Das hat eben zu der Verwirrung jedenfalls von einigen unserer Kunden geführt. Es wäre schön, wenn Tobit hier nachbessern könnte, so dass so ein Fauxpas dem User gar nicht mehr unterkommen kann.

Und ehrlich gesagt: Ich hatte es erst mal auch nicht auf dem Schirm, dass unsere Kunden das AN Feld nicht ausgefüllt hatten, als wir die Fehlerbeschreibung reinbekamen.

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.

Kollegiale Grüße an alle!

Oliver

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

riawie

Nur damit das auch meinerseits klargestellt ist: Ich finde deinen Einsatz hier echt toll und möchte auch mal explizit Danke sagen! Es ist sicher nicht selbstverständlich, dass man sich in einem Forum "für lau" solche Mühe gibt, den anderen zu helfen.

Gruß, Oliver

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

Klingt wie das Problem bei uns.

("Fehler bei Kommunikation" - externe Mail mit mehreren Empfängern)

Ich werde das beim nächsten Auftreten auch ansprechen/prüfen, ob das "An" Feld leer gelassen wird.

Würde es zumindest erklären.

Vielen Dank

Sebastian

Das muss dem Anwender gar nicht bewusst sein. Wenn er nämlich die Rundsendefunktion von DAVID ganz bestimmungsgemäß verwendet (also @@RND und dann Dateiname mit den Empfängern), um z.B. regelmässige Infos an alle seine Kunden zu verschicken, dann passiert exakt das o.A.:

Hier werden die Empfänger beim Versand aus der Rundsendedatei extrahiert und vermeintlich eine eigene Email pro Empfänger erzeugt. Zumindest erweckt der DAVID den Anschein, denn im Ausgangsarchive finden sich nach dem Versand einzelne Nachrichten mit korrektem Empfänger in der An:-Spalte.

DAVID versendet in diesem Fall aber nicht X einzelne Emails, sondern es wird so wie von Riawie beschrieben beim Versand per Smarthost eine Email an den Provider übergeben und entsprechend viele Einzelempfänger per Envelope dazu:

"...

(1) 235 2.5.0 Authentication successful. / Authentifizierung erfolgreich.

(1) MAIL FROM:<xyz@t-online.de>

(1) 250 2.1.0 Sender accepted. / Absender akzeptiert.

(1) RCPT TO:<abc@muster-1.de>

(1) 250 2.1.5 Recipient accepted. / Empfaenger akzeptiert.

(1) RCPT TO:<def@muster-2.de>

(1) 250 2.1.5 Recipient accepted. / Empfaenger akzeptiert.

(1) RCPT TO:<ghi@muster-3.de>

(1) 250 2.1.5 Recipient accepted. / Empfaenger akzeptiert.

..."

Dadurch, dass die Nachricht nur einmal übergeben wird, kann in so einem Fall das An-Feld der Email natürlich nie den tatsächlichen Empfänger der einzelnen Email enthalten (den müsste ja dann der Provider dorthinein kopieren).

Wenn der User vor dem Absenden der Rundsendung nicht z.B. seine eigene Emailadresse in das AN:-Feld geschrieben hat, dann bleibt das AN:-Feld bei all diesen Emails in so einem Fall leer und diese Emails werden dann von United Internet abgelehnt.

Abhilfe in dem Fall nur: Auch bei bewussten Rundsendungen immer eine (eigene) Emailadresse ins AN:-Feld schreiben, dann klappts auch mit United Internet. Den DAVID für diese Fälle speziell auf Direktversand (also nicht Smarthost/Provider) umzukonfigurieren, funktioniert auch, weil der DAVID dann in dem Fall selbst Einzelemails verschickt. Das ist aber relativ viel Aufwand und bei kleineren Installationen, die sonst mit einen zwischengeschalteten Provider und per Smarthost versenden, meist auch gar nicht einfach mal so nebenbei möglich. Da holt man sich eher noch zusätzliche Probleme ins Haus.

Viele Grüße

Werner

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.

riawie

Jetzt hast Du mich neugierig gemacht: Wo ist bei Dir der Betreff andersfarbig dargestellt? Der Betreff ändert bei den Installationen, die ich kenne, nur in Abhängigkeit der Dringlichkeit der Nachricht die Farbe.

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

riawie wo Du recht hast, hast Du Recht , man kann das Blau hier bei mir praktisch nicht erkennen. Ich musste ganz schön an den Monitoreinstellungen drehen, um den Unterschied zwischen dem dunklen Blau und dem Schwarz erkennen zu können.

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.

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.

Guten Morgen zusammen,

wir haben jetzt die Info von ionos bekommen, dass unsere Rundsendungen ohne "Date-Statement" im SMTP-Header geschickt werden.

was kann man hier machen?

Rundsendungen wollen wir eigentlich nicht ausschalten

Besten Dank