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.
Du verschickst also Mails über einzelne Postfächer, das ist so OK. Smarthost kommt auf den Provider an, bei Strato zum Beispiel kann man ein beliebiges Postfach aus dem selben Paket nehmen, und darüber dann einfach alle Mails auch mit anderen Absendern (der gleichen Domain) auf den Weg bringen. Wenn's so wie jetzt läuft, brauchst du aber den Smarthost nicht unbedingt.
Aber nochmal: Der SPF-Record hat in dieser Konstellation nichts mit eurer Webbox, eurem Internet-Provider oder euer externen IP-Adresse zu tun. SPF musst du bei IONOS setzen: https://www.ionos.de/hilfe/dom…vermeiden-mit-spf-record/
Wenn du über den Provider (IONOS Smarthost oder Einzel-Postfächer) sendest, brauchst du keinen SPF-Record für die IP der Webbox. Empfänger "sehen" nicht, dass ihr mit David verschickt, für die ist das einfach nur eine Mail, die von einem IONOS-Mailserver stammt.
Wie ihr selbst ins Internet geht, ist in dieser Konstellation wurscht. Das wäre erst interessant, wenn ihr Mails ohne Provider, also per direktem SMTP-Versand auf den Weg bringt. Oder verstehe ich dich an der Stelle falsch? Auch Subdomain & Co. für die Webbox sind nur dann relevant, wenn ihr externe Geräte per ActiveSync anbindet (und auch da im Grunde nur, damit ihr ein gültiges Zertifikat erhalten könnt).
Nö, ganz so schlimm ist das nicht - wenn David erkennt, dass ein interner User die passende Empfänger-Adresse hat, wird auch weiterhin intern versendet.
