David hat in der Tat keine eigene Rechte-Verwaltung; wenn jemand im Windows-Explorer den Ordner (nicht) öffnen kann, klappt das auch im David (nicht). Bist du sicher, den richtigen User am Wickel zu haben?
Ich arbeite so gut wie nie mit "Verweigern" - aber muss in deinem Screenshot ggf. auch bei "Ändern" -> "Verweigern" noch ein Haken rein?
Warum machst du das übers Hinzufügen von "Verweigern" und nicht einfach dem Löschen der Berechtigungen? Verweigern hat in der Windows-Logik zwar Vorrang vor Berechtigungen (glaube ich), aber das ist trotzdem Kuddelmuddel.
Also: Rechtsklick auf den User-Root (1000c000) -> Eigenschaften -> Sicherheit -> Erweitert. "Vererbung deaktivieren", bei Nachfrage "Vererbte Berechtigungen in explizite Berechtigungen ... kopieren". Und dann wirfst du aus der Liste alle Leute raus, die da nicht reingucken sollen, insbesondere "Authentifizierte Benutzer" aus deinem Screenshot! "SYSTEM" bitte drin lassen, je nach Unternehmens-Struktur ggf. auch "Administratoren", und natürlich den User selbst.
Letztlich ggf. noch den Haken setzen bei "Alle Berechtigungseinträge für untergeordnete Objekte ... ersetzen", und schließlich OK.
Nicht übel, das ist exakt die Antwort, die ich inzwischen vom Betreiber des MX-Servers erhalten habe (an der Stelle großes Lob an NetLeaders - das ging sehr schnell und präzise, ganz klassisch per E-Mail. Ist ja inzwischen leider selten geworden). 
In der Tat hat der Empfänger auf diesem Postfach (und nur diesem, das erklärt, warum andere Mails an irgendwas@empfaenger.invalid durchgehen) eine Weiterleitung eigerichtet. Und der Server von Netleaders bringt die Original-Mail mit dem Original-Absender auf den Weg, nur passen dann natürlich SPF und DKIM nicht mehr.
Eigentlich ganz einfach. Wenn man denn drauf kommt.
Im Sinne dieses Forums bleibt demnach festzuhalten: Der Absender ist nicht Schuld, Strato ist nicht Schuld, David aber definitiv auch nicht. 
Bzw. macht David wie angenommen beim Versand via Provider-SMTP das Gleiche wie normale Mailprogramme. Es lag alles nur an der speziellen Konstellation.
Nochmal danke in die Runde, wir werden das nun dem Empfänger so mitteilen und hoffen, dass das DMARC p=none bis dahin zumindest die Zustellung erlaubt.
OK, Firewall kann ich ausschließen, in der Regel des David-Servers ist auch der fragliche PC enthalten.
Die 195.185.212.45 ist schlicht die MX-Adresse des Empfängers, da scheint also ein Archivsystem, Malware-Filter o. ä. vorgeschaltet zu sein. Wie Ritana s KI korrekt rausgefummelt hat, ist die DKIM-Signatur beim Verlassen des Strato-Servers offenbar intakt, bei Ankunft auf dem Empfängersystem aber nicht mehr. Vermutlich wird da also etwas verwurstet. Wodurch sich auch erklärt, dass Testmails an andere Empfänger als einwandfrei eingestuft wurden.
Was mich nun noch verwirrt, ist, dass der Kunde angibt: Beim Versand via David soll alles klappen, auch zu diesem spezifischen Empfänger. Das kann ich leider nicht testen - eine Mail vom Versender an ein anderes Exchange-System (ohne vorgeschalteten Spezial-MX) sieht gut aus. Aber der Logik nach müsste es ja beim "Problem-Empfänger" auch via David zu Schwierigkeiten kommen, da beide über den gleichen SMTP der gleichen Domain versenden. Zwar über ein anderes Postfach, aber das "merkt" der Empfänger doch gar nicht. :-/
Alles etwas seltsam. Ich mach jetzt erstmal Pause und schlage dem Kunden ggf. vor, es mit einer Test-Absenderdomain z. B. bei Hetzner zu versuchen. Tritt das Phänomen dort identisch auf, wissen wir zumindest, dass das Strato-Hosting nicht ursächlich ist. Derweil behelfen wir uns mit einer DMARC-Policy "p=none" in der Hoffnung, dass die Mails dann trotz DKIM-Salat durchrutschen.
Danke euch allen für die gedankliche Unterstützung!
2018-03-13 ist der Client-PC, der die Mail auf den Weg bringt. Der "spricht" direkt mit dem Strato-SMTP. Die 195.185.212.45 scheint ja zu einem Laden zu gehören, der z. B. Cloud-Telefonanlagen betreut. Ich weiß nach wie vor nicht, was der da für Aktien drin hat bzw. wo der herkommt.
Was mir gerade einfällt: Kann das eine Firewall sein? Die stammt beim Kunden von einem Drittanbieter, wird nich durch uns betreut. Wäre ja möglich, dass die Firewall den David-Server ausgehend in Ruhe lässt, aber bei einem normalen Client, der plötzlich direkt Mails versenden will, "reingrätscht"?
Hast du für David selbst auch ein DKIM aktiviert? DMARC und SPF DNS Eintrag überprüft?
Für David direkt ist kein DKIM etc. eingerichet. Muss ja aber (wenn ich das richtig sehe) nicht, da wir ausschließlich per Smarthost senden. Die Mails aus dem David erhalten z. B. bei mail-tester[punkt]com eine Reputation 10/10: DKIM und SPF einwandfrei, alles mit Standard-Werten von Strato.
Ich füge unten mal das an, was der Kunde als Bounce-Nachricht zurück bekommt - und hoffe, alles korrekt anonymisiert zu haben.
zieladresse@empfaenger.invalid ist der Empfänger
quelladresse@versender.invalig der Sender.
Auffällig ist natürlich z. B. dieses hier: "Received-SPF: Fail (protection.outlook.com: domain of versender.invalid does
not designate 195.185.212.45 as permitted sender)" - damit hat das System im Prinzip ja Recht, ich weiß allerdings spontan nicht, wo diese IP herkommt. Es scheint sich nicht um einen Strato-Server zu handeln.
Ist es denkbar, dass das erwähnte Programm trotz der korrekten Hinterlegung des Strato-SMTPs noch über eigene Server verschickt? Das wäre ja ein ziemlicher Klops.
Delivery has failed to these recipients or groups:
zieladresse@empfaenger.invalid
Your message wasn't delivered because the recipient's email provider rejected it.
Diagnostic information for administrators:
Generating server: BEZP281MB2759.DEUP281.PROD.OUTLOOK.COM
zieladresse@empfaenger.invalid
Remote server returned '550 5.7.509 Access denied, sending domain versender.invalid does not pass DMARC verification and has a DMARC policy of reject.'
Original message headers:
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=fail;
b=A1qXPuYKwCmoW40yU/TmjYlPY5rDtNsSzdJLhivr9vBf/B9a2LctxXA41rl4HBEKzbMdh178mxAlddvRuHv47YKepx+Jt+yqVVbFHpDjFfPk/sEdVPm9XNEQh+/MGDI3GDdI6RzIL97OPa/7QtsEUabXvMnckupPagZs+j6PuFdU3FehPwBT8hcuiM0YO2xR1t397BQ9gHHxZn4YQxA8XuAJn2S4nEH5+on/42NjdZNR3CTKkXVsvGcZxI++sCVArBxQoTk+l16Qq+49usbjgT4W/7RPbZSZY6Y03dvW38lhbua7olGqzYVCgMomo0Z9mEjP1AhCiSLfOlfMcbh7NA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=6dxP7/yVJIeBOrJVJKd2XdrFvklZ3B++mMG4+3TTyn8=;
b=ZbYLQ8VWauvip3GUHrtLHsTBshGkoyMjKjWGwyIn3HOK7jh8VfdFtT6P69R+O9HM6WH0XF58/PWqnGEV07Q/CBUgEF/ycVIXwx5uhUBgLIdaNjwPRXAGLgx/f5kKmET8UQMG3+m8p6MJIT7U9NJ/wdfZcAx8s2MGpZ+yeDW1P9BjJJI3THfjAlyYBeK90xaBrTJY2rJwGvs5ZkpilQBZ8zlIrW6ld8gAclU3bKR4V0Olm5NeiO6RSv70VFrJyPGIKXCcLSyXVVMqk++eW2pcD7DjB1YK2+Co3s4EH9WjWB5pn+YU18o5KoFeoj4j6x2/XxguCk7NwfTPtMhcX8qQLA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=fail (sender ip is
195.185.212.45) smtp.rcpttodomain=empfaenger.onmicrosoft.com
smtp.mailfrom=versender.invalid; dmarc=fail (p=reject sp=reject pct=100)
action=oreject header.from=versender.invalid; dkim=fail (body hash did not
verify) header.d=versender.invalid; dkim=fail (signature syntax error)
header.d=none; arc=fail (47)
Received: from FR4P281CA0215.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::16)
by BEZP281MB2759.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:5e::11) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9818.25; Thu, 16 Apr
2026 08:00:06 +0000
Received: from FR2PEPF000004F1.DEUP281.PROD.OUTLOOK.COM
(2603:10a6:d10:e4:cafe::4c) by FR4P281CA0215.outlook.office365.com
(2603:10a6:d10:e4::16) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.9769.51 via Frontend Transport; Thu,
16 Apr 2026 08:00:06 +0000
Authentication-Results: spf=fail (sender IP is 195.185.212.45)
smtp.mailfrom=versender.invalid; dkim=fail (body hash did not verify)
header.d=versender.invalid;dkim=fail (signature syntax error)
header.d=none;dmarc=fail action=oreject
header.from=versender.invalid;compauth=fail reason=000
Received-SPF: Fail (protection.outlook.com: domain of versender.invalid does
not designate 195.185.212.45 as permitted sender)
receiver=protection.outlook.com; client-ip=195.185.212.45;
helo=mail.ispmail.de;
Received: from mail.ispmail.de (195.185.212.45) by
FR2PEPF000004F1.mail.protection.outlook.com (10.167.240.38) with Microsoft
SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9769.17
via Frontend Transport; Thu, 16 Apr 2026 08:00:06 +0000
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.21])
by mail.ispmail.de (Postfix) with ESMTPS id 243C2D0168
for <zieladresse@empfaenger.invalid>; Thu, 16 Apr 2026 10:00:05 +0200 (CEST)
Authentication-Results-Original: mail.ispmail.de; dkim=pass
header.d=versender.invalid header.s=strato-dkim-0002 header.b=LfwMg2bj;
dkim=pass header.d=versender.invalid header.s=strato-dkim-0003
header.b="X/PDTeaa"; dmarc=pass (policy=reject)
header.from=versender.invalid; arc=pass
("strato.com:s=strato-dkim-0002:i=1"); spf=pass (mail.ispmail.de: domain of
quelladresse@versender.invalid designates 85.215.255.21 as permitted
sender) smtp.mailfrom=quelladresse@versender.invalid
ARC-Seal: i=1; a=rsa-sha256; t=1776326404; cv=none;
d=strato.com; s=strato-dkim-0002;
b=gYaDgKa6f3spxBCK7cupMOc/uoyZKFafKg3ne+K6+3KKdAy+SCmUHpS8/TMW4kFI8E
tFU2EqUT6qMwJAVVHzEJ/dAZzjAXbzZcTEHoO2STFB/EonFT6DaqvOOWkRyEh/h+rSf8
W3t0GuvfyyIEw/nZ4FUjSqiqxnQEIppT7AHBVWJ9OggPlTpyuasxBXa41psaawJzboHd
NzgGeuZSGx6pCS0XZs6ZPRiBtW5umDxKaIYn7ZbE+g36DlWkSzcsVKG1vAc/2f6t8nRs
TUYtxZwHzbPVyA+eoRvNXR514w+lY1GroGsbMiPC3N9x/jqTf6ZAAJRchWDcl3ZyUCq7
Zeug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1776326404;
s=strato-dkim-0002; d=strato.com;
h=Date:Subject:To:From:Message-ID:Cc:Date:From:Subject:Sender;
bh=Q7IC7cheF/44hMi27Jfbp7hyL70l2rgmsp+3vbxpkQQ=;
b=LnfP8glWtmlayu53GmIDCSbCMKtKamjKbhYNC2mLTbwfFR5CLUVaKBCSLB7Z1k1NKD
iJkSZnSKDUvlkzFtmogBgkQMZWfM9r1ZTPGYvkrDJfyom44IZaCUSIOYWWQFT+ODCsk+
lZhlvNZyMRSHFsw4StUD9bpaD5vfLCpor8gq8WQs0dzXz3zmgdOhB4OTYWOuiEOzHJxq
UvSXF+m5xNC7FtpgmWoeLw4SgCOQVWdgzpNfA5jnWsOTC+tUktVw5YCTysjmEh500UMC
Wc5EqaTS5ld/iqTd7Heup6Z8Z5Hkqkc8P3fFz0XVfFJ6YdJ10prX42TjelQNEZFQdaMX
8YYA==
ARC-Authentication-Results: i=1; strato.com;
arc=none;
dkim=none
X-RZG-CLASS-ID: mo00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1776326404;
s=strato-dkim-0002; d=versender.invalid;
h=Date:Subject:To:From:Message-ID:Cc:Date:From:Subject:Sender;
bh=Q7IC7cheF/44hMi27Jfbp7hyL70l2rgmsp+3vbxpkQQ=;
b=LfwMg2bjHCg8fI8Ao+Rkdd7EqBimJQTBtUlvjkik/DitKC/UcEBAuZFbt+Ze58Vh6K
wih3NFUH06V37aKVksfMHgZ3/K65jHLP3KjFUpNwTtz9JkThoFH4Ek/bdSdBtV85/G0i
Ei9M4oir/cxDkXO8xk06ie9TSBEah6RgsihEvrtbkZLexOnwiYIq/hwKJKksR3tXsctO
RJcpv6RW7cxZDzhz4cmcCew+Xe2WSLOklbd2v5FF0L/RnMWy0FBAtOWvjdMH1IE4qIUT
/fDx8tYMf2l36thZ/E0YqFfTqbEto8QK8PIfT9LdaKRd12as7apppXlRho78+mIN78kr
GRVg==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1776326404;
s=strato-dkim-0003; d=versender.invalid;
h=Date:Subject:To:From:Message-ID:Cc:Date:From:Subject:Sender;
bh=Q7IC7cheF/44hMi27Jfbp7hyL70l2rgmsp+3vbxpkQQ=;
b=X/PDTeaaG2G9GpRkimAc97q9WDf+5UHr2rh/egeqzOV79t2/28bvi67hO9YBk226Kv
+lpY5IgxK5X331qXHEAw==
X-RZG-AUTH: ":OG0KflKtePdq/fqH4o1hZ8fNtHpiHGv6AiUC1QlPZEaooRFyJFlRVSFem4y10Ujia5dun0ib8AhrijPgmCk="
Message-ID: <Vba07623G801Fwf.RZmta@versender.invalid>
Received: from 2018-03-13
by smtp.strato.de (RZmta 55.0.1 AUTH)
with ESMTPSA id Vba07623G801Fwf
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits))
(Client did not present a certificate)
for <zieladresse@empfaenger.invalid>;
Thu, 16 Apr 2026 10:00:01 +0200 (CEST)
From: quelladresse@versender.invalid
To: zieladresse@empfaenger.invalid
Subject: =?utf-8?Q?Tankrechnung?=
Date: Thu, 16 Apr 2026 10:00:04 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_SoFtWaReBuErOzAuNeRuNdPaRtNeR_MiMe_bOuNdArY"
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: mail1
X-Rspamd-Queue-Id: 243C2D0168
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.10 / 13.00];
R_SPF_ALLOW(-2.00)[+ip4:85.215.255.0/24];
SUBJ_EXCESS_QP(1.20)[];
ARC_ALLOW(-1.00)[strato.com:s=strato-dkim-0002:i=1];
DMARC_POLICY_ALLOW(-0.50)[versender.invalid,reject];
R_MISSING_CHARSET(0.50)[];
R_DKIM_ALLOW(-0.20)[versender.invalid:s=strato-dkim-0002,versender.invalid:s=strato-dkim-0003];
MIME_GOOD(-0.10)[multipart/mixed,text/plain];
BAYES_HAM(-0.00)[29.85%];
TO_DN_NONE(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
FUZZY_BLOCKED(0.00)[rspamd.com];
NEURAL_HAM(-0.00)[-0.989];
MIME_TRACE(0.00)[0:+,1:+,2:~];
RCVD_TLS_ALL(0.00)[];
RCVD_COUNT_TWO(0.00)[2];
PREVIOUSLY_DELIVERED(0.00)[zieladresse@empfaenger.invalid];
ASN_FAIL(0.00)[21.255.215.85.asn.rspamd.com:server fail];
TO_MATCH_ENVRCPT_ALL(0.00)[];
HAS_ATTACHMENT(0.00)[];
FROM_NO_DN(0.00)[];
RCPT_COUNT_ONE(0.00)[1];
DKIM_TRACE(0.00)[versender.invalid:+];
MID_RHS_MATCH_FROM(0.00)[];
RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Action: no action
Return-Path: quelladresse@versender.invalid
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 0a6306b3-0328-4731-b491-6023f102f304:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: FR2PEPF000004F1:EE_|BEZP281MB2759:EE_
X-MS-Office365-Filtering-Correlation-Id: cd004ed9-be11-44aa-77ae-08de9b8e2c3b
X-Forefront-Antispam-Report:
CIP:195.185.212.45;CTRY:DE;LANG:de;SCL:9;SRV:;IPV:NLI;SFV:SPM;H:mail.ispmail.de;PTR:mail.ispmail.de;CAT:SPOOF;SFS:(13230040)(6049299003)(4053099003)(18002099003)(19002099003)(16102099003)(56012099003)(3613699012);DIR:INB;
X-Microsoft-Antispam:
BCL:0;ARA:13230040|6049299003|4053099003|18002099003|19002099003|16102099003|56012099003|3613699012;Ja, die Adresse ist korrekt. Über die erfolgt ja auch die Anmeldung beim Provider, das passt soweit.
Hallo zusammen,
ich kann mir ein Problem gerade logisch nicht erklären.
Gegeben ist ein David-System, das ausschließlich über den Provider (Strato) arbeitet. Empfang via Catchall, Senden per Smarthost. Klappt alles prima, und bei Strato sind die üblichen Einstellungen auf Default gelassen worden. Sende ich eine Mail als beliebiger User an z. B. einen Dienst wie mail-tester[punkt]com, dann erhalte ich eine tolle Reputation, insbesondere SPF, DKIM und DMARC werden als gültig und sauber angezeigt. Beim Versand über smtp.strato.de setzt der Provider diese Einträge ja automatisch.
Es gibt aber eine Applikation, die wir mit dem David-Postman nicht zum Laufen bekommen haben, konkret wurden PDF-Anhänge "verwurstet". Kurzerhand haben wir für diese Applikation also bei Strato ein separates Postfach eingerichtet und die passenden Einträge gemacht. Das Programm sendet nun "an David vorbei" direkt über smtp.strato.de.
Problem: Der Empfänger beklagt sich (nur bei diesem Absender) über eine fehlerhafte DKIM-Signatur und lehnt die Mail ab.
Hä? DKIM und Co. sind doch via DNS für die gesamte Domain gültig - wie kann es dann sein, dass alle David-Mails problemlos ihre Empfänger erreichen, diese Mails aber nicht? Das Programm ist leider alt und lässt keine Diagnose zu (z. B. Test-Mails an beliebige Empfänger), es ist aber alles sauber/aktuell konfiguriert, also smtp.strato.de als Ausgangsserver, SSL, Port 465.
Ich merke gerade, das Thema hat mit David nur bedingt zu tun, da es sich ja speziell um das eine Postfach handelt, das nicht mit David bearbeitet wird. Vielleicht hat trotzdem jemand eine Idee? Ich versteh's nicht wirklich.
Infos wie üblich unter https://david.tobit.software/releasenotes
Mein persönliches Highlight (ganz unironisch): "Symbolleiste im Editor linksbündig - Die Symbolleiste im Editor ist nun wieder linksbündig angeordnet, statt zentriert."
Es wird zwar nicht expliziet EAS erwähnt, wenn aber die Webbox als Dienst gemeint ist, stirbt das auch...
Das kann ich mir bei bestem Willen nicht vorstellen, das wäre ein massiver Schuss in den eigenen Fuß.
Ich lese aus dem Satz "wird der alte Web Access per WebBox demnächst abgekündigt" wirklich nur dia Abschaltung des WebAccess; die Webbox als Dienst, incl. EAS, wird weiter laufen.
Andernfalls bekommen wir hier ein Problem - über 90% der Kunden nutzen die Anbindung via EAS.
Ich kenne im Kundenkreis niemanden, der den WebAccess nutzt - weil er wie schon beschrieben bereits seit Jahren absolut grottig ist. Läuft dafür aber vermutlich auch noch mit dem IE4 (nicht getestet)
Den SmartClient als Nachfolger würde ich im Prinzip daher begrüßen, aber mit leichten Bauchschmerzen, denn WebAPI und Tobit-SSO sind halt nicht mehr wirklich "alles im eigenen Haus und volle Gewalt über alle Daten, die rein und raus gehen".
Ich denke, der Aufschrei wird eher klein ausfallen. Aber danke für die Info Baumi , ich hab' das in der Tat überlesen.
Ich denke, martaeng ging es eher grundsätzlich um das "Nach Hause telefonieren". Das hat David bisher auch schon für bestimmte Funktionen gemacht, aber dass bei nicht erfolgter Kommunikation mit dem Lizenzserver die komplette Version in einen Nur-Lese-Modus geschaltet wird, ist halt recht neu.
Ich fand die Information jedenfalls interessant. Auch, wenn man das am Ende letztlich nur schulterzuckend hinnehmen kann. Und mich mal interessieren würde, ob Tobit wirklich ein Problem mit Lizenzverletzungen oder gar Schwarzkopien hat - bei so einem speziellen Produkt kann ich mir das eigentlich kaum vorstellen.
MAPI Übergabe crasht jetzt den Client
Ich konnte das hier spontan nicht reproduzieren, wie äußert's sich denn konkret - Team-Client komplett "abgeschossen", oder kommt irgendeine Meldung? Was ist auf dem Client unter Einstellungen -> Editor -> MAPI konfiguriert?
Bricht die Leiste dann um, wenn man das Fenster schmaler macht? Und hocken die beiden Teile dann wieder in der Mitte?
Die Leiste wandert bei schmalerem Fenster immer weiter an den linken Rand, dann werden einzelne Symbole ausgeblendet und durch einen Pfeil nach unten ersetzt, und bei ganz wenig Platz wird die Leiste zweizeilig.
Der Sinn hinter der Zentrierung erschließt sich mir auch nicht ganz - beim Win11-Startmenü wurde ja damit argumentiert, dass die Mauswege kürzer werden. Aber in einer E-Mail arbeitet man meist linksbündig orientiert. Schon a bisserl seltsam.
Erster Eindruck nach dem Überfliegen von https://david.tobit.software/ReleaseNotes : Viele kleine Anpassungen und Bugfixes auf Client-Seite. Insbesondere auch für Mac und Smart-Client.
Wenn sie durch eine andere Verteilregel in dem Archive landen, greifen die dort vorhandenen Regeln sehr wohl.
Gerade mal ausprobiert, du hast Recht, das klappt! Ich nehme alles zurück.
Verteilregeln greifen wimre nicht, wenn die ankommenden Nachrichten bereits per Verteilregel im betreffenden Archiv landen. Daher eine Idee:
Alternativ habe ich das auch schon direkt beim Provider eingestellt, dann bekommt David davon gar nichts mit.
Es wird immer spannender. Bei mir wird die Datei auch dann neu erstellt bzw. überschrieben (mit 13kb Größe), wenn ich den Inhalt manuell auf "[]" ändere. Folgerichtig sind dann auch die Agents im Chatfenster wieder da. :-/
Bei uns kommen da auch keine KI Avatare. Wir haben die KI Funktionen allerdings auch nicht nur einzelnen Nutzern verweigert, sondern Systemweit abgeschaltet
Ist bei uns auch:
Bei den Usern ist "Sidekick AI Services erlauben" ebenfalls leer. Die Avatare kommen trotzdem:
Per Kontextmenü und auch über die Eigenschaften geht glaube ich gar nicht mehr.
Abhilfe: Einstellungen -> Ansicht -> Vorschau -> "Tabs mit erweiterten Eintragsinformationen anzeigen" aktivieren, dann erscheint im Vorschaubereich(!) ein neuer Reiter "HTML-Inhalt". Dort kann man direkt editieren, und beim Wechsel des Reiters (oder Drücken von Strg + S) wird gespeichert.
Ich finde das sehr holperig und unintuitiv, aber vermutlich möchte Tobit nicht, dass man im Quelltext herumwühlt. Was wiederum seltsam wäre, denn das ist der einzige Weg, wirklich saubere Vorlagen hinzubekommen. Naja, immerhin existiert obiger Workaround.
