Beiträge von nordtech

Zitat von cossys

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

Zitat von cossys

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.

Zitat von cossys

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/domains/…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.

Zitat von wordplex

Der SMTP-Eintrag im Postman ist nicht die Domain "fred.de", sondern die interne IP des David-Servers

Und wie sieht's unter System -> Allgemein -> Domäne aus? Da musst du fred.de afair ebenfalls rauslöschen, damit sich David nicht grundsätzlich für diese Domain zuständig fühlt.

Nachrichten, die David nicht konkret einem Benutzer zuordnen kann, landen normalerweise im "Unverteilt"-Archiv. Um das zu verhindern, können im David Admin Verteilregeln/Verteilvorlagen definiert sein, man gibt im Grabbing-Server-Postfach eine Zieladresse an oder im Unverteilt-Archiv werden Verteilregeln angelegt. Oder man gibt einem User einfach als (zusätzliche) eingehende Mailadresse die info@.

Das ist in deinem Fall nicht das Problem, da lt. Eingangsprotokoll die Nachrichten ja offenbar dort hinkommen, wo sie sollen. Dennoch wäre es gut, zu dokumentieren, warum das passiert (s. o.) bzw. wo die Verteilung konfiguriert ist.

Ist die im Admin angezeigte Datei denn auf Dateisystem-Ebene da? Also, wenn du im Explorer nach \\server\david\archive\user\10008010\in\I44227AF suchst, taucht da was auf?

Erster Impuls ist immer, nach einer Verteilregel im Eingang des Users zu schauen - ist da ggf. definiert, dass Nachrichten mit der Verteilkennung "info@" in einen Unterordner verschoben werden? Achte dabei auch auf die Dateisystem-Berechtigungen in diesem Eingang - fehlen diese, und man schaut als ein anderer User drauf, "verstecken" sich die Verteilregeln unter Umständen. Wenn ansonsten keine Regeln definiert sind, kannst du testweise mal die archive.urt im Eingang umbenennen. Ans Regelwerk kommst du, indem im David Client(!) im Navigator ein Rechtsklick auf den Eingangs-Ordner und dann "Regeln..." gewählt wird. Nicht den großen Shortcut in der Favoritenleiste nehmen, da klappt das nicht.

Standardmäßig haben Benutzer das Recht, Verteilregeln anzulegen, und je nach Konfiguration ploppt beim Löschen von Nachrichten ein Assistent auf, um bestimmte Konstellationen dauerhaft zu blockieren. Auf diese Weise bauen sich Anwender unbewusst gerne mal Regeln, die Mails an bestimmte Empfänger ungefragt in den Papierkorb schieben - wenn sie den Assi einfach nur durchklicken ohne richtig zu lesen.

Möglich (aber bei diesem Fehlerbld eher unwahrscheinlich) ist ferner eine defekte archive.dat (Nachrichten-index). Die könnte man reparieren bzw. neu aufbauen lassen, aber schau am besten erst einmal nach Verteilregeln im User-Eingang.

Zitat von AdminDV

Leider ist das Upgrade von unserer Version auf die neueste zu teuer

Kleiner Praxis-Tipp: Fragt ggf. mal bei einem Tobit-Händler an, was eine Neulizenzierung kostet. Ich hatte schon mehrere Kunden, bei denen wir im Rahmen der Erneuerung gleich "ausgemistet" haben, typischerweise durch den Entfall diverser Port-Lizenzen für ehemalige Faxnummern, und mit ein bisschen Rabatt war die Aktion dann gleich deutlich günstiger als ein offizielles Update.

Der "Dark Mode" sieht leider imho noch schlimmer aus als die weiße Oberfläche, da sind außerdem z. B. die Spaltenüberschriften (schwarz auf Anthrazit) nicht mehr lesbar. Ja, ich weiß, ist beta. Bisserl farbig oder zumindest wieder in einem Grauton wäre mir die Sache trotzdem lieber.

Oder: Warum nicht gleich so machen wie etwa bei Softmaker Office? "Klassische Optik" als Option, dann sind alle glücklich... Kann ja unter der Haube gerne alles "schön neu" bleiben.

Zitat von wordplex

Eure Begeisterungen scheinen sich ja alle wieder in Grenzen zu halten

Erstmal testen. Die neue Option im Editor "Einfacher Zeilenumbruch per ENTER (statt Absatzwechsel)" ist jedenfalls schön, damit werden wir etliche Kunden besänftigen können.

Zitat von riawie

Leider haben die meisten von uns [...] nicht erkannt wie schnell der Zug da rollt und es versäumt

