Beiträge von wlconsult

Es könnte sein, dass in das Record nicht der "agenturserver.de" reingehört, sondern die Mailserver von Mittwald. Kläre das notfalls mit dem Support dort, ein einfacher Anruf sollte genügen.

Bei IONOS wird z.B. auch nicht die Domäne eingetragen, sondern die MX von IONOS:

v=spf1 include:_spf-eu.ionos.com ~all

Für Mittwald sieht das u.U. ähnlich aus. Der Generator kann das in diesen Fällen nicht erkennen, bei Spacenet z.B. würde Dein durch den Generator erzeugtes Record aber passen.

DKIM ist dagegen nicht unbedingt notwendig, GMAIL akzeptiert die Emails auch nur mit SPF-Record. Das muss aber natürlich passen.

Grüße

Werner

GMail nimmt keine Emails mehr von Emailservern an, für die es kein passendes SPF-Record auf Deiner Domain gibt.

Es kommt darauf an, wie Euer DAVID die Nachrichten versendet: Macht Ihr das mit Smarthost über einen Provider (Strato, IONOS, ...) oder ist Euer DAVID direkt als MX eingetragen und sendet/empfängt direkt?

Prinzipiell muss das SPF-Record beim Betreiber der Domain im DNS Eurer Domain eingetragen werden. Wenn Ihr per Smarthost über den Provider versendet, geht das meist sehr einfach, weil es dafür bei fast allen Providern schon vorgefertigte Konfigurationen gibt, die man meist nur "einschalten" muss.

Wenn der DAVID dagegen direkt als MX tätig ist, dann musst Du das SPF-Record im DNS Eurer Domain als TXT-Eintrag selbst anlegen und die IP-Adresse des DAVID-Servers hinterlegen. Die FAQ der meisten Provider liefern hier immer gute Hinweise.

Du kannst das SPF-Record für Eure Domain überprüfen lassen, bzw. Du bekommst sogar Vorschläge für die in Eurem Fall gültige Syntax unter:

SPF Record Generator - MxToolBox

Viele Grüße

Werner

Dann ist es ja noch einfacher für Euch. Ihr müsst das Tool nur einmalig lizensieren und könnt es dann abgesehen von Eurer eigenen Installation für beliebig viele andere Migrationen nutzen.

Wenn der neue Server einen anderen Namen hat und sich auch noch in einer neuen Domäne incl. neuer User befindet, dann kann auch ich Dir nur dringend raten, den Umzug mit den Server Migration Services von TOBIT (über einen Fachhandelspartner) zu machen.

Den genauen Weg habe ich hier im Forum schon einmal beschrieben:

Beitrag

RE: DavidServer Migration von Win2008R2 zu 2016

Meine letzte Migration war von einem Server 2008 (kein R2, also 32 bit, Rollout 256) auf einen aktuellen Server 2019 Std. mit DAVID.V3-310 , komplett mit neuer Domäne und entsprechend neuen/anderen Usern und z.T. 14 Jahre alten Emails. Das kann man dann nicht mehr so machen, wie es Riawie beschrieben hat (seine Methode funktioniert unter den o.a. Umständen aber sehr gut).

Es gibt da viele Ansätze, die alle schon einmal hier im Forum angesprochen wurden. Ich möchte hier aber mal eine Lanze für…

wlconsult

3. November 2019 um 16:10

Wenn Du die Vorarbeiten selbst erledigst und auch den DAVID schon einmal vorab neu auf dem neuen Server installierst, dann sollte sich ein Fachhandelspartner finden lassen, der für den reinen Umzug mit dem Tool nur einen geringeren Obulus verlangt, weil es dann - abgesehen von der Zeit, die der Transfer der Daten benötigt - praktisch kein Aufwand mehr ist.

ARCUTIL ist eine absolute Krücke für diesen Zweck. Ein kleiner Fehler und Deine Arbeit war umsonst. Außerdem musst Du ja dann immer noch User neu zuweisen und vieles manuell korrigieren.

