Beiträge von wlconsult

So, jetzt bin ich es selbst noch einmal. Nachdem TOBIT es auch nach mehrmaliger Anfrage meinerseits nicht geschafft hat, meine Frage nach den Variablen für eine eigene Attachments.htm-Datei zu beantworten, gehe ich davon aus, dass es neben den o.a. drei Variablen schlichtweg keine weiteren gibt, die hier funktionieren.

Die anhängende Mustervorlage in deutsch/englisch ist im Prinzip die Vorlage, die TOBIT selbst fest in den Service-Layer eingebaut hat. Ich habe sie ein bisschen umgeschrieben und mich auf die drei verfügbaren Variablen beschränkt.

Editieren lässt sich die Datei sehr gut mit z.B. Notepad++ oder jedem anderen HTML-fähigen Editor. Ich kann nur raten, dafür nicht Word zu verwenden. In Zeile 6 des Quellcodes kann der eigene Firmenname eingetragen werden (<TITLE>Mein Firmenname</TITLE>). Dieser erscheint dann beim Empfänger oben auf dem Browsertab. Selbstverständlich kann jeder den verwendeten Text beliebig abändern oder um zusätzliche Sprachen erweitern. Das Ganze ist als Muster zur freien Verwendung gedacht.

Wo im System die fertige Vorlage abzulegen ist, steht in meinem vorherigen Post. Die Vorlage ist dann sofort aktiv, Ihr müsst also keinen der DAVID-Services neu starten.

Viel Spaß beim Ausprobieren
Werner

Die Tests dazu konnte ich bei einem großen Kunden erst letzte Woche machen und mittlerweile auch bei anderen Kunden mit/ohne Sitecare nachprüfen.

Das Problem ist schon an TOBIT weitergegeben, eine Antwort steht allerdings noch aus. Der Fehler besteht aber mindestens schon seit einem Jahr, denn so alt war die älteste DAVID-Version (ohne Sitecare), mit der ich das testen konnte.

Hallo zusammen,

das Problem kann ich bestätigen und es tritt schon seit Längerem auf (ist also nicht auf die aktuellste DAVID mit Sitecare beschränkt):

Kommt von extern eine Termin-/Besprechungsanfrage herein, die im AN-Feld mehrere Empfänger aufweist (Empfänger-Adressen aus unterschiedlichen Domänen), dann nimmt DAVID als Absender-Adresse für eine Antwort immer die erste Adresse aus dem AN-Feld, auch wenn die mit dem internen Empfänger oder der eigenen Domäne nichts zu tun hat. Als Ergebnis wird diese Email vom eigenen Provider abgelehnt, wenn eine Überprüfung der Absenderadresse stattfindet. Alternativ lehnt der Empfangsserver die Nachricht ab, weil Absender-Adresse und -Domäne nicht übereinstimmen.

Korrekt macht der DAVID das nur, wenn es nur einen (internen) Empfänger für die Besprechungsanfrage gibt, oder wenn per Zufall der interne Empfänger an erster Stelle im TO:-Feld steht.

Ein ziemlicher Bock meiner Meinung!

Du musst die Druckvorlage für Emails ändern. Diese befindet sich im Verzeichnis \DAVID\Clients\Windows und hat den Namen EMAIL.PRN. Ich habe meine eigene und die von allen Kunden schon vor einigen Jahren abgeändert, weil die Liste der Anhänge m.E. auch in den Kopf der Emails gehört und nicht an das Ende. Wenn eine Nachricht etliche Male hin und her geht, dann stehen die Anhänge mit der Originalvorlage schliesslich dort, wo kein Anwender sie mehr sucht.

Ich habe meine EMAIL.PRN hier mal angehängt. Probiere sie einfach mal aus.

Werner

Dem kann ich nur zustimmen. Bei größeren Netzwerkinstallationen legt bestimmt jeder Admin Wert darauf, dass sich die einzelnen Anwender bei Tobit anmelden und dann unkontrolliert irdendwelche Dinge auslösen können. Der Button sollte mindestens per Voreinstellung ausblendbar sein und zwar so, dass der User am Arbeitsplatz ihn auch nicht wieder einblenden kann.

