Das war dann das ko für mailstore. Wurde euch das nicht erzählt
Hm, nö. Uns wurde nur erzählt, dass mit David am besten die Proxy-Variante klappt.
Das war dann das ko für mailstore. Wurde euch das nicht erzählt
Hm, nö. Uns wurde nur erzählt, dass mit David am besten die Proxy-Variante klappt.
Ich habe auch gerade Mailstore getestet.
Das Programm ist flexibel, logisch und bezahlbar.
Ich kann all deine Ausführungen 1:1 bestätigen. Mailstore läuft bei einem meiner größeren Kunden seit knapp 1,5 Jahren als "David-Proxy" störungsfrei. Der Import über IMAP war einmalig etwas Fleißarbeit, funktionierte aber deutlich besser, als ich befürchtet hatte.
Also aus
Wird "Ort, 14. September 2017". Von daher musst du vermutlich erst mit "%(Datum" das Datumsfeld einleiten und dann mit den entsprechenden Variablen befüllen.
Die Hilfe im David-Client sagt dazu Folgendes:
Datum/Zeit
Über die folgenden Variablen können unterschiedliche Datum- bzw. Zeit-Variablen ausgewählt werden:
Datum
Zur Auswahl stehen vier Variationen des aktuellen Datums. In Klammern sehen Sie jeweils ein Beispiel. Sobald das System die Serien-Nachricht erstellt, wird das Erstellungsdatum eingefügt.
(16.04.2003): %(Datum)
(Mittwoch, 16.04.2003): %(Datum %A, %x)
(Mi, 16.04.2003): %(Datum %a, %x)
(16-Apr-2003): %(Datum %d-%b-%Y)
Zeit
Uhrzeit der Nachrichten-Erstellung.
%(Zeit)
Wochentag
Wochentag der Nachrichten-Erstellung.
%(Wochentag)
Monat
Monat der Nachrichten-Erstellung.
%(Monat)
Kalenderwoche
Aktuelle Kalenderwoche.
%(Kalenderwoche)
Es grenzt daher an ein Wunder, wenn die alten App-Versionen noch mit den heute aktuellen Versionsständen der David-Server funktionieren.
Naja, der PCL Conversion Server (das dürfte nur den ganz alten Hasen noch etwas sagen) läuft mit dem neusten Rollout auch nach wie vor. Ich denke, dass Tobit an solchen Stellen bewusst nichts verändert, und dann funktionieren die alten Lösungen schlichtweg weiter. Bei der App ist eher Apple der "Gefahrenfaktor", da dort auch radikale Änderungen öfter mal vorkommen.
Von meinen Kunden benutzt inzwischen niemand mehr die App, aber ich finde es schon gut, dass Tobit das Teil noch einmal fit für iOS11 gemacht hat. Schadet ja nichts.
Problem ist, das die anderen Regel auch durchgeführt werden ... Obwohl Regel nr. 1 schon verschiebt ...
Ich hab mich im Februar 2016 exakt darüber gewundert und bei Tobit eine Anfrage gestellt. Antwort damals:
Es werden grundsätzlich alle Regeln abgearbeitet. Damit das so gewährleistet werden kann, werden Verschiebe-Regeln, sollte eine weitere Weiterleitung-, Lösch-, Kopier- oder Verschiebe-Regel auf diesen Eintrag zutreffen, die Datei nicht verschieben, sondern lediglich kopieren. Die Sortierung der Regeln dient dazu, dass bei vielen Regeln die Übersicht zu behalten.
Die einfachste Lösung dafür wäre, im david® Administrator eine Verteilregel anzulegen, die die Verteilkennungen prüft und in die entsprechenden Archive verschiebt. Diese werden nämlich vor den Regeln in den Archiven verarbeitet. Die Verteilregeln in den Archiven können Sie dann entfernen.
Also im Grunde genau das, was Arno oben schreibt. Vorteil der Regeln im David Admin: Im Ziel-Archiv, in das die Nachrichten auf diese Weise verschoben werden, können weitere Regeln existieren. Verschiebt man hingegen per Archive-Verteilregel und im Ziel-Archiv existieren weitere Regeln, so werden jene (nach meiner Kenntnis) nicht mehr gezogen.
START "" /WAIT ""%ssl%\letsencrypt.exe --renew --baseuri "https://acme-v01.api.letsencrypt.org/" >> %ssl%\update_log_renew.txt"
Bei mir ist es das gleiche wie bei lycra. Trotz Umleitung erfolgt die Ausgabe von letsencrypt.exe direkt auf der Console, nicht ins Logfile. Das ist 0 bytes groß, allerdings auch dann, wenn die Erneuerung sauber durchgelaufen ist. Kann ich reproduzieren, wenn ich den Befehl direkt aus der Komandozeile starte: Ausgabe erfolgt ins Fenster, Befehl läuft erfolgreich durch, die update_log_renew.txt wird erstellt, bleibt aber 0 bytes groß.
Die Datei letsencryp.exe nutzt Serilog für die Protokollierung, und damit das sauber funtkioniert, muss man offenbar erst noch Pakete nachinstallieren. Mir war das irgendwann zu aufwändig, hab's daher nicht komplett durchgezogen.
stylistics: Nutzt du die letsencrypt.exe aus dem Archiv von Murmelbahn, oder evtl. eine andere?
ARGH! Wie heißt es so schön... Kaum macht man's richtig, schon funktioniert's! ![]()
Da muss ein Haken rein (Konfiguration Webbox):
![]()
Schon merkwürdig das es bei dir nicht so ist.
Ja. Meine Webbox scheint immer nur exakt ein Zertifikat rauszugeben, obwohl drei zusammengefügt werden. Das ist doch so richtig, oder?
Ich habe das Thema "Automatisches Update" nach vielen Versuchen ad acta gelegt; hier läuft's einfach nicht stabil und sauber. Entweder, es bleibt ein Programm hängen, oder die Webbox startet nicht sauber. Außerdem ist das Ganze eh ein bisschen suspekt, solange man von der letsencrypt.exe kein Protokoll bekommen kann - so ist nämlich nie klar, ob das Update wirklich durchgelaufen ist, oder der Batch nur aus den bereits vorhandenen Dateien eine neue wbcert.pem zusammenkopiert.
Dennoch bin ich mit dem Ergebnis ganz zufrieden; bei einer ansonsten kostenlosen Lösung kann man es auch auf sich nehmen, 4x im Jahr manuell eine Erneuerung durchzuführen. Und das geht mit der update.bat sehr bequem.
Mein Problem ist eher, dass Prüfseiten wie ssllabs.com immer noch melden, dass die Zertifikatskette unterbrochen sei. Obwohl die wbcert.pem ja aus den 3 Dateien zusammenkopiert wird, sagt mir ssllabs, dass lediglich ein Zertifikat übergeben wurde. "Sent by server" das für meine subdomain, "In trust store" das Root-Zertifikat, aber "Let's Encrypt Authority X3" wird als "extra download" angezeigt, obwohl es nach meinem Verständnis doch mit in die Datei eingebacken wurde? Hat diesbezüglich jemand eine Idee?
SMTP Empfang?! Auf einen David Server?
Na klar. Geht; allerdings muss man dann den Server nach außen halt ein bisschen mehr exponieren. Außerdem i. d. R. nur sinnvoll, wenn man eine feste WAN-IP hat.
Im David Admin oder am Client möglich?
Im Client. Symbolleisten -> Hauptfenster -> Grundfunktionen.
Mann, hier ist irgendwie gerade der Wurm drin. Seit heute Morgen (oder vielleicht auch schon seit dem neusten Rollout, habe länger keine Termine mobil angelegt) folgendes Phänomen:
Ich erstelle über den User-Account, der seit Jahren problemlos läuft, auf einem iOS-Gerät einen neuen Termin. Der wird auch brav übermittelt. "Teilnehmer" wird auf "Ohne" belassen. Kurz darauf habe ich aber im Ein- und Ausgang plötzlich eine Besprechungsanfrage, auf dem iPhone ploppt eine Nachricht "Vor 17389 Tg.: Einladung von... 1. Januar 1970 00:00". auf. In den Besprechungsanfragen im Ein- und Ausgang ist das korrekte Datum hinterlegt, allerdings sind das keine "echten" Besprechungsanfragen (ich kann nichts bestätigen oder ablehnen), sondern quasi einfache Mails.
Ich habe: Den Account auf dem iPhone komplett gelöscht, dann im David Admin auch das Gerät und die ActiveSync.db entfernt. Konto neu eingerichtet -> "Accountinformationen konnten nicht überprüft werden". Kurzer Gegencheck auf dem iPad: Geht alles, muss also am iPhone liegen. Netzwerkeinstellungen zurückgesetzt, danach konnte das Konto problemlos eingerichtet werden. Es wird auch alles brav abgeglichen: Kontakte, Kalender, Aufgaben, E-Mails. Aber wo kommen jetzt diese Pseudo-Besprechungsnanfragen her? Die erscheinen übrigens auch, wenn ich am iPad einen Termin erstelle. Ist also Davids Schuld.
Jemand eine Idee? Oder das zumindest schonmal gehabt?
Versuch mal nicht den Ordner oben in der Übersicht zu verknüpfen, sondern unter dem Servernamen den Ordner. Das geht bei mir.
Ich sag's ja, manchmal ist man einfach nur blind. So wie von dir beschrieben klappt's einwandfrei, danke! ![]()
Moin,
ich stehe (mal wieder) gedanklich etwas auf dem Schlauch. Um einem User einen Ordner zu verknüpfen (z. B., damit auf diesen auch via ActiveSync zugegriffen werden kann) geht man ja im David Client hin und sagt "Als Verknüpfung erstellen". Richtig? Glaub' schon. Nun möchte bei einem Kunden der Chef aber auch "Unverteilt" verknüpft haben, falls dort irrtümlicherweise Einträge auflaufen, die nicht zugeordnet werden können. Aber obwohl der User Domänen-Admin ist und sowohl auf Dateisystem-Ebene als auch in David alle Rechte hat, erscheint die Option "Als Verknüpfung erstellen" beim Unverteilt nicht.
Tante guugel sagt: "Bei dem Archive Unverteilt handelt es sich um ein globales Archive, welches standardmäßig nicht im David.InfoCenter Web angezeigt werden kann. Jedoch gibt es die Möglichkeit, eine Verknüpfung dieses Archives zu erstellen, sodass dieses als Unterarchive von Verknüpfungen angezeigt wird. Auch ist es möglich, bei gehaltener Strg+Shift-Taste das Archive Unverteilt z.B. unter den Eingang eines Benutzers zu ziehen und so hier eine Verknüpfung zu erstellen. So kann dieses Archive auch im David.InfoCenter Web angezeigt werden."
Klappt nur leider beides nicht. Bei Strg+Shift wird mit gleich per durchgestrichenem Kreis angezeigt, dass keine Verknüpfung erstellt werden kann. Und der Menüpunkt ist wie gesagt einfach nicht da.
Der Witz ist, ich hab' die Verknüfung auf Unverteilt in unserer eigenen Installation auch, es muss also mal funktioniert haben - neu erstellen kann ich die aber ebenfalls nicht.
Bitte keine Grundsatzdiskussionen zum Thema "In Unverteilt darf nichts ankommen", und man kann das natürlich über eine Verteilregel alles in einen Ordner schmeißen etc. pp. - mich würde nur interessieren, ob ich hier einen gedanklichen Fehler mache oder die Verknüpfung von "Unverteilt" einfach nicht mehr vorgesehen ist? Also auch nicht mehr per Umweg, wie früher?
Merci! Werde mich bei beiden mal umschauen.
Ein Zertifikat kauf mal einmal für z.B. drei Jahre (27€) und gut ist, und ich kann es ohne großen Aufwand
für andere Dienste verwenden.
Mal doof gefragt: Wo bekommt man das für diesen Preis? Eine spontane Recherche ergab gerade ca. 100 Euro im Jahr - ist natürlich noch immer nicht die Welt, aber schon eine Schallgrenze, bei der manche Kunden meckern könnten (zumal es ja gar nicht so einfach ist, einem normalen Anwender zu erklären, wozu ein Zertifikat überhaupt gut ist).
PS: Tobit Verkauft keine Webserver Zertifikate, sondern eMail (S/MIME) Zertifikate (von D-Trust).
NOCH nicht. Ich denke, denen ist schon bewusst, dass da was passieren muss - wenn man ein selbsterstelltes Zertifikat in der Webbox und eine dynamische IP hat, bekommt man den Webaccess über https ja zum Beispiel nur noch übers Wegklicken vieler fieser Warnmeldungen aufgerufen. Gut möglich, dass neuere Versionen von iOS und Android da auch wählerischer werden. Mein Tipp ist, dass Tobit demnächst eine integrierte Lösung anbieten möchte, wie schon mit SPAM-Filter, Virenschutz, ePost, Mail-Zertifikaten usw. - nur wird diese Lösung nicht kostenlos und somit nicht auf Let's Encrypt basieren.
hatte ich auch, aber keine hängende letsencrypt.exe
Ich denke, das lag bei mir daran, dass die letsencrypt.exe in einen Fehler gelaufen ist und "versteckt" auf einen Tastendruck wartete o. ä.. Kann ich nicht mehr nachvollziehen oder reproduzieren, kam vermutlich vom intensiven Herumspielen (einmal lief der Update-Batch sogar parallel doppelt, schluck...)
Ansonsten auch von mir noch einmal herzlichen Dank an alle Beteiligten.
Definitiv! Richtig gute Aktion! ![]()
Meiner Meinung nach ist es ein Trauerspiel, dass Tobit dies nicht selbst anbietet.
Zumal der Gedanke ja offensichtlich schon vorhanden war - eigentlich kann's nicht so schlimm sein, das in die Webbox zu implementieren. Wenn man böse denkt, könnte es natürlich sein, dass kostenlose Erweiterungen nicht erwünscht sind und man lieber selbst Zertifikate anbieten/verkaufen möchte. Oder man hält die Vorarbeit mit dem Setzen von A-Record bzw. CNAME für zu support-anfällig. Keine Ahnung.
Hm. Komisch, dass es noch so viele Probleme gibt. Bei mir läuft das Update einwandfrei jede Nacht durch
Bei mir gab's Probleme beim Start der Webbox, das konnte ich aber mit einer kleinen Pause vor dem Neustart des Dienstes beheben.
Ferner hängt der Task zum Ende hin fest; beim manuellen Aufruf bleibt das Konsolen-Fenster geöffnet. Soweit ich es erkennen konnte, liegt das an der python.bat und dem Abschießen der pyhton.exe per taskkill. Wenn ich das in eine eigene Aufgabe auslagere, klappt es zumindest beim manuellen Aufruf. Werde das heute Nacht mal automatisch laufen lassen.
Dann gab's (hier) das Problem, dass die letsencrypt.exe immer noch aktiv war und ich sie manuell per Taskmanager beenden musste. Da fiel mir irgendwann auf, dass im Taskmanager noch ganz viele "Windows Befehlsprozessor"-Einträge herumhingen. Und siehe da: Wenn ich jetzt letsencrypt.exe in der Kommandozeile aufrief, gab's statt irgendeiner Reaktion nur die Meldung, dass die Side-by-Side-Konfiguration ungültig sei und das Programm daher nicht gestartet werden könne... War natürlich glatt gelogen. Nach dem Beenden aller "Befehlsprozesse" lief letsencrypt.exe wieder ordnungsgemäß.
Der Haken beim Update-Script ist, dass man im Zweifel nicht unbedingt mitbekommt, wenn der Aufruf der letsencrypt.exe fehlschlug - die Dateien sind ja schon da und werden im weiteren Verlauf des Batches wieder zusammenkopiert und in die Webbox überstellt. Ob da evtl. beim Abruf etwas in die Hose ging, erfährt man erst, wenn nach 90 Tagen immer noch das alte Zertifikat im Verzeichnis liegt. Schön wäre es daher, wenn man letsencrypt.exe zu einer Protokolldatei überreden könnte. Das sollte funktionieren, indem man in der letsencrypt.exe.config im Abschnitt <appsettings> Einträge ergänzt, z. B. <add key="serilog:write-to:RollingFile.pathFormat" value="C:\Logs\myapp-{Date}.txt" /> - hat bei mir allerdings noch nicht hingehauen. Die Funktion RollingFile muss wohl in irgend einer Form erst nachgeladen werden.
Dass es durch die David-Version Unterschiede gibt, kann ich mir eigentlich nicht vorstellen. Das Script kümmert sich ja gar nicht um David, sondern schiebt der Webbox nur eine neue wbcert.pem unter... Windows Server 2012R2 habe ich auch laufen.
Am Update verschluckt sich das System bei mir noch. Heute Morgen war die Webbox beendet und ein Task "Letsencrypt" lief; nach dessen "Abschuss" im Taskmanager wurde das Zertifikat neu geschrieben, und die Webbox ließ sich wieder ganz normal starten.
Mit dem Bugfixing tue ich mich leider schwer, denn das Script läuft bei manuellem Anstoßen problemlos durch - bis auf die Tatsache, dass die Webbox nicht gestartet wird! Ich verwende übrigens stylistics' "Batch-Aufruf-Batch" und die modifizierten Scripte.
Lasse ich die Ausgaben der Befehle in eine Protokolldatei schreiben, und starte die Aufgabe manuell (nicht per Doppelklick auf die Datei, sondern per Rechtsklick in der Aufgabenplanung), so wird mir ebenfalls alles korrekt angezeigt. Lediglich bei der Zeile "NET START "DavidWebBox" >> c:\ssl\updatelog.txt" steht anschließend in der updatelog.txt gar nix. Konsequenterweise wird wie gesagt die Webbox nicht gestartet. Seltsam.
Das könnte man natürlich notfalls mit einem Zusatztask erledigen, der 5 Minuten nach der Erneuerung läuft. Aber das festhängende letsencrypt.exe heute Nacht macht mir schon Sorgen.
Mal naiv gefragt: Die Erneuerung muss doch nicht täglich laufen, oder? Man könnte das Ganze theoretisch auch alle 3 Monate manuell anstoßen? Zum Beispiel im Rahmen eines Wartungsvertrages als humanoider Taskplaner? ![]()
Ich antworte mir mal selbst (echt ätzend, diese Leute, die erst im Forum fragen, statt selbst eine Runde zu googlen, hüstel...)
CNAME-Eintrag heißt das Stichwort. Diesen für die Subdomain ebenfalls setzen, schon läuft's. Ich bin begeistert, ganz ehrlich.
Also, erstmal multiple "Daumen hoch" an alle Beteiligten, das ist echt genial - wegen solcher Aktionen machen Communities wie diese richtig Spaß! ![]()
Bei mir lief das Script jetzt auch sauber durch. Beim ersten Versuch hatte ich übersehen, dass die erzeugte Zertifikats-Datei 0 Bytes groß war, damit wollte die Webbox irgendwie nicht. Komisch. ![]()
Nun hab' ich aber dennoch weiterhin Probleme, nachdem alles gemäß Anleitung konfiguriert wurde, allerdings hängt es vermutlich nicht am Script oder dem Zertifikat. Wäre nett, wenn ihr mir hier geistig kurz auf die Sprünge helfen könntet: Die Subdomain mail.{meinedomain}.{tld} habe ich bei meinem Provider (Strato) ordentlich eingerichtet, aber die Abfrage z. B. auf SSLLABS.COM findet das Zertifikat gar nicht erst. Ein PING auf die Subdomain fördert dann auch zu Tage, woran es (meiner Meinung nach) liegt: der geht nämlich immer noch auf die 81.169.145.78, also einen Strato-Server und nicht auf die von mir eingetragene IP. Lustigerweise funktioniert es allerdings, wenn ich im Browser die Subdomain in der Adresszeile eintrage - dann kommt der David-Logon. ABER nur bei http:// - wenn ich ein https:// voranstelle, meckert der Browser sofort, dass keine sichere Verbindung möglich ist.
Mache ich an anderer Stelle einen Denkfehler, oder spuckt mir hier tatsächlich Strato mit einer "halbherzigen" Umleitung der Subdomain in die Suppe? Der Umleitungstyp ist übrigens "Proxy", nach meinem Verständnis auch der einzige, der Sinn ergibt. Zur Auswahl stehen noch frame, http und share gallery.
Und ferner, mal ganz blöd gefragt: Ist diese Form der Nutzung auch möglich, wenn man eine dynamische WAN-IP hat? Im ersten Anlauf habe ich als Weiterleitungsziel der Subdomain einfach meine dyndns-Adresse eingetragen, das wurde auch "geschluckt". Bei den Versuchen jetzt ist allerdings die aktuell gültige IP hinterlegt, und es mag trotzdem nicht rennen.
Bin für jeden Tipp dankbar & schönes Wochenende! ![]()