Beiträge von riawie

Zitat von Roland.K

Da Port 80 für die Zertifikate verantwortlich ist, muss es dann wohl an dem liegen.

Ja, für Challenge response wird einzig Port 80 benötigt, was auch nicht änderbar ist.

Am besten erlaubst Du für kurze Zeit mal das Port 80 auch für die Webbox genutzt werden darf und nicht nur für Let's Encrypt. Dann kannst Du selbst von außen testen ob Du auf Eure Webbox zugreifen kannst. Wenn das klappt muss das Problem entweder in einer Geographischen Zugriffsbeschränkung, in Eurer oder der Firewall Eures Providers liegen.

Das:

Zitat von Roland.K

Ich hab das Zertifikat schon gelöscht, aber auch das hilft nicht.

War übrigens ein großer Fehler, denn jetzt hat Dein Server gar kein gültiges Zertifikat mehr zur Verfügung.
Hättest Du das nicht gelöscht wären dir rund 29 Tage geblieben Dein Problem in aller Ruhe zu lösen. Denn bei Let's encrypt sind die Zertifikate stets 90 Tage gültig, werden aber immer schon nach 60 Tagen erneuert um im Fall das diese automatische Erneuerung aus welchen Gründen auch immer mal nicht klappt ausreichend Zeit zur Reaktion und Fehlerbeseitigung zu haben.

Zitat von nordtech

Sofern die Meldung also nochmals kommt, probier's mit der dann gültigen URL einfach mal aus.

Das kannste knicken.

Diese Datei wird vom David Server nur für einen sehr kurzen Zeitraum zum Abruf zur Verfügung gestellt und anschließend sofort wieder entfernt. Das ist wichtig, weil dieser Challenge Response Prozess eine gewisse Anfälligkeit des ganzen Zertifizierungssystems darstellt.

Sobald man die Fehlermeldung bekommt ist die Datei daher auch schon längst nicht mehr auf dem Server verfügbar. Oder anders ausgedrückt: Das man diese Datei selbst nicht abrufen kann bedeutet nicht das es ein Problem auf dem eigenen David Server gibt.

Auch der gesamte Pfad zu dieser Datei wird nur kurz dynamisch für den Prozess erstellt und anschließend direkt wieder weggeräumt.

Zitat von nordtech

Leider weiß ich aus dem Stegreif nicht, wo David die obige "Verifikationsdatei" auf Dateisyste-Ebene ablegt. Sonst könnte man da ja auch mal schauen. Der Virenscanner auf dem Server hat nicht zugeschlagen?

Die Datei landet tatsächlich kurze Zeit auf der Platte um für die Webbox lesbar zu sein.
Das der Inhalt dieser Datei den Virenscanner triggert ist allerdings sehr unwahrscheinlich, denn dafür dauert der Prozess vom anlegen der Datei, bis der tatsächliche Abruf kommt dann doch zu lange, so das der Virenscanner bei der winzigen Datei längst wieder sein Interesse verloren hätte, egal wie übereifrig der sein mag.

Die Fehlermeldung bei nicht auffindbarer Datei würde übrigens auch etwas anders aussehen und nicht auf reset by peer lauten.

Wenn Euer Server über die DynDNS Adresse problemlos erreichbar ist deutet Connection reset by peer auf ein Firewall Problem hin.

Der Server von Let's encrypt kann die Challenge Response nicht von Eurem David abholen.

Das könnte nun Eure eigene Firewall sein, oder auch ein Problem mit Eurer Internetanbindung sein, das dort z.B. Geo location Eingrenzungen vorgenommen wurden welche verhindern das der gerade genutzte Let's encrypt Server, bzw. aus seinem gerede genutzten Adressbereich auf Euren Anschluss zugreifen darf.

Das ist interessant, denn beim Acrobat DC passiert das nicht.
Versuche ich es jedoch mit dem Acrobat Reader habe ich das gleiche Ergebnis wie Ihr.
Ich habe aber sowohl im Reader, als auch im vollwertigen Acrobat die gleiche Senden als eMail Funktion genutzt.

mal unverbindlich testen geht genau so lang wie Du den neuen Client die Standard Systemeinstellungen für mailto und Co nicht ändern lässt.

Auch danach lässt sich das noch wieder korrigieren, allerdings kannst Du mehreren Diskussionen hier im Forum leicht entnehmen das dies meist nicht reibungslos klappt.