Hallo zusammen,
ich bin gerade dabei, eine individuelle Vorlage für die Attachments.htm-Datei zu machen, die DAVID beim Postlagernd-Versand an den Empfänger verschickt und über die er sich die Attachments dann herunterladen kann. Die Attachments.htm, die DAVID standardmässig benutzt und die offenbar im Service-Layer fest "verdrahtet" ist, ist ja nur in deutsch verfügbar. Ausserdem ist der Text mit dem Hinweis auf "postlagernden Versand" höchstens von DAVID-Nutzern richtig einzuordnen, der Rest der Welt kann damit i.d.R. nichts anfangen und klickt deswegen lieber nicht auf die Links.

Das Prinzip ist mir klar (eine neue Attachments.htm machen und auf dem DAVID-Server in das Verzeichnis \David\Clients\Windows legen). Funktioniert so weit perfekt. Nur leider habe ich bis jetzt nur drei Variablen gefunden, die auch wirklich mit der eigenen Attachments.htm funktionieren:
- ##SUBJECT## -> Betreff der Nachricht
- ##EXPIRATION## -> Links sind bis zu diesem Zeitpunkt gültig
- ##ATTACHMENTS## -> Listet die Anhänge als Link mit Angabe der Dateigröße auf

Ausserdem kann ich über das <TITLE></TITLE> Tag erreichen, dass z.B. der Firmenname auf dem Browser-Tab steht und nicht "Tobit.Software". Ich würde aber gerne so wie in der Original-Datei noch zusätzlich im Text das Sendedatum und den Namen oder die Emailadresse des Absenders mit ausgeben. Dinge wie ##FROM##, ##STATUSTIME## oder ##ATTACHCOUNT## aus den anderen Druckvorlagen funktionieren nicht. Auch ein Zugriff auf den Firmennamen (z.B. über SYS_FIRMA) für das Title-Tag wäre schön, dann wäre die Vorlage nämlich ohne Änderung universell nutzbar. Das geht aber scheinbar alles nicht.

Kann mir jemand den entscheidenden Tipp für die notwendige Syntax oder eine Liste mit den Befehlen geben, die man an dieser Stelle einsetzen kann? Bin ich einfach noch nicht auf den richtigen Kniff gekommen oder hat Tobit hier wieder einmal etwas nur schnell eingebaut, nicht zu Ende gedacht und dann nie wieder angefasst?

Ich stelle meine fertige Vorlage (in deutsch/englisch) dann auch gerne hier zum Download zur Verfügung.

Werner

Vermutlich kämpfst Du mit einem grundlegenden Designfehler der Strongbox: Du kannst beim Definieren der Jobs jedes beliebige Laufwerk und jeden beliebigen Pfad angeben (UNC oder Laufwerksbuchstabe) - alles kein Problem. Nur kannst Du leider keine Anmeldedaten für Netzwerklaufwerke mit beim Job eingeben. Der Job läuft hinterher mit den Credentials des Service-Layers und wenn das zugrundeliegende Anmeldekonto nicht direkt auf Dein Netzwerklaufwerk zugreifen darf, dann läuft der Strongbox-Job nicht, auch wenn Dir der DvAdmin sagt, dass mit dem Zugriff alles in Ordnung ist.

Wenn also z.B. Dein Server in einer Domäne liegt und der Service-Layer mit dem Domänen-Admin-Konto läuft, Dein NAS aber nicht Mitglied der Domäne ist und Authentifizierung über das AD also nicht unterstützt, dann sichert die Strongbox niemals auf das Laufwerk. Sie sichert auch nicht, wenn auf dem DAVID-Server das Administrator-Konto verwendet wird, der User auf dem NAS aber z.B. "admin" heisst. Die Strongbox kriegt das nicht mal dann hin, wenn die Freigabe auf Deinem NAS Public ist und jeder Vollzugriff hat, also gar keine Credentials gebraucht werden.

