Beiträge von NoHopeNoFear

    du kannst auch hiermit: http://www.computer-sommer.de/downloadcenter/index.php/tdq.html mehr oder weniger gut einen massen export machen. hatte damit für andere zwecke mal rumgespielt, funktioniert leider nicht zuverlässig wenn ganze ordner strukturen exportiert werden. einzelne ordner hat meist geklappt. würde es nicht für eine größere migration/export einsetzen, aber für einen user mit überschaubarer datenmenge sollte es gehen.

    das problem besteht schon immer. alle lösungen dafür wurden hier bereits erwähnt (EAS, IMAP, Replika). ich würde nicht davon ausgehen dass tobit einen (halb-) offline fähigen client noch zu unseren lebzeiten veröffentlicht.

    entgegen deiner aussage ist das kein problem vom editor sondern vom client an sich. es gibt keinen lokalen transit. der gesamte client läuft komplett online.

    das gibt es von itacom, ist allerdings relativ teuer:
    haben das bei einem kunden laufen, erstinstallation war nur mit support durch herstller machbar, aber vermutlich auch ein sonderfall bei diesem kunden.

    bist du denn sicher dass dir die archiv lösung nicht die möglichkeit bietet per POP3 mails abzuholen? dann wäre duplog eine machbare lösung. irgendwas muss das teil doch können?
    wenn keine proxy dienste gehen, kein pop3 geht bleibt ja nur SMTP gateway? wenn dem so ist könntest du auch popcon oder was ähnliches davor schalten.

    schau dir mal capifax an. wenn du nur eine simple lösung zum empfangen willst ist das deutlich günstiger und weniger umständlich als einen kompletten david zu installieren nur um ein paar faxe zu empfangen.
    haben wir mehfach so laufen, angebunden an kerio connect und exchange. AB dann evtl. direkt über die TK anlage lösen? ist jedenfalls fragwürdig für diese wenigen funktionen ein david zu installieren.

    alternativ umstellen auf NFON oder ähnlich, dann haste alles auf einmal gelöst ;)

    soweit ich weiß nein. deshalb auch meine aussage weiter oben im thread, dass es die beste lösung ist direkt am MX zu archivieren.
    daraus ergeben sich auch noch diverse andere vorteile wie z.b. die lösung des problems mit verschlüsselten mails und archivierung bzw. der verschlüsselung selbst.

    ich bin der ansicht dass die meisten "günstigeren" archiv lösungen zu kurz greifen. das thema ist relativ komplex und bietet einige ansätze um das email/doku system generell zu optimieren und sicherer zu machen. wer mit gewalt versucht für kleines geld den gesetzlichen pflichten nachzukommen und nicht über den tellerrand hinausdenkt verschenkt hier viel potenzial. schwierig ist es natürlich in der typischen 5-10 mitarbeiter bude solch eine lösung unterzubringen aber wir versuchen generell alle kunden über 15 user in diese richtung zu bewegen. bisher mit recht gutem erfolg, die akzeptanz der endanwender ist auch deutlich besser als wir es zu anfang erwartet haben.

    aber nicht die SMTP kommunikation selbst. wenn du am MX direkt archivierst, bzw. direkt versendest über deine archivierung sind die SMTP Commands (250 Empfangen z.B.) archiviert und damit lässt sich der versand/emfpang nachweisen. das ist z.b. relevant bei terminsachen.

    in einer reddoxx schaut das so aus für den versand, das wird separat zu jeder email gespeichert und ist quasi ewig nachvollziehbar.

    Code
    Connecting to: [Ziel MX]:25
    Receive on HELO: 250 HELP
    Receive on MAIL FROM: <Absender> = 250 2.1.0 Sender ok
    Receive on RCPT TO: <Empfänger> = 250 2.1.5 Recipient ok
    Data result: 250 2.1.5 OK mail delivered with id y03b65t8JBG2XSx
    - Disconected


    wenn du eine klassische archivierung einsetzt kannst du zwar mitunter belegen dass dein server die mail versendet hat - aber nicht dass sie auch angekommen ist. eine email gilt dann als zugestellt wenn der ziel mx sie akzeptiert hat, was danach passiert ist nicht dein problem.

    USB soundkarte am TS? Plug and Play Umleitung? ernsthaft? einfach den TS richtig konfigurieren, dann brauchts auch kein gefrickel.

    Audio & Audio Endpunkt Dienst starten, Umleitung von Audio Geräten erlauben und am Client aktivieren - fertig. Ob das das David Problem löst sei mal dahingestellt, aber ohne zu wissen ob der TE überhaupt was vom TS hört machts keinen Sinn hier was zu diskutieren.

    das problem für den versand liegt doch auf der hand. versannd direkt auf MX ohne die entsprechende voraussetzungen dafür zu erfüllen.
    also entweder PTR setzen - falls die IP denn statisch ist, SPF setzen und nochmal möglichst alle gängigen blacklists checken oder eben einen smtp relay benutzen.
    dafür fernwartungs service verkaufen wollen - in einem öffentlichen forum - ist schon ziemlich dreist.

    outlook mit EAS an David ist letztendlich auch ne frickel lösung die in sachen komfort, stabilität und features immer noch sehr weit hinter exchange zurück bleibt.
    warum man in ahaus bis heute nicht begriffen hat das remote arbeiten immer wichtiger wird verstehe ich auch nicht, scheinbar sind burger menus wichtiger.

    wir haben kaum noch kunden die david einsetzen, der großteil ist zu kerio oder exchange / exchange online abgewandert. bereut hat das bisher nur einer, und dem war sowieso nicht zu helfen ;)
    alle hier angesprochenen probleme sind ja nun auch nicht neu sondern schon ewig so. support für'n arsch, design wird immer wieder verschlimmbessert, an den relevanten dingen die die anwender wirklich haben wollen tut sich nichts. dazu noch dieser unsägliche schwachsinn mit den x webseiten die alle 0 informationsgehalt haben. warum sollte ich so einen unsinn als gewinnorientiertes unternehmen noch mitmachen?