Hallo zusammen,
das könnte mit einem Problem des Service-Layers zu tun haben, das seit mindestens zwei Jahren bei TOBIT bekannt ist und m.W. immer noch nicht gefixt ist: Service Layer legt selbständig neue Benutzer an
Sind die "neuen" Benutzerarchive komplett leer oder findet sich dort im Eingang jeweils auch eine Willkommens-Email und evtl. sogar eine Nachricht, die eigentlich für den externen Versand bestimmt war?
Werner
Probier's mal mit Port 465, denn Port 587 wird m.W. nur von der Telekom verwendet. Strato, GMX und 1&1 verwenden 465 oder z.T. auch 25 wie bisher.
Viele Grüsse aus München
Werner
Hallo zusammen,
das liegt vermutlich an der Art, wie Ihr Euren Postman konfiguriert habt. Ihr müsst für das T-Online-Konto eine Sendemethode definieren, so wie das der User Meierjo in folgendem Thread sehr schön dokumentiert hat:
Wie Email Verkehr auf SSL umstellen
Viele Grüsse
Werner
Hi Robert,
wenn es bei Dir auch um DAVID Zehn geht, dann geht es leider nicht, denn der Grabbing-Server von DAVID Zehn kann defintiv kein SSL. Es gibt dann mit DAVID eigenen Mitteln auch keinen Trick, mit dem Du es ihm beibringen kannst. Ein anderer User dieses Forums hat aber einen Workaround gefunden:
Hier wird POPCon verwendet, um die Emails per SSL beim Provider abzuholen und per SMTP an den Postman weiter zu geben. Der Grabbing-Server wird hier komplett umgangen, die Kontendefinitionen stehen in POPCon. Am Postman muß Weiterleiten aktiviert sein.
Du kannst POPCon herunterladen und 30 Tage kostenlos testen. Danach kostet es einmalig Euro 80,00, aber das ist in jedem Fall weniger, als ein Upgrade auf einen neuen DAVID.
Viele Grüsse
Werner
Hallo RSponi,
ich habe nie einen DAVID XL bei einem Kunden installiert, deshalb keine Ahnung, ob das funktioniert. Du hast zwei Probleme: Den SSL-Empfang über den Grabbing-Server und den SSL-Versand über den Postman. Für den Grabbing-Server, der in Deiner Version kein SSL kann, hat ein anderer User schon für DAVID Zehn einen Workaround gefunden:
Hier wird POPCon verwendet, um die Emails per SSL beim Provider abzuholen und per SMTP an den Postman weiter zu geben. Der Grabbing-Server wird hier komplett umgangen, die Kontendefinitionen stehen komplett in POPCon. Am Postman muß Weiterleiten aktiviert sein. POPCon kostet zwar Geld, aber weit weniger als ein Upgrade auf einen neuen DAVID.
Bevor Du die Sache mit dem POPCon angehst, solltest Du aber testen, ob Dein Postman SSL/TLS mit dem Provider kann. Entsprechende Hinweise zur Einrichtung findest Du z.B. im folgenden Beitrag, das Stichwort ist hier "Sendemethode" aus dem Beitrag von Meierjo:
Wie Email Verkehr auf SSL umstellen
Viel Glück!
Werner
Dann fällt mir noch spontan ein, dass der securesmtp.t-online.de auf Port 587 arbeitet und nicht auf 465. Evtl. liegt es daran.
Hast Du im POSTMAN unter "Konfigurieren" - "Erweitert" auch an "TLS bei Versand verwenden - Wenn möglich" gedacht? Falls nicht, dann versucht es der POSTMAN trotz des entsprechenden Ports ohne TLS und das scheitert dann in jedem Fall.
Hallo Thomas,
ich kenne da leider auch niemand, aber wenn der Mercury erfolgreich abholt, dann müssten die Mails ja schon in entsprechenden Postfächern auf dem Mercury liegen. Wenn es da keine Einstellungen gibt, damit er sie automatisch per SMTP an den POSTMAN weitergibt, dann solltest Du als Alternative versuchen, den Grabbing-Server per POP intern an den Mercury anzubinden. Dann holt der Mercury die Mails per SSL vom Provider, speichert sie in jeweils einem internen Postfach zwischen und der Grabbing-Server holt sie sich dann von dort unverschlüsselt per POP. Dann hast Du auch, was Du brauchst und als Nebeneffekt kannst Du die Emails im Grabbing-Server wieder direkt bestimmten Usern oder Eingangs-Archiven zuweisen.
Werner
Hallo Thomas,
eine direkte Anleitung kann ich Dir selbst nicht geben, aber ich habe das gefunden:
Für Dich ist neben der POP-Abholung der Konten der SMTP-Client wichtig. Er ist für das Weiterschicken an den SMTP-Server (d.h. den Postman) verantwortlich. Dort trägst Du als Server die IP-Adresse Deines DAVID-Servers ein. Natürlich muß am POSTMAN "Weiterleiten" aktiviert sein. Ausserdem solltest Du dort natürlich Username/Passwort konfigurieren und das dann im SMTP-Client des Mercury eintragen. Ich habe das aber selbst noch nicht ausprobiert. Bei den im vorherigen Beitrag angesprochenen Mailgateways kommt übrigens meist FETCHMAIL zum Einsatz.
Viele Grüsse
Werner
Das hängt beides zusammen, aber der Reihe nach:
Damit der User die Optionen beim Löschen externenr Nachrichten wieder bekommen, musst du im Infocenter des Users folgendes anklicken: Optionen - Einstellungen - Global - Bestätigungen und dann den Haken rein bei "Optionen beim Löschen von externen Nachrichten". Schon bekommt der User wieder das Fenster mit den Wahlmöglicheiten.
Beim Thema zwei gibt es mehrere Möglichkeiten: Gern passiert es, das die User bei den Wahlmöglichkeiten "Email mit dem Zeichensatz .... blockieren" auswählen. Das blockiert dann generell alle Emails mit einem bestimmten Zeichensatz. Oder der User klickt im Eifer des Gefechts auf "Empfänger dauerhaft blockieren". Damit hat er dann erst mal Ruhe vor seinen Emails, denn blockieren bedeutet bei DAVID immer, dass die Nachrichten unbesehen sofort und unwiderbringlich gelöscht werden (ohne Umweg über den Papierkorb).
Viele Grüsse
Werner
Hallo zusammen,
der Grabbing Server von DAVID 10 kann noch kein SSL, da gibt es leider auch keinen Trick. Erst der Grabbing Server von DAVID.fx kann auch SSL (Siehe auch Knowledgebase-Artikel Q-102.594, letzer Absatz).
Einziger Workaround der mir einfällt: Setze einen Mailserver wie z.B. Mercury (kostenlos) davor, der die Konten mit SSL per POP3 beim Provider abholt und dann per SMTP an den Postman des DAVID weitergibt. Ähnliche Konstruktionen funktionieren perfekt, wenn beim Kunden ein sicheres Mailgateway (für Ver-/Entschlüsselung) im Einsatz ist. Da ist der Grabbing Server auch komplett ausser Kraft und es arbeitet nur der Postman.
Ein Nachteil sei allerdings nicht verschwiegen: Beim Empfang über Postman gibt es keinerlei serverseitige Verteilung über Regeln. DAVID wertet in diesem Fall stumpf die SMTP-Header Informationen aus und nimmt danach die interne Zustellung vor. Die direkte Zustellung in bestimmte User-Postfächer oder beliebige Archive muß man dann mit Regeln in den User-Eingängen machen.
Viele Grüsse aus München
Werner
Kleine Gegenfrage: Wieviele Deiner Eingangsemails haben keinen Betreff? Denn danach suchst Du in Deiner Regel. Wenn jede Email - gleich welchen Betreffs - weitergeleitet werden soll, dann musst Du die Zeile mit dem Betreff ändern in: "Betreff ist gleich *". Das Sternchen ist eine Wildcard und steht für alles und für beliebig viel.
Dann: Wenn ein interner User der Empfänger ist (also auch ein DAVID-User), dann solltest Du nicht "Weiterleiten und Xmedia" verwenden, sondern die Option "Verteilen an einen Benutzer oder in einen Ordner" wählen. Dann kannst Du den Empfänger direkt über die User-Liste auswählen. Es kann aber auch ein beliebiges Archive eingetragen werden (z.B. ein zentrales Posteingangsarchive).
Und schliesslich solltest Du nicht "Empfänger ist gleich ..." verwenden, sondern "Verteilkennung ist gleich ...". Denn im Empfängerfeld stehst Du unter Umständen gar nicht selbst, Du hast diese Nachricht nur z.B. aufgrund anderer Weiterleitungen oder per CC, ... bekommen und dann schreibt der DAVID Deine Emailadresse nicht in das Empfängerfeld, sondern in die Verteilkennung.
So sollte das dann funktionieren. Vergiß aber nicht, daß DAVID Regeln automatisch nicht auf intere Emails anwendet, sondern nur auf externe.
Viele Grüße aus München
Werner
Ja, lösche die Postfacheinrichtung bei den Benutzern und richte Dir unter "Grabbing Server" - "POP3-Konten" die Emailkonten mit den POP-Zugangsdaten und unter "Postman" - "Sende Methoden" die Sendemethoden für die SMTP-Seite Deiner Postfächer ein. Dann kannst Du überall die korrekten Ports eintragen und hast auch sonst alle Freiheiten in Bezug auf Verteilung, ...
Das Eintragen der Emailkonten bei den Usern spart Dir bei der Einrichung zwar Zeit, limitiert Dich aber auch bei einigen Dingen (z.B. bei der hier besprochenen Thematik). Aus meiner Sicht sollte man deshalb generell den o.a. Weg gehen.
Viele Grüsse aus München1
Wenn Deine Emailkonten bei den Usern definiert sind, dann gibt es dort kein Eingabefeld für die Ports, aber die Server kannst Du dort in jedem Fall eintragen. Da setzt Du einfach den Port hinter den Servernamen, z.B. pop.1und1.de:995. Dann sollte das auch klappen.
Werner
Um Deine 1und1-Accounts auf SSL umzustellen musst Du im DAVID Administrator folgendes einstellen:
Grabbing Server - POP3 Postfach - Eigenschaften - Zugangsparameter - Port: Hier 995 eintragen, Server-Adresse bleibt wie gehabt der pop.1und1.de, alles andere auch.
Zum Versand hängt es davon ab, ob Du Sende-Methoden für die einzelnen Postfächer definiert hast, oder über den POSTMAN direkt (als Smarthost) nur einen SMTP-Server benutzt. Bei Sendemethoden gilt im DAVID Administrator folgendes:
Postman - Datenbanken - Sende Methoden - Rechts im Fenster einen Rechtsklick auf die jeweilige Sendemethode und dann auf Eigenschaften - Port: Hier 465 eintragen, Server bleibt smtp.1und1.de, alle anderen Einstellungen bleiben ebenfalls wie gehabt.
Bei Versand über Smarthost gehst Du statt dessen direkt auf Postman, Rechtsklick und dann Konfiguration. Hier beim Provider auch direkt den Port 465 eintragen und kontrollieren, ob der o.a. SMTP-Server eingetragen ist.
Danach beide Dienste (Grabbing-Server und Postman) neu starten. Das sollte es gewesen sein und fortan läuft mit 1und1 alles über SSL.
Diese informationen gelten sinngemäß auch für GMX und WEB , weil diese ebenfalls zu United Internet Media gehören. Man muß nur die SMTP- und POP-Server entsprechend anpassen, die Ports sind dieselben.
Bei T-Online läuft es im Prinzip ebenso, allerdings benötigt man ein Email-Kennwort, welches vorher extra im Kundencenter eingerichtet werden muß. Als Benutzername wird dann statt der Konstruktion aus Anschlußkennung, T-Online- und Mitbenutzernummer der Email-Alias verwendet, als Passwort nicht das T-Online-Passwort, sondern das neue Email-Kennwort. Die Server heissen bei T-Online securesmtp.t-online.de und securepop.t-online.de. Die Ports sind 587 oder 25 für SMTP und 995 für POP.
Viele Grüsse aus München
Werner
Um Deine GMX-Accounts auf SSL umzustellen musst Du im DAVID Administrator folgendes einstellen:
Grabbing Server - POP3 Postfach - Eigenschaften - Zugangsparameter - Port: Hier 995 eintragen, Server-Adresse bleibt wie gehabt, alles andere auch.
Zum Versand hängt es davon ab, ob Du Sende-Methoden für die einzelnen Postfächer definiert hast, oder über den POSTMAN direkt (als Smarthost) nur einen SMTP-Server benutzt. Bei Sendemethoden gilt folgendes:
Postman - Datenbanken - Sende Methoden - Eigenschaften der Sende Methode - Port: Hier 465 eintragen, Server ist mail.gmx.net, alle anderen Einstellungen bleiben wie gehabt.
Bei Versand über Smarthost gehst Du statt dessen direkt auf Postman, Rechtsklick und dann Konfiguration. Hier beim Provider auch direkt den Port 465 eintragen und kontrollieren, ob der richtige SMTP eingetragen ist.
Danach beide Dienste (Grabbing-Server und Postman) neu starten. Das sollte es gewesen sein und fortan läuft mit GMX alles über SSL.
Viele Grüsse aus München
Werner
Genau aus diesem Grund gibt es seit Einführung von Sitecare bei uns hier keinen einzigen DAVID-Neukunden mehr. Früher konnte man noch auf Bugfixes und ein paar Service Packs hoffen, die grobe Fehler in der Software noch nachträglich beheben, bis die jährlich erscheinende neue Version von DAVID früher oder später ein kostenpflichtiges Update notwendig machte.
Jetzt ist mit jeglichem Support nach Ablauf von 30 Tagen nach Kauf Schluß, es sei denn, der Kunde schliesst Sitecare bereits beim Kauf mit ab. Damit wird das Produkt aber schon im ersten Jahr um ca. 50-60% teurer, als es der Listenpreis vorgaukelt. Und dieser Zusatzbetrag wird danach auch weiterhin jährlich fällig. Der Mitbewerb nimmt dafür normalerweise nicht mehr als 25%-30% pro Jahr, wobei Service und Updates im ersten Jahr nach Kauf i.d.R. kostenlos inbegriffen sind.
TOBIT verweigert dem Kunden damit jegliche Fehlerkorrektur (auch im Rahmen einer ggfs. anwendbaren gesetzlichen Gewährleistung) und stiehlt sich meines Erachtens hier einfach aus der Verantwortung. Wenn der Kunde das Produkt nicht bei TOBIT direkt kauft, sondern über uns als Händler, habe wir unsererseits im Rahmen der Gewährleistung den schwarzen Peter, falls die Version buggy ist - und darauf haben wir grundsätzlich keinen Bock.
Aber ich vergaß: DAVID hat ja von Haus aus keine Fehler ...
Viele Grüsse aus München
Werner
@Kamil: Dieser Bug wurde dadurch entschärft, dass Du beim Weiterleiten/Antworten derartiger Mails darauf hingewiesen wirst, dass im Text DAVID-Steuerbefehle stehen. Danach schaltet das Infocenter auf Textmodus um und nimmt die @@-Zeichen raus.
Ich habe noch ein bisschen rumgespielt und dabei entdeckt, dass man bei der o.a. Problematik durch Weglassen des "@domain...." in der Empfängeradresse auch interne Faxe verschicken kann. Wenn man im Infocenter also eine neue Email erstellt, als Empfänger nur "{12345}" eingibt und das dann abschickt, legt der Service-Layer wie gehabt einen neuen Benutzer an, macht dort sein Willkommensemail in den Eingang und dann noch die gerade erstellte Nachricht als Fax. Und ich bin sicher da geht noch mehr.
Vorstellbares Szenario: Ein User (und es kann wirklich ein DAVID-User mit so gut wie keinen Rechten sein) bekommt eine Joke-Mail, wo zig Empfänger im TO: stehen. Am Ende dieser Liste stehen dann noch 30 fiktive Empfänger nach dem Schema aus meinem Eingangspost. Das Infocenter zeigt Dir die Empfängerliste ja nicht komplett an, sondern spricht nur von "und ... weitere". Unser DAU drückt auf Antworten, weil er sich auch an dem Blödsinn beteiligen will und schon hat der Admin gut zu tun, weil es 30 neue Benutzer im System gibt. Einziger Trost: Der Admin weiß dann auch, wer es war und kann demjenigen einen Besuch abstatten. Aber er kann nichts tun, um so etwas zukünftig zu verhindern.
Übrigens: Wenn man zwischen den geschweiften Klammern die User-ID eines bekannten internen DAVID-Users schreibt, erhält dieser User die Nachricht direkt. Der Service-Layer legt in diesem Fall keinen neuen sinnlosen User an. Vielleicht ist das auch eine der oft dementierten Hintertüren, über die TOBIT z.B. seine Werbeemails verteilt. Ich erinnere nur an die Zeit, als vehement für FX12 geworben wurde und in meinem Kundenkreis mehrere Installationen waren, wo plötzlich alle User der jeweiligen Site eine Werbung für das Update auf FX12 in ihrem Eingang hatten, obwohl es keinen entsprechenden regulären Email-Eingang gegeben hat.
Werner
Hallo zusammen,
das Problem tritt derzeit offenbar nur beim Versand auf. Die Kunden erhalten von Ihren amerikanischen Mandanten wie geschildert Emails, bei denen im TO: eine oder mehrere hausinterne Empfänger genannt sind, im CC: aber neben evtl. anderen Empfängern auch die im Eingangspost geschilderte DMS-Empfängeradresse mit den geschweiften Klammern. Da nach RFC diese Emailadressen in Ordnung sind, werden sie von allen beteiligten Providern und Servern kommentarlos übermittelt und schlagen beim Empfänger im DAVID-Server auf. Dort kann man sie öffnen, drucken, löschen und sonst was damit machen - alles kein Problem. Wenn man aber auf eine dieser DMS-Adressen antwortet, schlägt der beschriebene Mechanismus zu und man hat auf Dateiebene einen kompletten neuen User ohne Namen im System.
Das bedeutet: Der Service-Layer entwickelt beim Versand einer Nachricht an eine Email-Adresse mit geschweiften Klammern (die vollständig den gültigen Standards entspricht) ein Eigenleben und das ist in meinen Augen kein Feature, sondern ein übler Bug, der TOBIT bereits seit 1 1/2 Jahren bekannt ist.
@Kato: Da schon Kingcopy von ähnlichen Erfahrungen in einem anderen Zusammenhang berichtet hat, liegt die Vermutung nahe, dass hier ein systematisches Problem vorliegt, das auch noch an ganz anderer Stelle zuschlagen kann. Wenn der Service-Layer von sich aus alleine durch eine passende Email-Adresse dazu veranlasst werden kann, ein komplettes Benutzer-Archive anzulegen, eine Willkommens-Email zu erzeugen und eine für den externen Versand bestimmte Nachricht in den Eingang dieses neuen Benutzers zu kopieren, dann ist in meinen Augen vom Prinzip her auch alles andere denkbar. TOBIT wird sich dazu aber überhaupt nicht äußern.
Vielleicht habe ich die nächsten Tage einmal Zeit, ein paar Experimente mit einem Testsystem zu machen.
Übrigens: Einer der Mandanten hat Lotus-Notes, der andere MS-Exchange. Wenn meine Kunden die Emails jeweils mit z.B. Outlook beantworten, funktioniert alles ohne jede Klage.
Werner
Ich habe gerade noch mit einem befreundeten TAR gesprochen: Der hat dieses Verhalten bei einem seiner Kunden schon im August 2011 mit fx.2011 festgestellt und über das Intercom an TOBIT gemeldet. TOBIT meinte damals dazu:
"Wir konnten diesen Effekt nachvollziehen, ..... Möglicherweise wird hierzu eine Änderung bzw. Anpassung schon in einem der nächsten Service Packs (Hotfixes) oder Releases enthalten sein."
Er meinte auch, dass TOBIT das offenbar nicht fixen will oder kann, weil es zentrale Funktionen des Service Layers betrifft und es gibt offenbar auch keinen Workaround dazu. Das was Kingcopy im Beitrag vorher beschrieben hat, würde sich dann mit dieser Aussage in so fern decken, als das es offenbar wirklich intern im Service-Layer Funktionen gibt, die bei Triggerung durch die geschweiften Klammern in Abhängigkeit vom Kontext entweder etwas Nützliches oder aber auch etwas total Unvorhergesehenes machen - und TOBIT weiß das schon seit Langem und macht die Augen zu.
Meine beiden Kunden wird das sicher freuen, wenn ich Ihnen davon berichte.
Ich wünsche Euch ein schönes langes Wochende!
Werner