Eine Sicherungssoftware, bei der man bei den Jobs keine Anmeldedaten für Netzwerkresourcen hinterlegen kann, ist halt leider nur die Hälfte wert. TOBIT weiss das seit Langem, kümmert sich aber nicht drum.

Viele Grüße aus München
Werner

Hallo zusammen,

mit dem letzten Rollout hat TOBIT einiges an der Namensdarstellung beim Adressieren/Verteilen am Client verändert. Zum einen wird bei der Auflistung des internen Adressbuchs (beim Adressieren oder beim Verteilen am Client) jetzt nicht mehr der Archive-Name des Users verwendet, sondern der Inhalt des Feldes "Angezeigter name" aus der User-Einrichtung im DvAdmin. Zum anderen werden bei der Adressbuchauswahl jetzt wirklich alle eingegebenen Kontakte mit "Vorname Nachname" dargestellt, obwohl sie in den Adressbüchern korrekt eingegeben und in den Listen im Feld "Angezeigter Name" mit "Nachanme, Vorname" korrekt gelisted werden.

Beides ist total beknackt und ich frage mich - wie schon öfters in der Vergangenheit - was sich der betreffende Produktmanager oder Programmierer bei so einer Änderung gedacht hat. Niemand (ausser vielleicht die Isländer) hat nach Vornamen sortierte Adressbücher. Schlimmer noch: Wenn in einer Firma mehrere User eine allgemeine Adresse als Standard-Emailadresse wie z.B. info@... verwenden (müssen) und in der Vergangenheit bei der Einrichtung der User deshalb in der Benutzerverwaltung im Feld "Angezeigter Name" der Firmenname eingetragen worden ist, dann hat man jetzt beim internen Verteilen am Client nicht einmal mehr Namen stehen, sondern vielleicht 20 oder 30x den eigenen Firmennamen. Verteilen oder Adressieren an interne User ist auf diesem Weg dann gar nicht mehr möglich.

Letzteres kann man zwar mit Include-Dateien oder mit @@-Befehlen in der Emailvorlage ändern, aber schön ist es nicht und überflüssig wie ein Kropf. Die individuellen und die allgemeinen Adressbücher bleiben dadurch aber nach Vornamen sortiert, hier gibt es derzeit keine Tricks.

Ich hoffe für meine Kunden und mich, dass das schleunigst wieder geändert wird, denn es gibt aus meiner Sicht keinen nachvollziehbaren Grund für so einen Unfug. Ein Bug ist es nicht, denn es wurde konsequent überall umgesetzt.

Viele Grüsse aus München
Werner

Danke für die Rückmeldungen und den Tipp mit den Include-Dateien. Ich weiß mittlerweile, dass es ein neues Feature seit dem letzten Rollout ist (Q-111.451). Denn Sinn dahinter verstehe ich aber nicht.

Wenn ich im Archive-System die Benutzer in der Form "Nachname, Vorname" umbenenne, dann hatte ich bis jetzt bei der internen Verteilung ein perfekt alphabetisch nach Nachnamen sortiertes Benutzerverzeichnis, unabhängig vom angezeigten Namen beim Email-Versand. Beim "Angezeigten Namen" schreibe ich das i.d.R. genau anders herum, das steht ja dann auch so im SMTP-Header der ausgehenden Nachrichten. Wenn ich bei dem konkreten Kunden statt des Firemnnamens jetzt dort die individuellen Namen eintrage, dann ist seine Verteilerliste statt dessen ab jetzt alphabetisch nach Vornamen sortiert.

Der Tipp mit den Include-Dateien zeigt zwar einen möglichen Ausweg, dieser macht etwas bisher Einfaches aber komplizierter. Und ausserdem brauche ich im vorliegenden Fall mehrere Include-Dateien, weil leider nicht alle Benutzer im angezeigten Namen den Firmennamen stehen haben, sondern es bei den Chefs durchaus individuelle Abweichungen gibt.

Aus Sicht des Kunden ist das kein neues Feature, sondern kontraproduktiv. Und wie eingangs schon erwähnt: Ich kann den Sinn dahinter ebenfalls nicht entdecken und der Knowledgebase-Artikel sagt in typischer TOBIT-Manier auch nur, dass es jetzt halt so ist.

