Beiträge von NoHopeNoFear

die ursache liegt auf der hand, david versendet direkt - ohne smtp relay bzw. smarthost. dabei werden die dafür notwendigen voraussetzungen nicht erfüllt.

also SMTP relay vom provider verwenden oder den anschluss korrekt konfigurieren.

du kannst auch hiermit: http://www.computer-sommer.de/…center/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.

oder einfach den Mac via IMAP anbinden...

entweder im ausgang des system users oder des administrators. ob das in V8 auch schon so war kann ich nicht zu 100% sagen.

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.

vermutlich konnten sie auch beim 100. versuch kein beispiel generieren in dem der kram funktioniert. da sowieso kaum noch jemand mit funktionalen neuen features rechnet wurde es dann trotzdem veröffentlicht

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

reddoxx setzt direkten SMTP empfang vorraus (kann auch proxy, aber aus den genannten gründen nicht empfohlen). versand sollte idealerweise auch direkt, ohne smtp relay, erfolgen. dann gibts die oben gezeigten logs.

mein beileid
wenn du infos zur integration von reddoxx in david brauchst melde dich.

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.

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.

funktioniert die audio ausgabe auf dem terminalserver denn überhaupt? unabhängig von david?

wenn hier schon vom thema abgeschwiffen wurd und das thema backup diskutiert wird werfe ich mal veeam backup&replication in den raum.
wer mit virtuellem umgebungen arbeitet fährt damit meiner ansicht nach deutlich besser als mit acronis.

mein beileid. wie konntest du es auf die EAS schnittstelle eingrenzen?

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.

ist auch zu empfehlen. große auswahl und sehr guter support wenns mal klemmt.

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?

nach einem ähnlichen fehler habe ich mal ewig gesucht... am ende kam dabei raus dass der user am mausrad gewackelt / gedreht hat während er über das CC/BCC/AN feld gefahren ist und damit weitere empfänger ausgewählt hat. mouseover reicht da scheinbar.