Wenn Du es mit Bordmittel machen willst (musst), dann kannst Du die Daten der User auch über Strongbox-Images zurückspielen. Allerdings setzt auch das voraus, dass Du den DAVID auf dem neuen Server nicht nur installierst, sondern auch komplett einrichtest. Mit den Strongbox-Images spielst Du ja nur den reinen Datenbestand zurück, nicht aber die Konfiguration des Systems selbst.

DAVID versendet grundsätzlich alle Emails mit UTC +0000 Zeit-/Datumsinformation. Das ist m.W. auch nicht konfigurierbar. In allen anhängenden Systemen ergibt sich in Zusammenhang mit der lokalen Zeitzone dann wieder die korrekte Sende-/Empfangszeit.

Das Problem scheint also eher Euer Archiv zu betreffen, denn wenn ich mir z.B. Mailstore-Server als Archivierungslösung anschaue, wird die UTC-Information dort ebenfalls in die korrekte Zeitzone "übersetzt" und Emails entsprechend dargestellt.

Ich kann Dir die ISO zu Version 3387 (Rollout 335) oder zu Version 3414 (Rollout 337) anbieten. Im Prinzip ist es so, wie QWERTZ schon geschrieben hat: Die ISOs ändern sich nicht so oft. Um auf exakt Deinen Stand zu kommen brauchst Du die ISO 3387 und das Rollout 336.

VG

Werner

Das liegt daran, dass Deine Testversion abgelaufen ist. Mit Sitecare hat das nichts zu tun. Eine Testversion läuft 30 Tage und danach stellt sie die Arbeit ein, es sei denn, Du kaufst DAVID regulär.

Wir haben einige Kunden mit Installationen so um die 20 bis 35 User. Die unangekündigten Preiserhöhungen für die Sitecare dort lagen im Bereich von ca. 20 - 27 %, je nach Useranzahl und Staffel.

Große Installationen waren schon immer deutlich günstiger als kleine Installationen. Für bis zu 10 User zahlt man ungefähr 50% mehr pro User und Monat, als für eine Installation mit z.b. 50 Usern. Die alten BASIC-Lizenzen mit 2 Usern (wie oben von Shubi genannt) sind extrem viel teurer geworden.

Einfach deaktivieren, es läuft dann zum angezeigten Zeitpunkt aus.

Ich persönlich empfinde die von TOBIT aufgerufenen Kosten für die Sitecare speziell bei kleinen Installationen auch als - gelinde gesagt - unverschämt. Zudem hat TOBIT die Sitecare-Kosten ohne jede Ankündigung letzthin auch noch mal deutlich erhöht, was bei einigen unserer Kunden die Diskussion über einen Umstieg zu O365 noch mal beschleunigt hat.

Neuinstallationen seit Dezember 2021 keine mehr. Wir betreuen nur noch Bestandskunden und ziehen nach und nach alle zu O365 oder gehostetem Exchange um. Ab und zu verkaufen wir eine Zusatzlizenz, das wars dann aber schon. Momentan sind wir noch TAR, das wird aber auch bald Geschichte sein.

Der Anreiz für Händler, DAVID zu verkaufen, geht gegen Null. Praktisch keine Provisionen mehr, der B2B-Support seitens TOBIT ist schon seit Jahren ein Witz. Der Händler muss einen jährlichen Mitgliedsbeitrag und auch noch für die Sitecare seiner NFR-Versionen bezahlen - das gibt es sonst nirgendwo!

Den Kunden fällt der Abschied auch leicht: Sitecare ist gerade für kleinere Installationen überproportional teuer und der Kunde bekommt im Gegenzug schon lange keinen echten Mehrwert mehr für seine regelmässigen Zahlungen. Dringend notwendige Dinge wie eine bessere Anbindung von Outlook als Client oder eine EWS-Schnittstelle für 3rd-Party Produkte sehen wir nicht kommen. Activesync wird lt. MS nicht mehr weiter entwickelt und in zukünftigen Outlook-Versionen auch nicht mehr enthalten sein, damit ist das Thema Outlook als Client demnächst auch erledigt.