Ich muss mal rumprobieren, ob es evtl. irgendwie mit einer zentralen Include-Datei geht und melde mich dazu dann noch einmal.

Viele Grüsse aus München
Werner

Ist schon jemandem aufgefallen, dass der Client aus dem Rollout vom 11.07. sich beim manuellen Verteilen anders verhält als sein Vorgänger vom 11.06.? Bei einem Kunden habe ich die Situation, dass ca. 20 Mitarbeiter als erste (Haupt-)-Email-Adresse die allgemeine info@... eingetragen haben. In der Benutzerkonfiguration steht da also bei diesen Mitarbeitern unter "Angezeigter Name" der Firmenname und unter Hauptadresse eben jene info@...-Adresse. Erst bei "Weitere" kommen dann die individuellen Adressen.

Der Client vom 11.06. hat beim manuellen Verteilen am Client (also: Rechtsklick auf die Nachricht - Verteilen) im darauf folgenden Fenster unter "Benutzer" die Benutzernamen aus dem Archive-System verwendet/angezeigt. Jeder User war also eindeutig identifizierbar.

Der Client vom 11.07. zeigt statt dessen unter "Benutzer" den im Administrator unter "Benutzer" eingetragenen "Angezeigten Namen" an, was im vorliegenden Fall dazu führt, dass statt der gewohnten Usernamen jetzt ca. 20 mal der Firmenname in der Liste auftaucht. Ein gezieltes manuelles Verteilen einer zentral eingegangenen Nachricht an einen Mitarbeiter mit der allgemeinen Hautpadresse ist damit unmöglich geworden.

Kann das jemand bestätigen? Ich habe als Workaround in dem speziellen Fall lediglich die Möglichkeit gefunden, den "Angezeigten Namen" in der Benutzerkonfiguration im Administrator ganz raus zu löschen. Dann verwendet der Client beim manuellen Verteilen statt dessen wie bisher die Namen der Benutzer aus dem Archive-System. Den älteren Client kann man ja nicht einsetzen, weil dieser sich beim Start des Clients sofort auf den neuen Client updated.

Viele Grüsse aus München
Werner

PS: TOBIT habe ich dazu bis jetzt nicht gefragt, denn das ist mit Sicherheit ein neues Feature (DAVID ist ja per Definition "bug free" )

Schau doch bite mal im DAVID-Administrator unter "Ports" in den Eigenschaften Deines Postman nach, ob da unter "Dienste" ein Haken bei "Email-Rundsendung" drin ist. Wenn nicht, dann versendet Dein DAVID Einzelemails an alle Empfänger, auch wenn sie bei Dir hübsch nebeneinander im AN:-Feld zu sehen sind.

Falls der Haken fehlt, dann mach ihn rein, gehe dann nach "Email" - "Postman SMTP Dienst" - "Konfigurieren" und mache dort unter "Erweitert" den Haken bei "Verteilerliste anhängen" raus. Erstens kann man den Ausdruck, wie Du schon selbst festgestellt hast, weder anders platzieren noch formatieren und zweitens: Kein Mensch schaut ans Ende einer E-Mail, ob da in nicht üblicher Form eine Liste der Empfänger dieser Email zu finden ist, zu mal DAVID die auch bei Emails, die schon mehrfach zwischen zwei Empfängern hin und hergegangen sind, immer wieder ans Ende (und damit hinter alle RE: - RE: - Re: - ...) packt. Abgesehen von der Platzverschwendung beim Ausdruck. Das war mal eine gute Idee von Tobit (so vor gefühlten 25 Jahren etwa), aber sie ist total überholt und gegen alle Standards.

Du kannst das natürlich weiterhin so beibehalten, wenn sich Deine User dran gewöhnt haben, aber die Umstellung auf Rundsendung verhilft Dir wenigstens bei den externen Empfängern zu mehr Verständnis und verhindert die o.a. Rückfragen.

Viele Grüsse aus München
Werner

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:

SSL POP3 Abholung bei DAVID

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:

SSL Pop3 Abholung bei DAVID

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