Sorry, aber: Nein. Die Seite, die hier MAL WIEDER was "versäumt" hat, ist eindeutig der Hersteller. Es wäre ein Leichtes gewesen, den Fachhändlern mitzuteilen: Hey, wir haben hier was Neues in der Pipeline, schaut euch das an, der Zeitplan für die Entwicklung sieht so und so aus, die langfristige Strategie ist folgende.

Statt dessen wurschtelt Tobit bar jeglicher Außen-Kommunikation vor sich hin, kippt dann der erstaunten User- und Händerschaft ein unausgegorenes Produkt vor dir Füße und sagt "friss oder stirb".

Die Informationspolitik seitens Tobit ist seit Jahren eine absolute Katastrophe, sicherlich auch dadurch bedingt, dass man partout an den selbst entwickelten Kanälen festhalten will, statt sich das Leben einfach zu machen. Früher[tm] gab es mal für ein paar Wochen den Ansatz, den Händlern einen regelmäßigen Newsletter per E-Mail zuzusenden. Hat vermutlich zu gut funktioniert, oder es kam (oh Gott!) zu viel Feedback von den Empfängern. Wurde also eingestampft, und seitdem ist Funkstille. Vermutlich erwartet die Chefetage, dass man regelmäßig zur Pushcon pilgert, nur um da am Rockzipfel eines Großkopferten ein paar Info-Bröckchen zu erhaschen.

Sorry für den Rant, aber diese ganze Sache mit den unterschiedlichen Clients ist ein Musterbeispiel dafür, wie man es nicht machen sollte. Wütende Kunden rufen bei uns(!) an und fragen, wie man xyz wieder zurückstellt, und wir müssen dann sagen: "Öhm, ja, sorry, dass der Modern Client jetzt plötzlich überall Standard sein soll und der Classic nicht weiter entwickelt wird, wissen wir leider auch erst, seit wir heute die Release Notes gelesen haben". Das kann's doch nicht sein.

Zitat von r.stelzner

ist ein Update von David 12 auf David 3 zu empfehlen oder könnte sich das System arg verhaspeln?

Ziemlich problemlos, abgesehen von der geänderten Optik hat sich technisch von 12 auf 3 wenig getan. Und die Änderungen die es gibt, betreffen eh die einzelnen Programm-Module sowie den Client. Die Gefahr des Verhaspelns hingegen besteht eher im Archivsystem - und gerade da gab's ja wie ausgeführt in den letzten Jahren (ich würde sogar fast sagen: Jahrzehnten) keine grundlegenden Änderungen.

Die reine Datenmenge ist beim Umkopieren nicht unbedingt relevant, sondern, wie viele einzelne Dateien dahiner stecken. Wenn die User aber nicht gerade permanent 20-MB-Anhänge durch die Gegend senden, wird das bei 30GB auch eine stattliche Dateianzahl sein. Da ist das Migrationstool dann tatsächlich eine ziemliche Spaßbremse, da es jede Datei einzeln anpackt.

Also, manuelles Umkopieren (ggf. per Strongbox) ist vermutlich passender. Bei den Archiven kann man per arcutil auch händisch den Servernamen ersetzen lassen, das hab' ich schon ein paar Mal gemacht. Wenn du allerdings die komplette Installation 1:1 kopieren möchtest, dann wird das mit dem Anpassen fummelig. Das würde ich mich nicht trauen. Da ist's auf jeden Fall besser, wenn wie von riawie beschrieben, IP und Servername gleich bleiben.

Um die Verwirrung perfekt zu machen: Eine Misch-Strategie ist natürlich auch möglich. Also mit dem Migrations-Tool starten, da aber die größten User/Archivbrocken ausklammern und jene anschließend per Strongbox-Restore manuell zurückspielen. So bekommst du das Grundgerüst automatisch auf den neuen Servernamen angepasst und kümmerst dich um den Rest selbst.

Viele Wege führen nach Rom. Man kann in der Tat alles machen, was du oben beschreibst. Bei der Strongbox-Variante kommt es darauf an, was ihr übernehmen wollt. Wenn es nur um die User-Archive geht, sollte das auch bei unterschiedlichen Versionen kein Problem darstellen, da sich an der Verzeichnisstruktur und den Dateiformaten "seit Ewigkeiten" nichts geändert hat.