Wer will/soll dann noch DAVID (ver-)kaufen?

Wir haben kein Problem damit, denn wir verlieren beim Wechsel auf ein anderes Emailsystem keinen unserer Kunden, TOBIT schon. Und die kommen auch nie wieder zu TOBIT zurück.

Wenn man die Authentifizierung mittels Personalausweis und Kartenleser machen möchte, dann muss zum einen der Kartenleser mit seinen Treibern installiert sein und funktionieren, zum anderen muss man auch noch die AusweisApp2 für das jeweilige Betriebssystem herunterladen (https://www.ausweisapp.bund.de/download) und installieren. Diese "klemmt" sich zwischen die D-Trust-Website und den Kartenleser.

Ist die App auf dem Rechner nicht vorhanden, kommt der von Kingcopy angesprochene Fehler mit 127.0.0.1:xxxx.

Gruß Werner

Habe ich erst Anfang dieser Woche für mein persönliches Zertifikat gemacht. Ich war ebenfalls überrascht und nicht vorbereitet. Ich hatte allerdings die notwendigen Gerätschaften:

- Personalausweis mit digitaler ID und PIN

- Reiner Cyberjack RFID Kartenleser

- AusweisAPP2 für Windows

Ich musste den ganzen Kram aber erst einmal installieren und aktivieren, denn obwohl mein Perso schon 4 Jahre alt ist, habe ich die Online-Funktionen bisher nirgendwo brauchen können. Den Kartenleser hatte ich schon vom Online-Banking, deswegen war das nicht das Problem. Es soll auch mit dem Perso und der App für das Mobiltelefon gehen (also ohne RFID-Lesegerät), aber das habe ich nicht ausprobiert.

Wenn ich das nicht da gehabt hätte, dann hätte ich mir ein Zertifikat eines anderen Herausgebers besorgt. GlobalSign, Certum, COMODO, SwissSign, ... machen das nach wie vor mit einfacher Email-Validierung, allerdings seit neustem auch nur noch für max. 2 Jahre.

Outlook 2016 und neuer setzen zwingend ein offizielles Zertifikat auf dem DAVID-Server voraus (z.B. von Let's-Encrypt, wie Nordtech weiter oben schon gesagt hat). Ein selbstsigniertes Zertifikat funktioniert hier nicht mehr, m.W. auch dann nicht, wenn man versucht, das Postfach über die Systemsteuerung manuell anzulegen. Bei Outlook ab 2019 muss man auch noch einen Weg finden, das Autodiscovery zu umgehen, wenn der Server nur lokal gefunden werden soll. Das funktioniert mehr schlecht als recht und schon das nächste Update von MS kann das wieder zunichte machen.

Der beste Weg hierfür ist eine feste IP, ein Subdomain-Eintrag beim Hoster und ein offizielles Single-Server-SSL-Zertifikat. So etwas kostet z.B. bei Sectigo als "Lite (Positive SSL)" Euro 59,00 für 5 Jahre. Das wird auch von allen mobilen Endgeräten sofort akzeptiert.

In neueren Outlook-Versionen ist der EAS-Support übrigens zwar immer noch drin, er wird aber seitens MS nicht mehr gepflegt. Die letzte Version bei der das voll implementiert und supported wurde und bei der auch noch selbstsignierte Zertifikate funktionieren ist Outlook 2013.

Das ist für den Fachhändler exakt dasselbe System, nur dass es da (wegen evtl. mehrerer gleichzeitig offener Anfragen für verschiedene Kunden) noch unübersichtlicher wird.

Das ganze Händlerportal ist in meinen Augen ein Witz und jeder andere Hersteller oder Distributor hat da Besseres zu bieten - leider. TOBIT ist hier auch absolut resistent gegenüber Verbesserungsvorschlägen oder Wünschen.

Vielleicht liegt die Ursache auch in der zwangsweisen Verwendung von Chayns. Die Website zeigt meiner Meinung nach jedenfalls, dass man so etwas besser nicht mit dem Chayns-Baukasten machen sollte. Dafür taugt das System definitiv nicht.

Eine Migration mit dem Migration Tool sollte kein Problem sein. Als TAR habe ich das schon oft bei Kunden durchgeführt und es hat immer gut geklappt. Allerdings sollten einige Vorarbeiten erledigt werden. Wie genau es funktioniert und was dabei zu beachten ist, habe ich schon vor ein paar Jahren hier beschrieben:

Migration-Tool

Ob das Tool in Eurem Fall auch das Mittel der Wahl ist, hängt von ein paar Dingen ab:

- Wie groß ist die gesamte Datenmenge der alten DAVID-Installation?

- Welche Downtime könnt Ihr akzeptieren?

Das Migration Tool kopiert die Dateien des Archive-Baums einzeln übers Netzwerk von A nach B. Wie viel da in welcher Zeit geschafft wird, hängt dementsprechend von Eurem Netzwerk ab. Ein paar hundert Gigabyte schafft man aber locker an einem Wochenende.

Hallo Burkhard,

hast Du schon Folgendes geprüft/gemacht:

1. In der POSTMAN.INI-Datei im Verzeichnis \DAVID\APPS\POSTMAN\CODE den Parameter EHLOWITHDOMAIN aktivieren und auf TRUE setzen.

2. In der Konfiguration des POSTMAN auf dem ersten Tab unter "Generell" bei "SMTP Host Name" eure Email-Domain eintragen, also z.B. "musterdomain.de". Hier steht oft die IP-Adresse des DAVID-Servers.

Danach den Postman-Dienst neu starten.

Könnte es sein, dass bei den betreffenden Usern die automatische Bereinigung (max. Eintragsalter) für das persönliche Adressbuch aktiviert ist und die fraglichen Adressen einfach durch die nächtliche Bereinigung automatisch gelöscht werden?

Eine automatische Bereinigung für Adressen ist zwar nicht besonders sinnvoll, man kann sie aber aktivieren und dann verschwinden tag-genau die zum Bereinigungszeitraum passenden Adressen. Bei einem Kunden hat das mal ein Spaßvogel für den zentralen Kalender aktiviert mit der Folge, dass nicht nur die ältesten Einzeltermine gelöscht wurden, sondern auch ganze Terminserien bis in die aktuelle Zeit von einem Tag auf den anderen "verschwanden".

Das geht im DV.Admin unter "System" - "Konfigurieren" - "Updates":

Regeln werden beim DAVID grundsätzlich nur auf vom System empfangene Emails angewendet und nicht auf vom User manuell verschobene Emails.

Mit einer Regel im Papierkorb kannst Du also eine eingegangene und dann z.B. von einer anderen Regel (Löschregel) automatisch in den Papierkorb verschobene Nachricht irgendwo anders hin kopieren lassen.

Wenn der User aber irgendwo eine Nachricht manuell löscht, geht diese zwar auch in den Papierkorb, die Regel zum Weiterkopieren wird in dem Fall aber nicht abgearbeitet.

Es gibt hier keinen Workaround oder Trick. Dieses Verhalten gilt bei DAVID systemweit und ist nicht beeinflussbar: "It's not a bug, it's a feature!"

Die Einstellungen für die Postfächer speichert DAVID im Pfad \\DAVID\ARCHIVE\SYSTEM\DAVID\DVGRAB. Dort liegen die Postfachinformationen alle als *.001 Dateien und sind im Klartext lesbar:

Wenn der Ordner bei Dir leer ist, dann kannst Du ihn ja selektiv aus der Datensicherung wieder herstellen und dann den Grabbing-Server neu starten. Das sollte schon reichen.

VG

Werner