Nach dem Bestätigen kommt trotzdem wieder der Fehler:
Hast du das Zertifikat zusätzlich, wie von riawie in Beitrag 25 beschrieben, in den Zertifikatsspeicher des Smartphones importiert?
Welches muss ich denn wohl da bestellen?
In der Auswahl wäre das einfache Sectigo PositiveSSL vermutlich ausreichend. Du brauchst ja nur ein ganz einfaches für "Domain Validation".
Wie kann ich das denn bearbeiten
Bau dir einfach schnell ein neues.
Mach eine Sicherheitskopie eures jetzigen Zertifikats, vermutlich \David\Apps\Webbox\Code\wbcert.pem
Dann \David\Util\Windows\TLSCERT\tlscert.exe aufrufen und im Tool folgende Werte hinterlegen:
Certificate Type = Self Signed
Key Length = 2048
Country Name = DE
State or Province = Bundesland
Locality Name = Stadt
Organization Name = Firmenname
Organizational Unit = n/a
Common Name = EXAKTE (Sub)Domain David
Contact e-Mail = Mailadresse
Optionale Attribute: Leer lassen, Valid Days kannst du dir aussuchen (z.B. 366)
Wichtig ist dort halt, dass "Common Name" exakt der Adresse entspricht, über die du per Smartphone drauf zugreifst. Also z. B. eure dyndns-Adresse, ohne http(s)-Präfix. meindavidserver.dyndns.org etwa.
Die über das Tool erstellte Datei speicherst du als WBCERT.PEM in \David\Apps\Webbox\Code ab und startest dann die Webbox neu.
Schön finde ich das trotzdem nicht, auch wenn's funktioniert. Der Kostenaufwand für ein offiziell beglaubigtes Zertifikat ist ja nun wirklich minimal. Aber gut.
Ich will ja eigentlich kein Zertifikat für eine Webseite
Doch doch, in diesem Fall schon. Du willst ja damit keine E-Mails signieren/verschlüsseln, sondern ankommenden Clients nur bestätigen, dass sie den korrekten Host zu fassen haben. Gut, ist in diesem Fall nicht wirklich eine "Webseite", aber eben ein Dienst-Host.
Du brauchst: 1) Einen Hostnamen, der auf eure Adresse zeigt, da Zertifikate nicht für IP-Adressen ausgestellt werden können (nützt dir bei dynamischen Adressen eh nix). Wie gesagt, ich meine im Hinterkopf zu haben, dass Let's Encrypt keine Zertifikate für dyndns.org-Adressen ausstellt, bin da aber nicht ganz sicher. Falls doch, kommt der Tipp von ComputerManni ins Spiel, evtl. ist es schlau, sich bei Strato ein Billigpaket mit dyn. Host nur für diesen Zweck anzuschaffen.
2. musst du dann für diesen Host ein Zertifikat anfordern. Für LE geht das nur "zu Fuß" über die oben verlinkten Methoden. Ich hab' das seinerzeit offen gestanden als zu kompliziert empfunden und mir statt dessen ein einfaches Zertifikat bei GlobeSSL geholt ("Globe Standard SSL"). Einfache Domain Validation (DV), mehr brauchst du an der Stelle nicht. Andrere Anbieter gehen natürlich ebenso, GlobeSSL ist relativ billig. Für den Bezug erstellst du auf dem David-Server ein certificate request, z. B. mit der TLSCERT.EXE im Util-Verzeichnis. Mit dem ausgestellten Zertifikat musst du dir anschließend eine .pem-Datei bauen und diese der Webbox "unterjubeln".
Anschließend sieht es im Browser dann im Idealfall so aus, wenn du die Webbox-Adresse von extern aufrufst:
OK, im Screenshot steht neben der URL ein Ausrufezeichen, und es handelt sich um einen dyndns.org-Host (klappt LE damit überhaupt? Ich meine mich zu erinnern, dass wir bei allen Kunden auf andere Anbieter umgeschwenkt sind oder ein Konstrukt mit CNAME-Weiterleitung gebaut haben, weil die Ausstellung direkt auf xyz.dyndsn.org nicht funktionierte).
Ich gehe weiterhin davon aus, dass das Zertifikat Schuld ist.
Auf dem A40 funktioniert er weiterhin
Ich glaube nicht, dass wir hier weiter kommen, solange du uns nicht verrätst, welches bzw. welche Art von Zertifikat die Webbox nach außen weitergibt. Bitte:
Im Browser david aufrufen und schauen was das Zertifikat sagt.
Ports passen soweit, eingehend muss für ActiveSync nur 443 ankommen. Ich tippe auch zu 90% auf ein Zertifikats-Problem. Vielleicht ist ein Gerät da toleranter als das andere - früher[tm] war es gängig, dass auch selbstsignierte Zertifikate geschluckt wurden, seit einigen Jahren allerdings wollen die meisten Systeme ein offizielles.
Was bekommst du denn im Browser angezeigt, wenn die den Webaccess öffnest und mal in der URL-Zeile auf das Schloss klickst?
Zertifikat kostenlos wird schwierig, ginge wohl über Let's Encrypt, habe ich aber auf manuellem Wege nicht mehr ausprobiert, seit die Funktion in David eingebaut ist (für Installationen mit aktivem Sitecare).
Bei Kunden ohne Sitecare nehme ich i. d. R. ein günstiges Zertifikat z. B. von GlobeSSL. Das liegt bei knapp 10 Euro brutto für ein Jahr und ist damit auch für kleine Installationen verschmerzbar.
Ja, beim Weiterleiten scheinen Anmeldung und Verschlüsselung verloren zu gehen, egal, was im Postman für den Smarthost konfiguriert wird. "Gut", dass es auch bei anderen auftritt, dann hoffe ich mal auf einen zeitnahen Hotfix.
Nein, das läuft über eine Weiterleitung im Postman. Der Auftrag erscheint im "In Transit" als "Rundsendung" (obwohl nur an einen Empfänger gerichtet - weiß nicht, ob das vorher auch schon so war), und wird kurz darauf vom Provider mit obiger Meldung abgelehnt.
Sendemethoden etc. sind nicht definiert, die Mail muss mit den Standard-Postman-Einstellungen auf den Weg gehen.
Wie gesagt - bringe ich aus dem David-Client eine Mail mit identischem Absender und Empfänger auf den Weg, läuft's. Schon sehr merkwürdig.
Gestern, vor Rollout 411, funktionierte das noch einwandfrei. 
Nun habe ich schon wieder etwas Angst, was bei den Kunden passiert, wenn sich dort am WE David aktualisiert...
Nach dem Update klappt der Mail-Versand aus meiner Warenwirtschaft plötzlich nicht mehr. Verschickt wird per Smarthost, Strato sagt aber "falscher Absender". Bringe ich die Mails manuell auf den Weg, klappt alles, mit identischem Absender und Empfänger.
Aus der Meldung des Strato-Servers werde ich in diesem Zusammenhang nicht schlau, der Versand erfolgt immer über das selbe Smarthost-Konto:
:1: 250-smtp.strato.de greets xx.xx.xxx.xxx
:1: 250-ENHANCEDSTATUSCODES
:1: 250-PIPELINING
:1: 250-8BITMIME
:1: 250-DELIVERBY
:1: 250-SIZE 104857600
:1: 250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5
:1: 250-REQUIRETLS
:1: 250 HELP
:1: MAIL FROM:<info@xxxxxxxxxx.xx>
:1: 530 5.7.0 User not authenticated
(1) SMTP Server: Wrong Sender Name!
:1: RSET
:1: 250 2.0.0 RSET OK
:1: QUIT
:1: 221 2.0.0 closing connection
(1) Mail Transmission abortedKann das jemand reproduzieren?
Gnah! Mal wieder zu kompliziert gedacht. 
Die Bereinigung erfolgt simpel über die Eigenschaften des Archivs "World Wide Web" -> "Postlagernd". Da ist standardmäßig im Reiter "Dienste" ein max. Eintragsalter von 10 Tagen hinterlegt.
In der Admin-Hilfe steht: "Beachten Sie, dass sich bei Nutzung dieser Funktion zum Teil erhebliche Datenmengen im Postlager-Ordner ansammeln können. Aus diesem Grund ist für den hierzu standardmäßig verwendeten Ordner (»WWW- Postlagernd«) eine automatische Bereinigung nach zehn Tagen voreingestellt."
Wo man die Dauer ändern kann, weiß ich spontan nicht - würde mal auf eine .ini tippen. Wobei mir weder in der david.ini noch in der webbox.ini ein passender Eintrag begegnet ist. Vielleicht wurde bei euch der entsprechende Wert hochgesetzt?
Aber bei einem so langen Zeitraum und den von dir beschriebenen anderen Problemen wird es vermutlich eher grundsätzlich an der Bereinigung haken.
selbstsigniertes Cert ist auch vorhanden
Nunja, ist das vielleicht der Grund? Mobilgeräte mögen ja schon seit einiger Zeit nur noch offizielle Zertifikate, vielleicht ist das bei neueren Outlook-Versionen auch so? Ich benutze das von David ausgestellte Let's-Encrypt-Zertifikat, damit funktioniert's definitiv.
Eigentlich müsste das nach dem, was ich so erkennen kann, greifen... Daher mal eine "doofe" Frage: Im Reiter "Ziel" ist schon die Aktion definiert, die du haben willst, oder? Also kopieren/verschieben? Oder ist da ggf. "kopieren" angehakt und wartest darauf, dass die Regel verschiebt?
Die "Anzahl Zugriffe" weiter rechts in der Liste werden ebenfalls nicht hochgezählt? Oder ist da zu erkennen, dass die Regel irgendwann früher schon einmal funktioniert hat?
Nun hab' ich extra gerade mal mein Outlook 2019 angekurbelt, um das zu testen.
Zugriff auf David via EAS Funktioniert weiterhin.
Erfahrungsgemäß macht Tobit da nix. Der Ball liegt auch eher bei der Software, die das "false positive" produziert, also beim Hersteller des Virenschutzes. Die Webseite wird vermutlich ja nur als unsicher aufgeführt, weil festgestellt wurde, dass von dort häufig "Schadsoftware" heruntergeladen wird.
Die Konstellation "großer AV-Anbieter" und "Kunde nutzt 'exotische' Software wie David" wird immer hakelig sein. Da hilft nur, mit dem manuellen Schreiben von Ausnahmen gegenzusteuern. Ehe man Kaspersky beigebracht hat, dass z. B. eine Drive-Snapshot-exe nichts Böses tut, bekommt man graue Haare.
An dieser Stelle aber auch erneut Unmut in Richtung Tobit, dass das Client-Update immer neu bezeichnete Temp-Ordner aufmacht: Bei einem Kunden wurde heute C:\Windows\Temp\Package7\clients\windows\dv4ts.exe als Malware erkannt - würde statt "Package7" (die Ziffer ändert sich ständig) einfach "TobitClientUpdate" oder so verwendet, könnte man schön den gesamten Ordner als Ausnahme definieren.
Naja. Obiges trat heute tatsächlich nur auf einem (!) Client auf, Securepoint bzw. Ikarus waren mit der Anpassung offenbar sehr flott.
Ich komm grad ums verrecken nicht drauf wo ich das wieder gerade biegen muss
Alternativ zum Registry-Eintrag: Im Verzeichnis des Classic Clients in DVSMAPI einmal die dvsmapi.exe aufrufen und den Dialog bestätigen. Je nachdem, ob 32 oder 64 bit heißt der Ordner "C:\Program Files\Tobit InfoCenter" oder halt "C:\Program Files (x86)\Tobit InfoCenter".
Ich hab' das bestimmt schon ein Dutzend Mal durch; viele Kunden mögen den Modern Client tatsächlich spontan nicht so besonders. Vermutlich in erster Linie wegen der Optik - ich hatte aber auch schon einen Fall, wo der neue Client aus unbekanntem Grunde ständig hakte und stockte. Mit dem alten ist alles OK.
Ja, eine Strongbox-Sicherung des Kalenders hatten wir schon im Laufe der Kommunikation mit dem Tobit-Support nach Ahaus geschickt. Es hieß damals, mit dem Kalender sei alles OK, aber die können natürlich auch nicht jeden einzelnen Eintrag auf Herz und Nieren prüfen. Wir haben dem Support nun explizit beschrieben, welche Einträge wir in Verdacht haben, vielleicht lässt sich ja was erkennen.
Fürs Protokoll: Wir haben nach unzähligen Versuchen mit Herumschrauben an Hardware, Einstellungen, Smartphone-Clients etc. nun vermutlich die Lösung gefunden. Zumindest idelt die Webbox jetzt die meiste Zeit über, in Spitzen geht's mal auf 2-5% hoch, aber insgesamt deutlich ruhiger.
Dummerweise hatten wir zuletzt "aus Verzweiflung" mehrere Maßnahmen am Laufen, daher ist es nicht exakt möglich, die Ursache zu benennen. Ich denke allerdings, dass es an einem defekten Eintrag in einem für alle User verknüpften Gruppenkalender lag. Den habe ich durch Zufall entdeckt, weil er zeitlich gut zum erstmaligen Auftreten des Problems passte. Dem Eintrag selbst war allerdings nichts anzumerken, er ließ sich normal öffnen. Aber nach Löschen und neu Anlegen wurde es plötzlich zunehmend ruhiger auf dem System.
Schön, dass wir eine Lösung finden konnten. Wieder einmal zeigt sich allerdings, dass David an manchen Stellen keine wirkliche Fehlertoleranz aufweist. Wie z. B. auch beim Outlook-Import oder dem Migrationstool. Wir konnten ferner nicht feststellen, wie es zu diesem defekten Kalendereintrag gekommen ist, der Server hatte keine Abstürze oder Dateisystem-Probleme. Na ja. Hauptsache Problem gelöst, Kunde glücklich.
Ich werd mal bei Plusnet anklopfen
OK, (aller)letzter Versuch: Wenn ihr über den Provider versendet, braucht ihr KEINEN SPF-Eintrag, in dem eure feste IP zusätzlich hinterlegt ist. Die ist AUSSCHLIESSLICH dann sinnvoll, wenn Mail vom Postman direkt per SMTP an den Empfängerserver geliefert werden soll, ohne Beteiligung von IONOS. Wenn du aber schreibst
550 Invalid RDNS entry for WW.XXX.YY.ZZZ (unsere feste IP)
...dann ist es eben NICHT der Fall, dass ihr ausschließlich über den Provider sendet.
Tipp: Stell das entsprechend um, sendet NICHT direkt, sondern NUR über IONOS, setzt den SPF auf die Standard-IONOS-Einträge (vgl. mein Link oben), und rDNS kannst du dann vergessen, weil das IONOS' Bier ist.
Das mit smarthost klingt praktisch - wäre schön, wenn jemand bestätigen könnte, daß das bei IONOS funktioniert
Prinzipiell funktioniert das, kann aber natürlich je nach Vertrag anders sein. Ich habe einen kleinen Kunden mit 3 Postfächern bei IONOS: info@, user1@ und user2@. Die Postfächer werden im Grabbing Server einzeln abgeholt, der Versand erfolgt aber gesammelt per Smarthost, in diesem Falle per Anmeldung mit dem info@-Konto. Klappt reibungslos. Der Vertrag ist ein älterer "Webhosting Premium". Host smtp.ionos.de, Port 587.
BTW: Ich erhalte bei Mail-tester.com mit Versand via Strato, gültigem SPF (nur Strato-Server) und einem David, der über den Provder versendet einen Score von 9,1. Und das auch nur, weil eine einzelne Blacklist gerade was gegen die Strato-Server hat und meine Test-Mail relativ wenig Text im Bezug auf die Signatur-Grafik aufweist (SPAM-Assasin mault). Sonst wäre es eine 10. Mach dir also keinen zu großen Kopp wegen des rDNS. Lass das IONOS' Sorge sein. Setz im Postman (geht ja auch testweise) den Haken bei "Generell über Provider (smarthost) senden", trag ein passendes Konto ein, und sehr wahrscheinlich bist du damit alle Sorgen los.
Du musst den SPF-Record bei IONOS so setzen, dass er auf die Mailserver von IONOS zeigt. NICHT auf eure feste IP!
Sobald SPF korrekt eingestellt ist, wirst du rDNS sehr wahrscheinlich nicht mehr brauchen.