Wenn Du aber den neuen Client von Hand gezielt startest und die bei dessen Start obligatorische Abfrage bezüglich nötiger Anpassungen einfach ablehnst kannst Du den neuen Client problemlos ausprobieren und immer wieder zurück.

Letztlich gehe ich allerdings davon aus das Tobit den alten Client in kürze schlicht aktiv entfernen wird, auch wen es weh tut

Der Return-Path wurde so eindeutig nicht vom David Server erzeugt, sondern von Server des Providers.

bei IONOS wird das ganz gut erklärt:

https://www.ionos.de/hilfe/e-mail/p…kannte-adresse/

Ist also kein David Problem als solches.

Kann man mit dem David Server aber durchaus umgehen, allerdings nur mit einigem Aufwand.
Entweder man nutzt dazu die Tobit Relay Services (kosten Geld) oder man verschafft sich eine ordentliche feste IP Adresse aus einem IP Segment mit guter Reputation, setzt beim Provider passende DNS Records und sendet dann Mails direkt an die Empfänger, statt über Smarthost.

Nein, das kann ich Dir nicht erklären.

Ich hätte das selbst auch gern rein lokal und würde auch in Sachen Videokonferenz via David lieber auf eine rein lokale Authentifizierung setzen.
Da ich Chayns aber nun eh auf den Smartphones für den SmartClient nutze - weil damit die Suche in den Mails bei weitem besser ist als via EAS - habe ich auch keinen guten Grund mehr die Anmeldung am Server im mobil genutzten David Client nicht über Chayns laufen zu lassen.

Rein lokal im Unternehmensnetz arbeitende David Clients, welche den David Server auch via SMB erreichen und ihn rein über seinen SMB Namen ansprechen betrifft das Thema ja eh nicht, da in dem Fall die Anmeldung ja weiterhin komplett über SMB / Active Directory Single Sign On läuft.

Ich hatte diese Woche auch den ersten Fall.

Zum Glück nutzte der schon seit der Corona Zeit Chayns für Video Chats und entsprechend habe ich da dann auch den Login des Clients auf Chayns umgestellt. Zumindest damit läuft es nun ohne Klagen.

Zitat von Heinz

Wurde das auch gehen bzw. wie groß darf die Zahl mit den Minuten sein?

Sind da z.B. 60 Minuten oder mehr möglich?

reicht eine Woche?

Hab ich jedenfalls gerade mal zum Spaß mit @@Termin +10080@@ getestet, der Auftrag wurde einwandfrei zum Versand am nächsten Freitag angenommen

Ansonsten ließe sich noch der David Befehl

@@Archive =>user\100080F0\system\drafts@@

Dazu müsste allerdings die ID 100080F0 aus dem obigen Beispiel durch die tatsächliche UserID des jeweiligen David Nutzers ersetzt werden. Welche Du zu dem Zweck erst mal ermitteln müsstest.

Wir haben das daher damals - als wir sowas genutzt haben schlicht über den eben erwähnten Wartezustand und den Transit Ordner gelöst gehabt

Muss die Mail unbedingt im Entwürfe Ordner landen?

Oder geht es nur darum das sie nicht gleich versandt wird, sondern der Nutzer noch die Chance hat sie zu ergänzen?

Falls ja, dann setze einfach ein @@warten@@ irgendwo in den Nachrichtentext.

Damit landet die Mail dann im Transitordner und bleibt dort so lange stehen bis jemand entweder den Wartestatus aufhebt (Rechtsklick und dann Wartezustand aufheben oder beenden, so genau hab ich das gerade nicht im Kopf) oder aber die Nachricht schlicht per Doppelklick in den Editor lädt und anschließend nach - oder auch ohne - Bearbeitung mit senden abschickt.

Wartende Nachrichten im Transitordner sind standardmäßig nur für den Nutzer unter dessen Kontext sie erstellt wurden und für Administratoren sichtbar, somit sollte das rein funktional eigentlich auch o.k. sein die Nachrichten dort statt im Entwürfe Ordner zu parken.

Das Active Sync an SiteCare hängen würde war schon immer ein Gerücht welches hier im Forum verbreitet wurde, meiner Kenntnis nach aber nie zutraf.

sitecare

• Vollautomatischer Aktualisierungs-Service
• Sofortiger Zugang zu den neuesten Funktionen und Technologien
• Kontinuierliche Evolution in kleinen Schritten ohne Wartungsstau
• Permanente Kompatibilität zu neuesten Betriebssystemen und Geräten

