Beiträge von nordtech

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 aborted

Kann 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.

Zitat von mk-itservice

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.

Zitat von riawie

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.

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.