Sofern es sich um Installationen mit eher überschaubarem Datenbestand handelt, bevorzuge ich persönlich das Migrationstool. Das ist kostenpflichtig, und wimre kann nur ein Tobit-Partner eine entsprechende Lizenz erwerben. Ist aber vom Preis her kein großer Faktor. Man hat bei der Migration per Tool den Vorteil, dass auch alle anderen Komponenten wie z. B. eine Webbox-Konfiguration usw. übernommen werden. Dafür arbeitet das Teil aber eher gemächlich, und wenn man Pech hat, bricht die Migration mittendrin ab und man darf erstmal auf Fehlersuche gehen.

Welche Variante für euch die beste ist, hängt ab von der Datengröße der Archive und vom Umfang der Konfigurationen.

Auf dem Hyper-V-Host läuft ein XEON E5-2650 v3, die VM hat statisch 8GB RAM, Windows Server 2012R2.

Mich würde aber wie gesagt eher eure Praxiserfahrung interessieren, bzw. wie viele ActiveSync-Geräte parallel angebunden sind.

Moin,

mal wieder ein Frage in die Runde: Wie groß sind so eure größten David-Installationen, insbesondere in Bezug auf die Webbox/Active Sync?

Hintergrund der Frage ist ein Kunde, bei dem wir nur den David betreuen, nicht die Hardware. David läuft in einer eigenen VM, und die Webbox verursacht durchgehend zwischen 50 und 90% CPU-Auslastung. In David konfiguriert sind 110 Benutzer, viele davon per Smartphone (+ Tablets + einige Outlooks) angebunden. So kommen wir momentan auf 55 aktive ActiveSync-Verbindungen. Ältere (nicht mehr genutzte) Geräte haben wir im Admin schon weggelöscht, aber die haben ja vermutlich eh keinen Anteil an der Last.

Konkret gibt es Probleme mit dem Abgleich: Manche neue Einträge in verknüpften Kalendern etwa kommen auf den Smartphones erst mit großer Verzögerung oder auch gar nicht an. Wir haben leider keine Möglichkeit, auf die zugewiesenen Ressourcen in Hyper-V zu schauen, tippen aber angesichts der hohen CPU-Last derzeit auf "die Webbox ist überfordert und kommt nicht recht hinterher".

Meint ihr, dass das Problem durch Zuweisung von mehr CPU-Power gelöst werden kann? Oder stößt David da ggf. prinzipiell an Grenzen? Wie viele aktive User und ActiveSync-Gerät habt ihr am Start?

Zitat von riawie

beim auslaufen der SiteCare werden auch die MIS Dienste und damit der Virenscan für eingehende Mails abgeschaltet.

Bist du da sicher? Wir haben einen Kunden am Start, bei dem MIS (kostenpflichtig) aktiv sind, aber kein Sitecare!

Man erwirbt bei David prinzipiell immer eine Lizenz, die dauerhaft nutzbar ist. Sitecare ist eine Art Software-Wartung, die regelmäßige Updates garantiert. Aber wie lycra schon schreibt, das Grundsystem an sich läuft auch ohne Sitecare einfach weiter.

Kleine Ausnahmen gibt es bei Sonderfunktionen, z. B. ist auch der automatisierte Bezug von Zertifikaten über Let's Encrypt an ein aktives Sitecare gebunden.

Wenn du im David Admin ganz oben auf "David" klickst, siehst du wichtigsten Infos zur Installation, dort gibt's auch einen Link zu https://david.tobit.software/administration - das ist das aktuelle Portal, auf dem du den Sitecare-Status usw. einsehen kannst. Zur Anmeldung nimmst du die Lizenznummer, diese besteht aus 5 Blöcken á 5 Zeichen. Die ersten beiden Blöcke sind die Site-ID, der dritte Block das Kennwort (sofern der Kunde das nicht geändert hat).

Ja, "Message Identification takes long" ist mir auch schon mehrfach bei Kunden aufgefallen. Da das Phänomen bei Systemen in unterschiedlichsten Regionen und mit schnellen Anbindungen auftritt, nehme ich mal an, dass das Problem auf Tobit-Seite liegt.

My 2 cents: Simples Feedback sollte man auch ohne Anmeldung abschicken können - es hat ja nicht jeder User Lust, sich zu exponieren oder sogar extra ein Konto dafür anzulegen.

Für das Fenster an sich wird wohl MS Edge Webview2 genutzt. Killt man einen der Tasks, während das Fenster offen ist, gibt's eine Fehlermeldung, die der obigen sehr ähnlich sieht. Von daher vermutlich ein Problem in der Richtung - aber wie man's konkret behebt, kann ich leider auch nicht sagen.

Hotfix #353201 (15.06., 120 MB) ist draußen, behebt ein Problem mit dem Start des Classic Clients.