...bringt neben Updates und Let's Encrypt auch noch die Linküberprüfung auf Gefährlichkeit mit.

Link Lookup (Schutz vor gefährlichen Weblinks)

• Erkennt und warnt vor gefährlichen Links in empfangenen Nachrichten
• Wirksamer Schutz vor Einschleusung von Ransomware oder anderer Schadsoftware
• Prüft jeden im david Client angeklickten Web-Link
• Meldet mögliche Sicherheitsrisiken vor dem Öffnen von Links
• Macht versehentliches Ausführen gefährlicher Inhalte quasi unmöglich
• Für alle Nutzer von david mit sitecare generell verfügbar

Mehr hängt da soweit ich weiß nicht dran.

Jetzt hätte ich doch fast den Support vergessen, denn der schriftliche Premium Support ohne Berechnung hängt auch noch an der SiteCare.

Das Problem deutet recht klar darauf hin das zwischendurch der Zeichensatz der Mail verwürfelt wurde.
Mit vollständigen Header Informationen sollte sich das auch nachvollziehen lassen.
Mindestens ein beteiligter Rechner verwürfelt den Zeichensatz der Mail.

für mich sieht das aus als gäbe es bei den betroffenen Nutzern ein Problem mit den Zeichensatzeinstellungen in ihrem System, welche nicht durchgängig konsistent sind.

Meiner Meinung nach lässt sich dem nur sinnvoll auf den Grund gehen wenn man so ein System direkt vor sich hat.

Mein pragmatischer Ansatz - wenn ich hier einen oder mehrere derart betroffene Plätze hätte wäre schlicht die betroffenen Arbeitsplätze vollständig neu aufzusetzen, denn ich hätte schlicht keine Zeit mich so lange mit einem solchen Fehler herumzuschlagen.

jupp, genau so soll es laut der von IONOS inzwischen mehrfach klargestellten Info zukünftig sein.

Hans_F ich würde als IONOS Kunde schlicht beim catchall Postfach bleiben, denn dieser Betriebsmodus ist von den Änderungen ja gar nicht betroffen.

Lediglich IONOS Kunden mit mehr als einer bei IONOS gehosteten eMail Domain, welche auch von allen Domains aus versenden wollen würden etwas ändern müssen. In solch einem Fall müsste schlicht für jede Domain ein eigenes catchall Postfach angelegt werden. Das wäre aber auch David Seitig kein Problem und würde dort einwandfrei so funktionieren das beim Versand immer mit dem korrekten smarthost Postfach welches zur Absender Domain passt versendet wird. Ich habe das einige Zeit mit zwei verschiedenen Providern und dort liegenden unterschiedlichen Domains problemlos betrieben.

Für die ganz einfachen Fälle welche nur eine einzige eMail Domain als Absender nutzen und beim Empfang bislang ein catchall Postfach nutzen ändert sich schlicht nichts, denn das wird weiterhin funktionieren.

Ist der Service Layer des Rollout 415 nur bei uns so instabil, oder auch bei anderen?

TAB-Soft danke für die Info.

Dann hat das Update den Inhalt dieses Eintrag wohl bei uns und lycra schlicht verloren :o

Naja, jetzt geht es wieder und der Support war auch fix bei der Unterstützung
Und für die Zukunft haben wir wieder einen fall mehr der sich bei Bedarf mit Glück über die Forumssuche lösen lässt

ich würde mal denken das es ein Bug ist.
Wobei mich wundert das da überhaupt neuerdings ein Eintrag ist, denn wenn mich nicht alles täuscht gab es das Feld da früher gar nicht und er hat das von der webbox mit übernommen, bin mir aber nicht zu 100% sicher.

lycra guck mal bitte nach ob bei Euch auch der Eintrag Domain Name in der Konfiguration der WebAPI leer ist?

David Administrator:
System > Fernzugriff & Publizierung > david WebAPI (Smart Client) > Rechtsklick > Konfiguration

Der David Support bat mich gerade nach einer Reihe von Fragen um einen Screenshot der WebAPI Konfiguration, dabei ist mir das dann aufgefallen.
Ich hatte dort vorher nicht nachgeguckt, weil ich ja seit gestern - wo noch alles funktionierte - nichts an der Konfiguration geändert hatte.

Nach Eintrag der korrekten Domain funktioniert wieder alles