Versionsinformationen zum MDaemon-Server V20.0

MDaemon 20.0.2 - 2020-09-22

ZUR BESONDEREN BEACHTUNG

[16456] Es stehen jetzt gehostete E-Mail-Lösungen mit MDaemon Private Cloud zur Verfügung. Nähere Informationen finden Sie unter http://www.altn.com/Products/MDaemon-Private-Cloud/.

BEHOBENE FEHLER

MDaemon 20.0.1 - 2020-08-18

ZUR BESONDEREN BEACHTUNG

[16827] Mithilfe der Einstellungen für den Zugriff auf Netzwerkressourcen im Konfigurationsdialog Einstellungen | Voreinstellungen | Windows-Dienst können Sie jetzt ein Benutzerkonto festlegen, unter dem die Windows-Dienste MDaemon, MDaemon-Remoteverwaltung und XMPP ausgeführt werden. Bislang wurden diese Dienste und die Prozesse und Threads, die durch diese Dienste gestartet wurden, im Sicherheitskontext des Benutzerkontos SYSTEM ausgeführt. Die Installationsroutine ändert während der Aktualisierung auf die vorliegende Version die Konfiguration der betroffenen Windows-Dienste so, dass sie unter dem angegebenen Benutzerkonto ausgeführt werden.

[23399] In der Datei clamd.conf haben sich Änderungen ergeben, und viele Einstellungen werden nicht mehr unterstützt. Die Installationsroutine überschreibt daher eine bestehende Datei clamd.conf. Falls Sie Ihre Datei clamd.conf angepasst haben, müssen Sie die Datei clamd.conf nach der Installation überprüfen und möglicherweise anpassen.

ÄNDERUNGEN UND NEUE LEISTUNGSMERKMALE

BEHOBENE FEHLER

MDaemon 20.0.0 - 2020-06-16

ZUR BESONDEREN BEACHTUNG

[8930] Bitte lesen Sie in den Versionsinformationen den Abschnitt [8930] besonders sorgfältig durch. Dieser Abschnitt enthält Informationen über Änderungen an der Integration des Active Directory, und Sie bemerken unter Umständen eine Änderung in der Funktionsweise, wobei bislang nicht funktionierende Vorgänge jetzt funktionieren. Um einen Überblick über die einzelnen Änderungen und ihre Wirkung zu erhalten, müssen Sie den genannten Abschnitt vollständig durcharbeiten.

[22733] MDaemon 20.0 erfordert Microsoft Windows 7, Server 2008 R2 oder eine neuere Version der genannten Betriebssysteme.

[12190] Der Konfigurationsdialog Einstellungen | Voreinstellungen | Verschiedenes wurde um zwei Optionen erweitert. Sie bestimmen, ob die durch das System erstellten Benachrichtigungen, die an den Postmaster gesandt werden, auch an die Globalen und Domänen-Administratoren gesandt werden sollen. Per Voreinstellung sind beide Optionen aktiv. Domänen-Administratoren erhalten hierbei nur Nachrichten, die sich auf ihre Domänen beziehen, sowie die Versionsinformationen. Globale Administratoren erhalten alle Nachrichten sowie die Berichte über Inhalte der Warteschlangen, Statistiken, Versionsinformationen, Meldungen, dass Benutzer nicht gefunden wurden (für alle Domänen), Meldungen über Datenträgerfehler, Meldungen über eingefrorene und gesperrte Benutzerkonten für alle Domänen (sie und die Domänen-Administratoren können die Benutzerkonten wieder freigeben), Warnmeldungen über Lizenzen und den bevorstehenden Ablauf der Funktionsdauer von Betaversionen, Übersichten über Spam und weitere Nachrichten. Falls Sie nicht wünschen, dass die Administratoren diese Nachrichten erhalten, müssen Sie die neuen Optionen deaktivieren.

[22604] Autobeantworter werden ab jetzt anders als bisher gespeichert. Der Text des Autobeantworters für ein Benutzerkonto wird jetzt als Datei OOF.MRK in den Verzeichnissen DATA der Benutzerkonten gespeichert. Dieses Verzeichnis ist ein neues Unterverzeichnis unter dem Hauptverzeichnis des Postfachs. Die Skriptdateien für die Autobeantworter werden nicht mehr im Verzeichnis APP gespeichert, und sie werden auch nicht mehr durch mehrere Benutzerkonten gemeinsam genutzt. Beim ersten Programmstart überführt MDaemon alle Dateien und Einstellungen der bestehenden Autobeantworter an die neuen Speicherorte für die betreffenden Benutzerkonten. Die Datei AUTORESP.DAT wird nicht mehr verwendet. Sie und die RSP-Dateien der einzelnen Benutzerkonten werden gelöscht. Die Datei OutOfOffice.RSP und Dateien, die sich nicht auf einzelne Benutzerkonten beziehen, bleiben als Standard-Referenzskript und Beispieldateien erhalten. Falls Sie eine bestimmte Autobeantworter-Konfiguration mehreren Benutzerkonten gleichzeitig zuweisen wollen, können Sie dies mithilfe der neuen Schaltfläche Veröffentlichen im Konfigurationsdialog Benutzerkonten-Editor | Benutzerkonten-Einstellungen | Autobeantworter erreichen. Durch Anklicken dieser Schaltfläche werden der bestehende Text des Skripts für den Autobeantworter und alle Einstellungen aus dem gerade bearbeiteten Benutzerkonto in die anderen Benutzerkonten kopiert, die Sie auswählen. Im Konfigurationsdialog Benutzerkonten | Benutzerkonten-Einstellungen | Autobeantworter | Einstellungen steht außerdem eine neue Schaltfläche zur Verfügung, mit deren Hilfe Sie das Standard-Skript für die Autobeantworter (OutOfOffice.rsp) bearbeiten können. Die so bearbeitete Datei wird in die Datei OOF.MRK der Benutzerkonten kopiert, in denen die Datei OOF.MRK fehlt oder leer ist.

[22738] Die Signaturen für Benutzerkonten werden ab jetzt anders als bisher gespeichert. Die Signaturdateien werden jetzt als Dateien SIGNATURE.MRK in den Verzeichnissen DATA der Benutzerkonten gespeichert. Dieses Verzeichnis ist ein neues Unterverzeichnis unter dem Hauptverzeichnis des Postfachs. Beim ersten Programmstart überführt MDaemon alle Dateien der bestehenden Signaturen an die neuen Speicherorte für die betreffenden Benutzerkonten. Im Verzeichnis Signatures unter dem Hauptverzeichnis von MDaemon sind danach keine benutzerspezifischen Signaturdateien mehr gespeichert. Das Verzeichnis selbst bleibt aber bestehen, da es noch Elemente enthalten kann, die durch die MDaemon-Remoteverwaltung und den Inhaltsfilter benötigt werden. Der ursprüngliche Inhalt des Verzeichnisses Signatures wurde vor der Umstellung in das Verzeichnis \Backup\20.0.0\Signatures\ gesichert. Auch die Dateien ADMINNOTES.MRK für die einzelnen Benutzerkonten wurden in das neue Unterverzeichnis DATA verschoben.

[8014] Im Konfigurationsdialog Sicherheit | Spam-Filter | Weiße Liste (automatisch) wurde die Voreinstellung für die Option "... nur über DKIM echtheitsbestätigte Adressen in die Weiße Liste eintragen" geändert; die Option ist jetzt per Voreinstellung deaktiviert. Die Option hat sich für mehrere Anwendungszwecke als zu stark einschränkend erwiesen. Sie verhindert auch die Nutzung des Adressbuchs als Weiße Liste für Nachrichten, die über MultiPOP und DomainPOP abgerufen wurden. Falls die Option bislang aktiv war und so beibehalten werden soll, müssen Sie die Option nunmehr erneut aktivieren.

[22512] Im Konfigurationsdialog Einstellungen | Voreinstellung | Benutzeroberfläche wurde die Option "Alle Konfigurationsdialoge der Benutzeroberfläche zentrieren" für alle Installationen auf die Voreinstellung gesetzt und damit aktiviert. Falls dies nicht Ihren Anforderungen entspricht, müssen Sie die Option deaktivieren. Die Option verhindert, dass Konfigurationsdialoge teilweise außerhalb des darstellbaren Bildschirmbereichs erstellt werden (was für die meisten Anwendungszwecke wünschenswert sein dürfte), sie erschwert aber bisweilen die Anwahl eines von mehreren überlappenden Fenstern.

[22515] Im Konfigurationsdialog Sicherheit | Sicherheits-Manager | Filter | Länder-Filter ist der Länder-Filter ab jetzt per Voreinstellung aktiv. Bei aktiviertem Länder-Filter werden das Land oder die Region, aus dem oder der eine eingehende Verbindung hergestellt wird, immer protokolliert, soweit sie sich feststellen lassen. Die Protokollierung erfolgt auch, wenn das betreffende Land oder die betreffende Region nicht durch den Länder-Filter gesperrt sind. Sie können daher den Länder-Filter auch dann aktivieren, wenn Sie keine zu sperrenden Länder auswählen, und die Informationen über Land oder Region werden danach angezeigt und protokolliert. Da sich die Voreinstellung für diese Option geändert hat, sollten Sie nach einer Aktualisierung von MDaemon die Konfiguration des Länder-Filters darauf hin überprüfen, ob sie Ihren Anforderungen weiterhin entspricht. MDaemon fügt in die Nachrichten die Kopfzeile "X-MDOrigin-Country" ein; in ihr erscheinen Land oder Region. Sie können diese Kopfzeile zur Bearbeitung durch den Inhaltsfilter oder für andere Verarbeitungszwecke nutzen.

[19910] Die bislang fest kodierte Größenbegrenzung von 2 MB, oberhalb derer Nachrichten nicht mehr durch den Spam-Filter ausgewertet wurden, wurde entfernt. Es besteht jetzt theoretisch keine höchstzulässige Größe mehr, ab der Nachrichten nicht mehr durch den Spam-Filter geprüft werden können. Sie können, falls die neue Vorgehensweise zu Problemen führt, auch weiterhin eine höchstzulässige Größe konfigurieren. Der Wert 0 (null) in der Konfiguration bewirkt ab jetzt aber, dass keine Größenbegrenzung mehr gilt. Der Wert der höchstzulässigen Größe wird ab jetzt nicht mehr in KB sondern in MB angegeben. Eine etwa bestehende Größenbegrenzung wurde entsprechend umgerechnet. Falls keine Größenbegrenzung konfiguriert war, wurde der Wert 0 gesetzt. Sie sollten im Konfigurationsdialog Sicherheit | Spam-Filter | Einstellungen den Wert daraufhin prüfen, ob er Ihren Anforderungen entspricht.

[21527] Die Übersichten über die Warteschlangen auf der Haupt-Benutzeroberfläche wurden um die Spalten "Domäne des Absenders" und "Domäne des Empfängers" erweitert. Aufgrund dieser Erweiterung mussten einmalig die etwa zuvor gespeicherten Spaltenbreiten auf die Voreinstellungen zurückgesetzt werden. Wenn Sie die Spaltenbreiten nunmehr erneut anpassen, werden die angepassten Spaltenbreiten wieder gespeichert werden.

[18617] Der Host-Filter wird per Voreinstellung jetzt auch auf MSA-Verbindungen angewendet. Falls gewünscht, können Sie die entsprechende Option im Konfigurationsdialog Sicherheit | Sicherheits-Manager | Filter | Host-Filter deaktivieren.

[2356] Per Voreinstellung gestatten die MDaemon-Dienste IMAP, Webmail und ActiveSync den Zugriff auf freigegebene gemeinsam genutzte Ordner gesperrter Benutzerkonten ab jetzt nicht mehr. Sie können dieses Verhalten mithilfe neuer Einstellungen im Konfigurationsdialog Einstellungen | Server-Einstellungen | Öffentliche & Freigegebene Ordner anpassen.

BESONDERS WICHTIGE NEUE LEISTUNGSMERKMALE

[14587] Cluster-Betrieb

Mithilfe des neuen Cluster-Dienstes, den MDaemon unterstützt, können Sie Ihre Konfiguration durch mehrere MDaemon-Server in Ihrem Netzwerk gemeinsam nutzen lassen. Hierdurch können Sie auch Hardware oder Software zur Lastverteilung einsetzen und die durch den Betrieb des E-Mail-Systems verursachte Systemlast auf mehrere MDaemon-Server verteilen. Verarbeitungsgeschwindigkeit und Effizienz können hierdurch gesteigert werden, da die Netzwerkauslastung gleichmäßiger verteilt, Lastspitzen verringert und die für das E-Mail-System zur Verfügung stehenden Ressourcen besser ausgenützt werden können. Der Dienst kann auch die Ausfallsicherheit Ihres E-Mail-Systems erhöhen, falls bei einem Ihrer Server ein Hardware- oder Softwareausfall auftritt. Nähere Informationen über die Konfiguration von MDaemon für den Cluster-Betrieb finden Sie in der Hilfe zu MDaemon.

[17087] REQUIRETLS (RFC 8689)

Die Arbeiten der IETF an dem Verfahren RequireTLS sind abgeschlossen. Dieses Verfahren wird ab jetzt unterstützt. Mithilfe von RequireTLS können Sie festlegen, welche Nachrichten zwingend über TLS-geschützte Verbindungen übermittelt werden müssen. Steht TLS für die Übermittlung einer solchen Nachricht nicht zur Verfügung, oder sind die Parameter, die während des TLS-Verbindungsaufbaus und für die beteiligten Zertifikate übermittelt werden, nicht akzeptabel, so werden die Nachrichten zurückgeleitet und nicht etwa ohne TLS zugestellt. Eine vollständige Beschreibung für RequireTLS finden Sie in englischer Sprache in dem RFC-Dokument 8689, insbesondere in den Abschnitten Abstract (Zusammenfassung), Introduction (Einführung) und Security Considerations (Betrachtungen zur Sicherheit).

RequireTLS ist per Voreinstellung aktiv. Sie können dieses Leistungsmerkmal mithilfe einer neuen Option im Konfigurationsdialog Sicherheit | Sicherheits-Manager | SSL & TLS | DNSSEC deaktivieren. Grundsätzlich sollte es problemlos sein, das Leistungsmerkmal aktiviert zu lassen. Es wirkt nur auf solche Nachrichten, die aufgrund einer Aktion des Inhaltsfilters entsprechend gekennzeichnet werden, oder die an nach dem Schema +requiretls@Domäne.TLD aufgebaute E-Mail-Adressen (z.B. arvel+requiretls@mdaemon.com) versandt werden. Regeln des Inhaltsfilters für die genannte Kennzeichnung müssen Sie selbst erstellen. Alle anderen Nachrichten werden so verarbeitet, als ob das Leistungsmerkmal nicht aktiv wäre. Nachrichten, für die RequireTLS aktiv ist, können nur dann erfolgreich versandt werden, wenn bestimmte Bedingungen alle erfüllt sind. Ist auch nur eine Bedingung nicht erfüllt, so werden die Nachrichten nicht etwa über eine unverschlüsselte Verbindung übermittelt sondern an den Absender zurückgeleitet. Folgende Bedingungen sind zu erfüllen:

RequireTLS verlangt, dass MX-Einträge durch DNSSEC-geschützte Abfragen ermittelt werden; alternativ können die MX-Hosts auch durch MTA-STS geprüft werden. Sie können DNSSEC im Konfigurationsdialog Sicherheit | Sicherheits-Manager | SSL & TLS | DNSSEC konfigurieren und dabei angeben, nach welchen Kriterien die DNSSEC-Abfragen erfolgen. DNSSEC verlangt entsprechend konfigurierte DNS-Server, die Sie selbst bereitstellen müssen. Die MDaemon-Datendateien für den IP-Cache und die MX-Hosts wurden aktualisiert und berücksichtigen jetzt die DNSSEC-Konfiguration. Es steht hierzu eine neue Option im Konfigurationsdialog Einstellungen | Server-Einstellungen | DNS & IPs | IP-Cache zur Verfügung, und die Hinweise am Beginn der Datendatei für die MX-Hosts wurden entsprechend aktualisiert.

RequireTLS stellt einen wichtigen Fortschritt gegen mehrere mögliche Angriffe auf die Sicherheit von E-Mail-Systemen dar, und unser Unternehmen ist stolz darauf, hieran beteiligt gewesen zu sein. Wir hoffen, dass alle E-Mail-Systeme im kommenden Jahr dieses Leistungsmerkmal unterstützen werden.

[18705] DOMÄNEN-/UNTERNEHMENSWEITE VERSCHLÜSSELUNG ÜBER MDPGP MITHILFE EINES EINZIGEN SCHLÜSSELS

MDPGP unterstützt jetzt die Verschlüsselung von Nachrichten zwischen Domänen mithilfe eines einzigen Schlüssels für alle Benutzer. Ein Beispiel hierzu: Sollen alle zwischen "Domäne-A" und "Domäne-B" ausgetauschten Nachrichten verschlüsselt übermittelt werden, soll aber gleichzeitig vermieden werden, jeden Benutzer der Domänen mit einem eigenen Schlüsselpaar auszustatten und die Nutzung der Schlüssel entsprechend zu verwalten, so bietet das neue Leistungsmerkmal hierfür eine Lösung:

"Domäne-A" und "Domäne-B" übermitteln einander auf einem frei wählbaren Weg ihre öffentlichen Schlüssel. Sie können beispielsweise die öffentlichen Schlüssel über das Kontextmenü der Benutzeroberfläche von MDPGP exportieren und per E-Mail versenden. Sie können, falls gewünscht, neue besondere Schlüssel für diesen Zweck erstellen und dazu nach Anklicken der Schaltfläche "Schlüssel für bestimmten Benutzer erzeugen" die neue Option "Domänenschlüssel (Domäne.TLD)" verwenden. Der Erstellungsvorgang entspricht ansonsten dem Vorgang für die Erstellung benutzerindividueller Schlüssel. Sie können auch bereits bestehende Schlüssel verwenden. Sobald jede Domäne den öffentlichen Schlüssel der jeweils anderen Domäne erhalten hat, kann dieser mithilfe der Schaltfläche "Domänen-Schlüssel importieren" auf der Benutzeroberfläche von MDPGP importiert werden; hierbei wird der Domänenname der Domäne angegeben, deren Nachrichten mit diesem Schlüssel verschlüsselt werden sollen.

Falls einer Domäne bereits ein öffentlicher Schlüssel vorliegt, den sie nutzen will, und dieser Schlüssel bereits im Schlüsselbund enthalten ist, kann der Schlüssel mithilfe der neuen Option "Schlüssel als Domänen-Schlüssel festlegen" im Kontextmenü der Benutzeroberfläche von MDPGP als Domänen-Schlüssel festgelegt werden.

Für diese Art der Verschlüsselung dürfen Sie keinen Schlüssel nutzen, für den Ihnen auch der zugehörige geheime Schlüssel vorliegt. Nutzen Sie einen solchen Schlüssel, dann verschlüsselt MDPGP die Nachricht zunächst, stellt dann aber sofort fest, dass der geheime Schlüssel für die Entschlüsselung bekannt ist, und entschlüsselt die Nachricht daher unmittelbar wieder.

Nach Abschluss des oben dargestellten Konfigurationsvorgangs erstellt MDPGP eine Regel des Inhaltsfilters, die bewirkt, dass alle an die betreffende Domäne gerichteten Nachrichten mit dem ausgewählten öffentlichen Schlüssel verschlüsselt werden. Sie können diesen Vorgang steuern, indem Sie die Regel im Inhaltsfilter aktivieren oder deaktivieren, und Sie können die Regel auch anpassen. Beispielsweise könnten Sie die Regel auf mehrere Domänen oder nur auf bestimmte Benutzer innerhalb der Domänen wirken lassen. Der Inhaltsfilter ermöglicht auch solche Anpassungen.

[18705 TEIL 2] VERSCHLÜSSELUNG ABGEHENDER NACHRICHTEN ANHAND DER IP-ADRESSE DES EMPFÄNGERS (Hierzu sollte eine gesonderte ID angelegt werden.)

MDPGP wurde um eine Option erweitert, mit deren Hilfe sie bestimmte Schlüssel IP-Adressen zuordnen können. Wird eine abgehende SMTP-Verbindung mit einer hier zugeordneten IP-Adresse hergestellt, so werden alle abgehenden Nachrichten, die an diese IP-Adresse übermittelt werden, vor der Übermittlung mit dem der IP-Adresse zugeordneten Schlüssel verschlüsselt. Nachrichten, die bereits verschlüsselt sind, werden nicht verändert und nicht erneut verschlüsselt. Dieses Leistungsmerkmal ist beispielsweise in Anwendungsfällen hilfreich, in denen Sie sicherstellen wollen, dass alle Nachrichten an bestimmte Gegenstellen (etwa wichtige Partner, Zulieferer, verbundene Unternehmen usw.) immer verschlüsselt werden.

[9745] MAKROS FÜR NACHRICHTEN IN MAILINGLISTEN

Der Abschnitt Routing im Editor für Mailinglisten wurde um einige Optionen erweitert, mit deren Hilfe Makros im Nachrichtentext von Nachrichten genutzt werden können, die in Mailinglisten veröffentlicht werden. Beispielsweise können jetzt alle Listennachrichten personalisiert werden. In den Einleitungs- und Schlusstexten wurden Makros auch bisher schon unterstützt; neu ist die Unterstützung für Makros im Nachrichtentext selbst. Da sich die Makros auf die einzelnen Empfänger der Listennachrichten beziehen, sind sie in solchen Mailinglisten nutzbar, für die die Option "Listennachrichten an jedes Mitglied einzeln zustellen" aktiv ist. Dieses Erfordernis ist auch der Grund dafür, dass die Optionen in den Abschnitt Routing aufgenommen wurden. Da anzunehmen ist, dass nicht unbedingt beliebige Mitglieder einer Mailingliste die Makros nutzen sollen, kann die Nutzung und Umsetzung der Makros auf solche Nachrichten beschränkt werden, in denen der Absender das Listenkennwort angibt. Eine entsprechende Option steht zur Verfügung; ist sie aktiv, und wird das Listenkennwort nicht angegeben, so werden die Makros nicht umgesetzt. Das Listenkennwort gehört zu einer bereits bestehenden Option, die Sie im Abschnitt Moderation finden. Wird kein Listenkennwort festgelegt, so kann jedes Listenmitglied mit der Berechtigung zum Veröffentlichen von Nachrichten die Makros in den Nachrichtentexten nutzen. Es dürfte sich daher empfehlen, entweder ein Listenkennwort festzulegen oder die Makros insgesamt nur für Mailinglisten zu aktivieren, in denen die Mitglieder in der Regel nur Lesezugriff haben. Es sind aber natürlich auch andere Anwendungsfälle denkbar. Die folgenden Makros stehen zur Verfügung:

Bei der Umsetzung des Makros für den vollständigen Namen können sowohl die Formate "Vorname Nachname" als auch "Nachname, Vorname" verarbeitet werden.

[19572] VERBESSERTES SYSTEM ZUR HIJACKING-ERKENNUNG

Der Konfigurationsdialog Sicherheit | Sicherheits-Manager | Filter | Hijacking-Erkennung wurde verbessert. Es stehen neue Optionen zur Verfügung, die MDaemon veranlassen, zu zählen, wie oft echtheitsbestätigte Benutzer versuchen, E-Mail-Nachrichten an ungültige Empfänger zu senden. Ein Empfänger wird dann als ungültiger Empfänger gezählt, wenn während der Übermittlung der Nachricht der Server des Empfängers auf den Befehl RCPT hin einen Fehler 5xx meldet. Treten zu viele solche Fehler binnen zu kurzer Zeit auf, so kann MDaemon das Benutzerkonto des Absenders einfrieren. Der Postmaster wird hiervon per E-Mail benachrichtigt und kann das Benutzerkonto wieder freigeben. Dieses neue Leistungsmerkmal verwirklicht eine leistungsfähige Maßnahme, um Benutzerkonten zu schützen, deren Zugangsdaten entwendet wurden, und die zum Spam-Versand in großem Umfang missbraucht werden. Dem Leistungsmerkmal liegt die Annahme zugrunde, dass beim den gängigen Versuchen, Spam zu versenden, die Fehler 5xx (Benutzer unbekannt) häufig auftreten werden. Das Leistungsmerkmal soll verhindern, dass Benutzerkonten nach einem Hijacking zu umfangreichen Schaden anrichten.

Im Rahmen der Umsetzung dieses Leistungsmerkmals mussten die Optionen zur Auswertung und Bearbeitung der Absenderkopfzeile From in einen eigenen Konfigurationsdialog verlegt werden, um Platz für die neuen Optionen zur Hijacking-Erkennung zu schaffen. Die Einstellungen zur Auswertung der Absenderkopfzeile From befinden sich jetzt im Konfigurationsdialog Sicherheit | Sicherheits-Manager | Filter | Auswertung der Absenderkopfzeile From.

[22391] WARTESCHLANGE FÜR ZEITVERSETZTE ZUSTELLUNG UND VERBESSERUNGEN BEIM ZURÜCKRUFEN VON NACHRICHTEN

MDaemon verfügt jetzt über eine eigene Warteschlange für Nachrichten, deren Zustellung verzögert oder zeitversetzt erfolgt. Die Verzögerung in der Zustellung kann aufgrund des Leistungsmerkmals Zurückrufen von Nachrichten oder aufgrund der jetzt unterstützten Kopfzeile Deferred-Delivery (zeitversetzte Zustellung) eintreten. Vor Einführung dieser neuen Wartschlange war die Eingangs-Warteschlange bisweilen mit Nachrichten überfüllt, deren Zustellung zeitversetzt erfolgte, und die bisweilen die Zustellung normaler Nachrichten verlangsamten. Auf der Benutzeroberfläche stehen nun eine neue Registerkarte Zeitversetzt in der Protokollübersicht sowie ein neuer Abschnitt im Knoten Warteschlangen zur Verfügung, über die der Inhalt der Warteschlange für zeitversetzte Zustellung betrachtet werden kann. Die betreffenden Nachrichten werden durch das System in die Warteschlange für zeitversetzte Zustellung aufgenommen, und Datum und Uhrzeit, zu der sie die Warteschlange verlassen sollen, sind in den Dateinamen kodiert. MDaemon prüft die Warteschlange für zeitversetzte Zustellung einmal pro Minute und verschiebt die Nachrichten, deren Zustellzeitpunkt gekommen ist, in die Eingangs-Warteschlange. Von dort aus werden sie normal weiter verarbeitet. Die entsprechende Aktivität wird im Protokoll Routing vermerkt.

Das Zurückrufen von Nachrichten ist ab jetzt auch ohne zeitversetzte Zustellung möglich, und die Nachrichten müssen nicht in die Warteschlange für zeitversetzte Zustellung eingestellt werden. Sie können daher die Zeitverzögerung, falls gewünscht, auf den Wert 0 setzen. Hiermit verbunden ist aber das beachtliche Risiko, dass Nachrichten, die zurückgerufen werden sollen, zum Zeitpunkt des Rückrufs bereits zugestellt sind. Eine Verzögerung von mindestens 1-2 Minuten erscheint daher empfehlenswert. Den Benutzern bleibt sonst recht wenig Zeit, um festzustellen, dass sie eine Nachricht zurückrufen wollen, den Rückruf auszulösen und MDaemon noch Zeit zu geben, die Anforderung auszuführen. Dem gegenüber steht, dass MDaemon beim Zurückrufen von Nachrichten die Nachrichten ab jetzt auch aus den Warteschlangen für externe Nachrichten entfernen kann, und dass in diesen Warteschlangen ohnehin eine gewisse Verzögerung in der Verarbeitung eintreten kann. Es erschien daher nicht nötig, zwingend eine weitere Verzögerung durch Nutzung der Warteschlange für zeitversetzte Zustellung vorzugeben. Ist Ihre MDaemon-Installation aber so konfiguriert, dass abgehende Nachrichten sofort zugestellt werden, sobald sie die Warteschlangen für externe Nachrichten erreichen, dann sollten Sie die zeitversetzte Zustellung in Erwägung ziehen und nicht den Wert 0 verwenden; ansonsten bleibt gegebenenfalls nicht ausreichend Zeit, um zurückgerufene Nachrichten noch aus den Extern-Warteschlangen zu entfernen.

MDaemon protokolliert jetzt die Nachrichten-ID der jeweils letzten E-Mail-Nachricht, die lokale Benutzer nach der Anmeldung echtheitsbestätigt versenden. Hierdurch können die Benutzer die jeweils letzte versandte Nachricht (und nur diese) zurückrufen, indem sie den Begriff RECALL auf die Betreffzeile einer Nachricht setzen und diese Nachricht an das MDaemon-Systemkonto (mdaemon@) senden. Will ein Benutzer die letzte versandte Nachricht zurückrufen, so braucht er dann nicht erst die Nachrichten-ID zu recherchieren und in die Anforderung einzusetzen. Will er hingegen eine andere Nachricht zurückrufen, so muss er weiterhin entweder die Nachrichten-ID der zurückzurufenden Nachricht auf die Betreffzeile setzen oder die zurückzurufende Nachricht aus seinem Ordner für gesendete Objekte an die Anforderung als Dateianlage anfügen.

Neben der letzten jeweils durch die Benutzer versandten E-Mail-Nachricht speichert MDaemon auch die Speicherorte und Nachrichten-IDs der letzten 1000 E-Mail-Nachrichten, die durch alle echtheitsbestätigten Benutzer insgesamt gesendet wurden. Die Auswertung des Inhalts der Nachrichten-Verzeichnisse ist damit nicht mehr notwendig, und die hiermit in Zusammenhang stehende, gegebenenfalls erhebliche Leistungseinbuße wird vermieden. Mithilfe einer neuen Option im Konfigurationsdialog Einstellungen | Server-Einstellungen | Zurückrufen von Nachrichten kann diese Zahl auch erhöht werden (beispielsweise, wenn über den Server besonders viel E-Mail-Verkehr abgewickelt wird). Das Zurückrufen von Nachrichten schlägt fehl, wenn die zurückzurufende Nachricht nicht in den letzten 1000 versandten Nachrichten (oder einem abweichenden Wert) enthalten ist. Aufgrund dieser neuen Vorgehensweise können zurückgerufene Nachrichten auch nach der Zustellung noch aus den Postfächern der Benutzer entfernt werden; sie erscheinen nach dem Rückruf nicht mehr in den Mailclients und auf den mobilen Endgeräten der Benutzer.

Nachrichten, die an mehrere Empfänger gesandt wurden, werden alle durch die Anforderung zum Zurückrufen zurückgerufen. Das Zurückrufen von Nachrichten ist nur für Nachrichten möglich, die die Kopfzeile X-Authenticated-Sender enthalten. Diese Einschränkung ist aus Sicherheitsgründen erforderlich, und sie verhindert den Rückruf von Nachrichten durch andere Benutzer als den Absender. Ist das Leistungsmerkmal Zurückrufen von Nachrichten aktiv, so ist die Option zum Ausblenden der Kopfzeile X-Authenticated-Sender im Konfigurationsdialog Einstellungen | Voreinstellungen | Kopfzeilen daher wirkungslos.

[13710] PROTOKOLL FÜR FEHLGESCHLAGENE VERSUCHE ZUR ECHTHEITSBESTÄTIGUNG

Die Registerkarte Sicherheit wurde um eine untergeordnete Registerkarte "Fehlgeschlagene Echtheitsbestätigungen" ergänzt, und es besteht ab jetzt eine hierzu gehörige Protokolldatei. In diesem Protokoll wird jeder Anmeldeversuch oder Versuch zur Echtheitsbestätigung protokolliert, der für SMTP, IMAP und POP fehlschlägt. Jeder Versuch wird auf einer eigenen Zeile protokolliert. Protokolliert werden auch das genutzte Übermittlungsprotokoll, die Verbindungs-ID, nach der in anderen Protokollen gesucht werden kann, die IP-Adresse der Gegenstelle, die die Echtheitsbestätigung erfolglos versucht hat, der verwendete Anmeldename (dies kann auch ein Alias sein), und das Benutzerkonto, dem der Anmeldename zugeordnet ist (falls kein übereinstimmendes Benutzerkonto besteht, wird "none" protokolliert).

Sie können über das Kontextmenü der jeweiligen Zeile in der Protokolldarstellung auf der Benutzeroberfläche die IP-Adresse der Gegenstelle in die Schwarze Liste eintragen lassen.

[4915] ECHTHEITSBESTÄTIGUNG BEI WEITERLEITUNG/ROUTING VON NACHRICHTEN

Der Programmkode, der der Weiterleitung von Nachrichten dient, wurde an mehreren Stellen um Funktionen zur Echtheitsbestätigung und Anmeldung ergänzt. Aufgrund dieser Änderungen können jetzt mehrere Dateien im Verzeichnis \APP\ verschleierte Anmelde- und Kennwortdaten in sehr schwacher Verschlüsselung enthalten. Zu diesen Dateien gehören forward.dat, gateways.dat, MDaemon.ini, alle GRP-Dateien für Mailinglisten und weitere Dateien. Die eingesetzte Verschlüsselung ist stark genug, um das Ablesen der Kennwörter durch einen Blick über die Schulter eines Bedieners zu verhindern, aber sie ist nicht stark genug, um Hackern den Zugriff unmöglich zu machen. Wir weisen Sie daher, wie auch sonst, darauf hin, dass Sie die Funktionen des Betriebssystems sowie weitere Maßnahmen nutzen müssen, um das System, auf dem MDaemon läuft, und die Verzeichnisstruktur von MDaemon gegen unbefugten Zugriff zu sichern.

[4915] Der Konfigurationsdialog Einstellungen | Server-Einstellungen | Server und Zustellung | Unzustellbare Nachrichten wurde um Optionen erweitert, mit deren Hilfe Sie AUTH-Anmeldenamen und -Kennwörter für die Nutzung auf den jeweils angegebenen Hosts konfigurieren können. Der Konfigurationsdialog wurde außerdem neu gestaltet, und einige Texte wurden aktualisiert, um die Funktionsweise der Optionen besser zu beschreiben.

[9333] Der Abschnitt Routing im Editor für Mailinglisten wurde um Optionen erweitert, mit deren Hilfe Sie AUTH-Anmeldenamen und -Kennwort für den in diesem Abschnitt konfigurierten Host festlegen können.

[22385] Der Abschnitt Weiterleitung im Gateway-Manager wurde um mehrere Optionen erweitert, mit deren Hilfe Sie für die Weiterleitung von Nachrichten an andere Domänen und Hosts AUTH-Anmeldenamen und Kennwörter konfigurieren können. Der Konfigurationsdialog wurde außerdem neu gestaltet, und einige Texte wurden aktualisiert, um die Funktionsweise der Optionen besser zu beschreiben.

[22413] Der Abschnitt Freigabe wartender Nachrichten im Gateway-Manager wurde um mehrere Optionen erweitert, mit deren Hilfe Sie für die Freigabe wartender Nachrichten an andere Domänen, Hosts und IP-Adressen AUTH-Anmeldenamen und Kennwörter konfigurieren können. Der Konfigurationsdialog wurde außerdem neu gestaltet, und einige Texte wurden aktualisiert, um die Funktionsweise der Optionen besser zu beschreiben. 

[22427] Der Abschnitt Weiterleitung im Konfigurationsdialog Benutzerkonten-Editor | Benutzerkonten-Einstellungen wurde um mehrere Optionen erweitert, mit deren Hilfe Sie für die Weiterleitung von Nachrichten an andere Domänen, Hosts und IP-Adressen AUTH-Anmeldenamen und Kennwörter konfigurieren können. Der Konfigurationsdialog wurde außerdem neu gestaltet, und einige Texte wurden aktualisiert, um die Funktionsweise der Optionen besser zu beschreiben.

[17402] HOST-BEZOGENE ECHTHEITSBESTÄTIGUNG

Dem Konfigurationsdialog Einstellungen | Server-Einstellungen wurde der neue Abschnitt Host-bezogene Echtheitsbestätigung hinzugefügt. In diesem Abschnitt können Sie für beliebige Hosts Port, Anmeldenamen und Kennwort konfigurieren. Sendet MDaemon Nachrichten per SMTP an einen hier erfassten Host, so werden die dem Host hier zugeordneten Anmeldedaten verwendet. Bitte beachten Sie, dass diese Anmeldedaten nur dann verwendet werden, wenn für die jeweilige Aufgabe besonders konfigurierte Anmeldedaten nicht zur Verfügung stehen. Konfigurieren Sie beispielsweise Anmeldedaten mithilfe der neuen Optionen zur Weiterleitung im Benutzerkonten-Editor (siehe Eintrag 22427 oben) oder mithilfe der neuen Optionen zur Freigabe wartender Nachrichten im Gateway-Editor (siehe Eintrag 22413 oben) oder mithilfe anderer, für bestimmte Aufgaben besonders vorhandener Optionen, so werden diese aufgabenspezifischen Anmeldedaten statt der hier konfigurierten Anmeldedaten verwendet. Dieses Leistungsmerkmal arbeitet nur mit Hostnamen, nicht mit IP-Adressen. Bei der Umsetzung wurde eine Entscheidung zugunsten der Hostnamen getroffen, da diese benutzerfreundlicher sind. Die zugehörige Benutzeroberfläche ist bewusst einfach gehalten und vermeidet unnötige Komplexität.

Vor einigen Jahren wurde die Möglichkeit vorgesehen, Anmeldenamen und Kennwörter in der Datei MXCACHE.DAT zu speichern; dies diente als unkomplizierte Problemlösung für bestimmte Anwendungsfälle bei Kunden. Diese Möglichkeit besteht nach wie vor, aber die Anmeldenamen und Kennwörter in dieser Datei werden im Klartext gespeichert. Die neue Host-bezogene Echtheitsbestätigung ermöglicht dieselben Funktionen, sodass Anpassungen an der Datei MXCACHE.DAT nicht mehr erforderlich sind. Die Host-bezogene Echtheitsbestätigung nutzt die Datei HostAuth.dat, in der Anmeldenamen und Kennwörter in (wenn auch schwach) verschlüsselter Form gespeichert sind. Für das neue Leistungsmerkmal steht auch ein Konfigurationsdialog auf der Benutzeroberfläche zur Verfügung; es ist daher gegenüber der manuellen Bearbeitung der Datei MXCACHE.DAT vorzugswürdig. Falls gewünscht, können Sie auch die Datei HostAuth.dat mit Notepad bearbeiten und Anmeldenamen und Kennwörter im Klartext eintragen; diese werden dann durch MDaemon verschlüsselt. Entsprechende Hinweise finden Sie in den Erläuterungen am Beginn der Datei HostAuth.dat.

[4085] VERBESSERUNGEN FÜR BENUTZERDEFINIERTE WARTESCHLANGEN UND NACHRICHTEN-ROUTING

Der Konfigurationsdialog Warteschlangen | Nachrichten-Warteschlangen | Benutzerdefinierte Warteschlangen wurde verbessert. Sie können jetzt für jede Warteschlange für die externe Zustellung Host, Anmeldenamen, Kennwort, SMTP-Antwortpfad und Port angeben. Falls diese Daten konfiguriert sind, werden grundsätzlich alle Nachrichten in der Warteschlange unter Berücksichtigung der Daten und der neuen Einstellungen zugestellt. Nachrichten können aber auch dann unter Verwendung besonderer Einstellungen zur Zustellung zugestellt werden, wobei die Einstellungen in diesem Konfigurationsdialog übergangen werden. Dieses Verhalten ist beabsichtigt und stellt nicht etwa einen Fehler dar.

Die Benutzeroberfläche für die neuen Optionen zeigt noch gewissen Verbesserungsbedarf, kann jedoch derzeit nicht umgestaltet werden. Die Benutzeroberfläche zeigt in der Listenübersicht Anmeldenamen und Kennwörter nicht an und wird dies auch nicht in Zukunft tun. Über die Benutzeroberfläche können bestehende Einträge nicht bearbeitet werden; um einen Eintrag zu ändern, müssen Sie den bestehenden Eintrag löschen und einen neuen Eintrag anlegen. Die Schaltflächen zum Hinzufügen und Entfernen von Einträgen wirken unmittelbar; Sie können die hiermit durchgeführten Änderungen nicht durch Anklicken einer Schaltfläche Abbrechen rückgängig machen. Änderungen, die Sie durchführen, sind endgültig. Eine verbesserte Benutzeroberfläche kann nicht in Aussicht gestellt werden; jedoch überwiegen die Vorteile der neuen Optionen die mit der Benutzeroberfläche verbundenen Einschränkungen deutlich. Sie können jetzt beliebig viele Extern-Warteschlangen einrichten, Nachrichten mithilfe des Inhaltsfilters auf die Warteschlangen verteilen und dabei alle durch den Inhaltsfilter unterstützten Bedingungen anwenden, jeder Warteschlange einen eigenen Zeitplan für die Zustellung zuweisen, und das Routine flexibel und den Anforderungen entsprechend einrichten.

[8504] VERBESSERUNGEN FÜR DIE DOMÄNEN-VERTEILUNG

[16798] Seit einiger Zeit wurden im Rahmen der Domänen-Verteilung Abfragen nach den Absenderdaten, die im SMTP-Befehl MAIL übermittelt wurden, nach Bedarf durchgeführt. Hierbei wurden Nachrichten oft mit der Fehlermeldung "Echtheitsbestätigung erforderlich" (Authentication Required) abgewiesen; dies war problematisch, weil der Absender dann keine Echtheitsbestätigung durchführen konnte, wenn sein Benutzerkonto auf einem anderen Server gehostet war. Dieses Problem wurde behoben; MDaemon kann jetzt Nachrichten zur Zustellung annehmen, die von Benutzerkonten versandt werden, die auf anderen Servern gehostet sind. Eine Echtheitsbestätigung wird dabei nicht verlangt. Die neue Vorgehensweise kann mithilfe einer Option im Konfigurationsdialog Sicherheit | Sicherheits-Manager | Echtheitsbestätigung für Absender | SMTP-Echtheitsbestätigung geändert werden. Falls Sie die Abfragen nach den Absenderdaten aus dem SMTP-Befehl MAIL im Rahmen der Domänen-Verteilung nicht durchführen lassen wollen, können Sie die Abfragen durch Bearbeiten einer neuen Option im Konfigurationsdialog Einstellungen | Server-Einstellungen | Domänen-Verteilung insgesamt abschalten. Die Optionen sind per Voreinstellung aktiv.

[8504] Der Konfigurationsdialog Einstellungen | Server-Einstellungen | Domänen-Verteilung wurde um eine Option ergänzt, mit deren Hilfe jetzt auch Mailinglisten in die Domänen-Verteilung einbezogen werden können. Geht bei aktivierter Option eine Nachricht für eine Mailingliste ein, so wird für jeden Host in der Infrastruktur der Domänen-Verteilung, bei dem ebenfalls eine Version der Mailingliste gespeichert ist (MDaemon prüft durch eine Abfrage, ob diese Voraussetzung erfüllt ist), eine Kopie erstellt. Die Kopien werden an die betreffenden Hosts übermittelt, und diese stellen die Nachrichten den Listenmitgliedern zu, deren Benutzerkonten bei Ihnen jeweils gehostet sind. Mailinglisten können somit über mehrere Server verteilt werden, ohne dass damit eine Einschränkung in der Funktionalität verbunden wäre. Diese Option arbeitet nur dann, wenn jeder Host in der Domänen-Verteilung die IP-Adressen der anderen Hosts als vertraute IP-Adressen behandelt (siehe Konfigurationsdialog Sicherheit | Sicherheits-Manager | Sicherheits-Einstellungen | Vertraute IPs), da die Nachrichten sonst möglicherweise mit der Fehlermeldung abgewiesen werden, dass der Absender kein Listenmitglied ist.

[8723] Der Konfigurationsdialog Einstellungen | Server-Einstellungen | Domänen-Verteilung wurde um eine Schaltfläche Erweitert ergänzt. Durch Anklicken dieser Schaltfläche können Sie eine Datei öffnen, in der die Domänennamen erfasst werden können, die die Domänen-Verteilung nutzen dürfen. Ist die Datei leer (dies entspricht der Voreinstellung), so können alle Domänen auf Ihrem System die Domänen-Verteilung nutzen. Nähere Informationen hierzu enthält der Erläuterungstext am Beginn der Datei.

[12628] VERBESSERTE STEUERUNG FÜR DIE WEITERLEITUNG VON NACHRICHTEN

[12628] Der Konfigurationsdialog Einstellungen | Voreinstellungen | Verschiedenes wurde um eine Option erweitert, mit deren Hilfe Administratoren verhindern können, dass Benutzerkonten ihre Nachrichten außerhalb ihrer eigenen Domänen weiterleiten. Konfiguriert ein von dieser Option betroffener Benutzer eine Weiterleitung an eine Zieladresse in einer externen Domäne, so wird die weitergeleitete Nachricht in die Defekt-Warteschlange verschoben. Diese Option wirkt nur auf Nachrichten, die aufgrund der für das Benutzerkonto konfigurierten Weiterleitungsoptionen weitergeleitet werden.

[12791] Der Abschnitt Weiterleitung des Benutzerkonten-Editors wurde um eine Schaltfläche "Zeitplan" erweitert, mit deren Hilfe die Benutzerkonten einen Zeitplan für Beginn und Ende der Weiterleitung konfigurieren können. Eine entsprechende Option steht auch für die Vorlagen für Benutzerkonten zur Verfügung. Ist diese Option aktiv, so wird die Weiterleitung nur an den ausgewählten Tagen und in dem ausgewählten Zeitraum an diesen Tagen wirksam. 

[12927] Das Feld für die Zieladresse für die Weiterleitung in der Vorlage für neue Benutzerkonten verarbeitet jetzt auch Makros für Benutzerkonten. Zu dem Zeitpunkt, in dem die Vorlage für die Erstellung neuer Benutzerkonten verwendet wird, sind die einzigen für das Benutzerkonto bekannten und durch Makros auswertbaren Daten der vollständige Name, die Domäne, das Postfach und das Kennwort des Benutzerkontos. Ein Beispiel hierzu: Soll jedes neue Benutzerkonto so konfiguriert werden, dass alle Nachrichten an eine E-Mail-Adresse mit demselben Postfachnamen in einer anderen Domäne weitergeleitet werden, so können Sie als Zieladresse für die Weiterleitung $MAILBOX$@andereDomäne.com eintragen. Makros sind auch in den neuen Feldern Senden als, AUTH-Anmeldename und AUTH-Kennwort zulässig.

[12455] Wird eine Nachricht weitergeleitet, so wird hierbei ab jetzt auch der Zeitstempel für den letzten Zugriff auf das weiterleitende Benutzerkonto aktualisiert. Hierzu wird der Wert LastAccess in der Datei hiwater.mrk des weiterleitenden Benutzerkontos aktualisiert. Diese Änderung bewirkt, dass Benutzerkonten, die lediglich der Weiterleitung eingehender Nachrichten dienen, nicht mehr wegen Inaktivität unbeabsichtigt gelöscht werden. Beachte: Der Zeitstempel wird nur aktualisiert, wenn die Weiterleitung tatsächlich stattgefunden hat und nicht etwa durch bestimmte Konfigurationsoptionen verhindert wurde; dies kann beispielsweise vorkommen, wenn die Zieladresse für die Weiterleitung oder der Zeitpunkt der Weiterleitung (siehe Eintrag 12791 oben) den konfigurierten Beschränkungen nicht entsprechen. Es genügt für die Aktualisierung des Zeitstempels nicht, dass lediglich eine Weiterleitung konfiguriert ist, sie muss auch tatsächlich wirksam sein.

[15076] VERBESSERTE SMTP-ECHTHEITSBESTÄTIGUNG

[15076] und [15265] Der Konfigurationsdialog Sicherheit | Sicherheits-Manager | Echtheitsbestätigung für Absender | SMTP-Echtheitsbestätigung wurde um zwei Optionen erweitert. Die Option "Echtheitsbestätigung auf dem SMTP-Port nicht zulassen" deaktiviert die Unterstützung für AUTH auf dem SMTP-Port vollständig. AUTH wird dann auch nicht mehr in der Antwort auf den Befehl EHLO gemeldet. Der Befehl AUTH wird als unbekannter Befehl behandelt, falls er durch einen SMTP-Client übermittelt wird. Die Option "... IPs von Gegenstellen nach versuchter Echtheitsbestätigung in Dynamischen Filter eintragen" fügt die IP-Adresse solcher Gegenstellen dem Dynamischen Filter hinzu, die die Echtheitsbestätigung versuchen, obwohl sie deaktiviert ist. Die Verbindung wird sofort getrennt. Diese Optionen sind besonders in den Fällen hilfreich, in denen alle legitimen Benutzerkonten den MSA- oder einen anderen Port nutzen, um Nachrichten nach Echtheitsbestätigung einzuliefern. In solchen Fällen kann davon ausgegangen werden, dass Versuche, auf dem SMTP-Port eine Echtheitsbestätigung oder Anmeldung durchzuführen, von Angreifern ausgehen müssen.

[10458] VERBESSERTE VERWALTUNG DER BENUTZERKONTEN

[10458] Der Benutzerkonten-Manager wurde verbessert. Sie können jetzt Benutzerkonten auswählen, die aktiv sind, die MultiPOP nutzen, oder deren Kontingente zu mindestens 70 % oder zu mindestens 90 % ausgeschöpft sind, oder für die keine Weiterleitung aktiv ist. Sie können auch das Textfeld Beschreibung nach beliebigen Texten durchsuchen und Benutzerkonten anhand der Suchergebnisse auswählen.

[14105] Das Kontextmenü des Benutzerkonten-Managers wurde um einige Optionen erweitert, mit deren Hilfe Sie alle ausgewählten Benutzerkonten in Mailinglisten und Gruppen aufnehmen und aus ihnen entfernen können.

[23083] Mithilfe einer neuen Option im Kontextmenü des Benutzerkonten-Managers können Sie ein bestehendes Benutzerkonto kopieren und hieraus ein neues Benutzerkonto erstellen. In das neue Benutzerkonto werden außer Vor- und Nachname, Postfachname, Kennwort und Nachrichten-Verzeichnis alle Einstellungen des kopierten bestehenden Benutzerkontos übernommen.

[11427] Der Konfigurationsdialog Benutzerkonten-Editor | Benutzerkonten-Einstellungen | IMAP-Filter wurde um die Schaltfläche Veröffentlichen erweitert. Durch Anklicken dieser Schaltfläche wird die neue Regel auf alle anderen Benutzerkonten angewendet, die derselben Domäne wie das bearbeitete Benutzerkonto angehören. Hiermit soll insbesondere dann Zeit gespart werden, wenn eine Regel für alle Benutzer übernommen werden soll. Außerdem wurde ein Problem im Editor für die Regeln behoben, das dazu führte, dass Regeln doppelt angelegt werden konnten.

[9921] AKTIVIERUNG DES SCHUTZES GEGEN STÖRUNGEN FÜR GANZE DOMÄNEN

[9921] Der Konfigurationsdialog Domänen-Manager | Hostname & IP wurde um neue Optionen erweitert, mit deren Hilfe der Schutz gegen Störungen für eine Domäne insgesamt aktiviert werden kann. Solange der Schutz gegen Störungen aktiv ist, weist die Domäne alle Verbindungen von allen Benutzern für alle Dienste ab, nimmt aber von außen eingehende Nachrichten weiterhin zur Zustellung an. Sie können einen Zeitplan festlegen, nach dem der Schutz gegen Störungen beginnt und endet. Ein Beispiel hierzu: Der Zeitplan 1. April 2020 bis 31. Mai 2020, jeweils 17.00 Uhr bis 07.00 Uhr, Montag bis Freitag, bewirkt, dass an allen genannten Wochentagen im genannten Zeitraum zwischen 17.00 und 07.00 Uhr keine E-Mail-Dienste für die Benutzer der Domäne verfügbar sind. Wenn Sie das Beginndatum löschen, wird hierdurch der Zeitplan deaktiviert, und der Schutz gegen Störungen bleibt für die Domäne aktiv.

[22678] VERBESSERTE ARCHIVIERUNG

Das einfache System zur Archivierung von Nachrichten in MDaemon wurde geändert und ist jetzt effizienter und einheitlicher. Die im Konfigurationsdialog Einstellungen | Server-Einstellungen | Archivierung enthaltenen Optionen arbeiten jetzt wie folgt: Wird eine Nachricht aus einer lokalen Warteschlange in das Nachrichtenverzeichnis eines Benutzers zugestellt, so wird hierbei eine Archivkopie erstellt (diese Kopie wird im Ordner IN des Empfängers abgelegt, falls die Archivierung entsprechend konfiguriert ist). Wird eine Nachricht aus eine Extern-Warteschlange zur Zustellung per SMTP aufgenommen, so wird dabei eine Archivkopie erstellt, und zwar unabhängig davon, ob der Versand erfolgreich war (diese Kopie wird im Ordner OUT des Absenders abgelegt, falls die Archivierung entsprechend konfiguriert ist). In das Routing-Protokoll werden dabei Einträge nach dem Schema "ARCHIVE message: pgp5001000000172.msg" oder "* Archived: (archives)\company.test\in\frank@company.test\arc5001000000023.msg" bei Verarbeitung lokaler und externer Nachrichten eingefügt.

Die folgenden Arten von Nachrichten werden nicht archiviert: Nachrichten aus Mailinglisten, Spam (die entsprechende Option wurde abgeschafft und aus dem Konfigurationsdialog Einstellungen | Server-Einstellungen | Archivierung entfernt), mit Viren infizierte Nachrichten, Systemnachrichten und Nachrichten von Autobeantwortern.

Es wurde eine neue Warteschlange "ToArchive" (ZuArchivieren) hinzugefügt, die über die Benutzeroberfläche nicht erreichbar ist. Diese Warteschlange wird in regelmäßigen Abständen auf Nachrichten geprüft, die dort abgelegt wurden (manuell, durch ein Plugin oder in sonstiger Weise). Nachrichten, die in der Warteschlange gefunden werden, werden sofort archiviert und danach gelöscht. Werden Nachrichten gefunden, die von der Archivierung ausgeschlossen sind, so werden sie einfach gelöscht. Der Verzeichnispfad zu dieser Warteschlange lautet \MDaemon\Queues\ToArchive\. Die Protokollansicht Routing und das Protokoll Routing enthalten Einträge, die über die erfolgreiche Archivierung Aufschluss geben.

[20579] Die Archivierung verschlüsselter Nachrichten wird jetzt einheitlicher gehandhabt. Per Voreinstellung werden unverschlüsselte Kopien verschlüsselter Nachrichten archiviert. Kann eine Nachricht nicht entschlüsselt werden, so wird sie verschlüsselt archiviert, da sonst keine Möglichkeit der Archivierung besteht. Mithilfe einer neuen Option im Konfigurationsdialog Einstellungen | Server-Einstellungen | Archivierung können Sie bestimmen, dass verschlüsselte Nachrichten verschlüsselt archiviert werden.

[22693] Der Konfigurationsdialog Einstellungen | Server-Einstellungen | Archivierung wurde um eine Option erweitert, mit deren Hilfe Nachrichten archiviert werden können, die an die Adressen für Veröffentlichungen in öffentlichen Ordnern gesandt werden. Diese Option ist besonders deswegen hilfreich, weil solche Adressen nicht mehr als Benutzerkonten auf dem Server selbst gehostet werden müssen (siehe Eintrag 12311 oben). Diese Option ist per Voreinstellung aktiv.

[15960] EFFIZIENTERE PROTOKOLLIERUNG

[15960] Der Platz im Konfigurationsdialog Einstellungen | Server-Einstellungen | Protokollierung | Einstellungen war erschöpft, und einige Optionen mussten daher in den neuen Konfigurationsdialog Einstellungen | Server-Einstellungen | Protokollierung | Weitere Einstellungen verschoben werden. Die zusätzlichen Optionen wurden erforderlich, um die Erstellung von Protokolldateien für Vorgänge zu vermeiden, für die die Protokollierung deaktiviert ist. Ein Beispiel hierzu: Falls die Option "SMTP-Aktivität protokollieren" deaktiviert ist, so besteht kein Grund, eine leere SMTP-Protokolldatei anzulegen. MDaemon legt daher keine leeren Protokolldateien mehr an. Für Vorgänge, deren Protokollierung abgeschaltet ist, werden bereits bei Programmstart keine Protokolldateien mehr erstellt. Protokolldateien, die bei Deaktivierung einer Protokollfunktion bereits bestanden, bleiben bestehen und werden nicht etwa gelöscht. Fehlende Protokolldateien werden erstellt, sobald die Protokollierung für den zugehörigen Vorgang aktiviert wird. Ein Beispiel hierzu: Wurden bislang keine POP-Aktivitäten protokolliert, so besteht hierfür keine Protokolldatei. Die Protokolldatei wird erst angelegt, wenn die Protokollierung der POP-Aktivität aktiviert wird. Für nicht genutzte Dienste und für genutzte Dienste, für die die Protokollierung abgeschaltet ist, werden keine Protokolle mehr erstellt. Diese dargestellte Änderung wirkt auf alle Protokolldateien, die das Kernmodul von MDaemon selbst verwaltet (dies sind die meisten Protokolle). Protokolldateien für Dynamischen Filter, Instant Messaging, XMPP, WDaemon und Webmail werden außerhalb von MDaemon selbst gepflegt und sind von der Änderung nicht betroffen; sie bestehen unverändert. Gleichwohl wurden die Protokollierungsfunktionen insgesamt verbessert. Aufgrund dieser Änderungen müssen Sie MDaemon neu starten, falls Sie im Konfigurationsdialog Einstellungen | Server-Einstellungen | Protokollierung | Betriebsart des Protokolls die Betriebsart ändern.

[22480] Es wurden weitere Änderungen an der Protokollierung vorgenommen. ATRN-Verbindungen werden jetzt richtig dargestellt, alle Protokolle werden in einheitlicher Farbkennzeichnung dargestellt, die Darstellung der Verbindungs- und untergeordneten Child-IDs wurde vereinheitlicht, und der MultiPOP-Server protokolliert jetzt keine überschüssigen und unnötigen Daten in den Fällen mehrt, in denen das Kontingent eines Benutzerkontos überschritten ist.

Das Routing-Protokoll war das einzige Protokoll, in dem die Verarbeitung von Nachrichten aus Eingangs- und lokalen Warteschlangen vermerkt war. In diesem Protokoll wird jetzt auch die Verarbeitung der Extern-Warteschlangen im Rahmen von Zustellversuchen vermerkt. Sie müssen daher nicht mehr das Routing-Protokoll und das Protokoll für abgehende SMTP-Verbindungen (SMTP[out]) durchsuchen, um die Verarbeitung einer Nachricht nachzuvollziehen.

[22617] VERBESSERTE ACTIVE-DIRECTORY-INTEGRATION

[8930] Die Nutzung von Gruppen im Active Directory durch MDaemon wurde bereinigt und arbeitet jetzt wie beabsichtigt. Wird ein Benutzer einer Gruppe im Active Directrory hinzugefügt, so wird er auch in MDaemon hinzugefügt. Wird ein Benutzer aus der Gruppe entfernt, so wird er in MDaemon je nach Konfiguration gesperrt. Hierzu ist es erforderlich, die Suchfilter richtig zu konfigurieren (weitere Informationen hierzu finden Sie weiter unten). Dieses Leistungsmerkmal war besonders schwierig zu implementieren, da das Active Directory das Hinzufügen von Benutzern zu Gruppen oder die Aufnahme von Benutzer in Gruppen nicht als Änderung an dem betroffenen Benutzer sondern als Änderung an der Gruppe behandelt, MDaemon aber auf Änderungen an dem Benutzer prüfen muss. Diese Vorgehensweise bedingte umfangreiche Anpassungen in MDaemon, und hiermit war beträchtlicher Programmieraufwand verbunden. Um dieses Problem zu beheben, benötigt MDaemon einen Suchfilter, der Änderungen an der Gruppe und Änderungen an Benutzern erkennt, die Mitglieder der Gruppe sind. Die Prüfung auf Änderungen an der Gruppe ist erforderlich, da MDaemon jetzt das Attribut "members" (Mitglieder) auswertet. Die Prüfung auf Benutzer, die Mitglieder der Gruppe sind, ist erforderlich, weil MDaemon hieraus die für die Konfiguration des Benutzerkontos nötigen Daten gewinnt. Die Prüfung auf Änderungen an der Gruppe liefert diese Daten nicht.

Ein Beispiel für einen Suchfilter anhand einer Gruppe namens "MeineGruppe":

     (|(&(ObjectClass=group)(cn=MeineGruppe)) (&(objectClass=user)(objectCategory=person)(memberof=cn=Meine Gruppe,ou=meine,dc=domain,dc=com)))
Sie müssen die Attribute "ou=" und "dc=" durch die für Ihr Netzwerk gültigen Attribute ersetzen.

Weitere Verbesserungen während des Versionszyklus 20 erscheinen möglich, aber die dargestellte Funktion sollte nun richtig arbeiten.

[12696] Wenn Sie den Eintrag "Alias=%proxyAddresses%" in der Datei ActiveDS konfigurieren, erstellt MDaemon einen Alias für jeden Wert, den die Abfrage dieses Attributs liefert, und der einer SMTP-Adresse entspricht. Adressen des Typs X.500 und andere Arten von Adressen bleiben unberücksichtigt.

[16403] Der Konfigurationsdialog Benutzerkonten | Benutzerkonten-Einstellungen | Active Directory | Echtheitsbestätigung wurde um eine neue Option erweitert, mit deren Hilfe Sie einen eigenen Suchfilter für Suchen nach Kontakten definieren können. Bislang wurden Kontakte mithilfe des Suchfilters für Benutzer gesucht. Es steht auch eine eigene Schaltfläche zur Verfügung, um den Suchfilter für Kontakte zu testen. Die Suchvorgänge im Active Directory wurden verbessert; sind die Suchfilter identisch, so werden aufgrund einer einzigen Abfrage alle betreffenden Daten aktualisiert. Unterscheiden sich die Suchfilter, so sind zwei getrennte Abfragen erforderlich. Die Beschriftung einiger Steuerelemente in diesem Konfigurationsdialog mussten aus Platzgründen aktualisiert werden. Die Option für die Seitengröße wurde entfernt; diese kann nach wie vor manuell geändert werden, falls ein Wert über 1000 erforderlich ist.

[20853] Folgende Felder wurden in die Vorlagen für die Datei ActiveDS.dat aufgenommen; sie werden jetzt in Kontakteinträge einbezogen, wenn Adressbücher aufgrund der Überwachung des Active Directory erstellt und aktualisiert werden: abTitle=%personalTitle%, abMiddleName=%middleName%,abSuffix=%generationQualifier%, abBusPager=%pager%, abBusIPPhone=%ipPhone%, abBusFax=%FacsimileTelephoneNumber%. Falls diese Felder zu Problemen führen, oder falls Sie sie bei Erstellung und Aktualisierung von Kontakten nicht berücksichtigen wollen, können Sie ihre Einträge durch Bearbeiten der Datei ActiveDS.dat mit Notepad deaktivieren.

[6444] Der Abschnitt [CharacterConvert] in der Datei ActiveDS.dat zur Steuerung der Zeichenumsetzung wurde verbessert. Es ist jetzt möglich, einzelne Zeichen durch zwei Zeichen zu ersetzen (etwa, wenn ß durch SS ersetzt wird). Sie können die Datei ActiveDS.dat mit Notepad öffnen, um die voreingestellten Umsetzungen einzusehen. Die Umsetzungen werden jetzt per Voreinstellung sowohl für das Feld Alias (falls ein solcher besteht) als auch für das Feld Postfach (Mailbox) vorgenommen.

[11729] Kontakte in öffentlichen Ordnern werden jetzt gelöscht, wenn das zugehörige Benutzerkonto aus dem Active Directory gelöscht wird. Die Kontakte werden nur dann gelöscht, wenn sie durch die Active-Directory-Integration erstellt wurden. Sie können dieses Verhalten mithilfe einer neuen Option im Konfigurationsdialog Benutzerkonten | Benutzerkonten-Einstellungen | Active Directory | Überwachung deaktivieren, falls gewünscht.

[22617] Erstellt oder aktualisiert die Active-Directory-Überwachung ein Benutzerkonto, und wird dabei ein Postfachname festgestellt, der als Postfachname für MDaemon zu lang ist, so wird ab jetzt, wie auch bisher, der Postfachname verkürzt; zugleich wird ab jetzt ein Alias mit dem vollständigen Postfachnamen angelegt. Ab jetzt werden außerdem die Anmerkungen für Administratoren für die Benutzerkonten aktualisiert, wenn Benutzerkonten und Aliasnamen angelegt werden. Dies soll die Nachverfolgung dieser Vorgänge erleichtern.

[22578] Die Funktion zum Testen der Einstellungen im Konfigurationsdialog Mailinglisten-Manager | Active Directory wurde angepasst sodass die Ergebnisse jetzt in der Sprache der jeweiligen MDaemon-Sprachfassung angezeigt werden. Die Ergebnisse enthalten darüber hinaus den Basis-DN, der für den Test verwendet wurde.

[22661] Im Konfigurationsdialog Mailinglisten-Manager | Active Directory können Sie jetzt ein Active-Directory-Attribut für den vollständigen Namen der Listenmitglieder konfigurieren. Falls gewünscht, können Sie auch weiterhin nur ein Active-Directory-Attribut für die E-Mail-Adresse angeben. Um den vollständigen Namen für das Listenmitglied abzurufen, können Sie ein Active-Directory-Attribut nach folgendem Schema nutzen: "displayName, Email" anstatt nur "Email". Das erste jeweils angegebene Attribut soll das Active-Directory-Attribut bezeichnen, das den vollständigen Namen enthält (dies ist üblicherweise "displayName"). Das zweite Attribut soll die E-Mail-Adresse bezeichnen.

[22589] Die Texte, die im Protokoll für das Active Directory erscheinen, sind jetzt in die jeweiligen Sprachfassungen übersetzt. Die Protokolle unterstützen jetzt verschiedene Textfarben.

[22657] MDaemon erstellt keine Benutzerkonten mehr für AD-Gruppenobjekte. MDaemon erstellte bislang Benutzerkonten für Gruppen, falls ein Suchfilter AD-Gruppen enthielt. Da aber Benutzerkonten nur für Mitglieder von Gruppen, nicht aber für die AD-Gruppen selbst, erstellt werden sollen, und da solche Benutzerkonten für Gruppen mehrere Daten nicht enthalten, die für ein vollständiges MDaemon-Benutzerkonto erforderlich sind, wurde diese Vorgehensweise geändert.

[23019] Nach Änderungen an Benutzerkonten im Active Directory können diese Benutzerkonten in MDaemon unter Umständen erneut angelegt werden, obwohl sie vorher über die MDaemon-Benutzeroberfläche oder die MDaemon-Remoteverwaltung gelöscht worden waren. Mithilfe einer neuen Option im Konfigurationsdialog Benutzerkonten | Benutzerkonten-Einstellungen | Active Directory | Überwachung kann dies verhindert werden. Die Option, Benutzerkonten nicht erneut zu erstellen, wenn sie zuvor in MDaemon gelöscht wurden, ist per Voreinstellung aktiv.

[22613] VERBESSERTE AUSWERTUNG DER ABSENDERKOPFZEILE FROM

[22613] Die Funktionen zur Änderung der Absenderkopfzeile From wurden umbenannt in "Auswertung der Absenderkopfzeile From" und um einige Leistungsmerkmale erweitert. Im Konfigurationsdialog Sicherheit | Sicherheits-Manager | Filter | Auswertung der Absenderkopfzeile From steht eine neue Option zuf Verfügung, mit deren Hilfe die Anzeigenamen in den Absenderkopfzeilen From auf Inhalte untersucht werden, die wie E-Mail-Adressen aussehen. Werden solche Inhalte gefunden, und entsprechen sie nicht der tatsächlichen E-Mail-Adresse, so werden sie durch die tatsächliche E-Mail-Adresse ersetzt. Ein Beispiel hierzu: Enthäkt die Absenderkopfzeile "From:" den Inhalt From: "Frank Thomas " , so wird sie geändert in From: "Frank Thomas " . Diese Option ist per Voreinstellung abgeschaltet. Es steht außerdem eine neue Option zur Verfügung, die bewirkt, dass die Einstellungen in diesem Konfigurationsdialog nur auf Nachrichten aus Verbindungen ohne Echtheitsbestätigung angewendet werden. Die Einstellungen betreffen auch weiterhin nur lokale Benutzer.

[21601] PRÜFUNG AUF KOMPROMITTIERTE KENNWÖRTER

MDaemon kann die Kennwörter der Benutzer mit einer Liste als kompromittiert bekannter Kennwörter abgleichen, die durch einen Drittanbieter bereit gestellt wird. Der Abgleich findet statt, ohne dass das Kennwort an den Anbieter übermittelt wird. Ist das Kennwort eines Benutzers in der Liste vorhanden, so bedeutet dies nicht, dass das Benutzerkonto kompromittiert oder gehackt wurde. Es bedeutet vielmehr, dass das fragliche Kennwort bereits einmal auf einem anderen System durch einen Benutzer verwendet wurde, und dass dieses verwendete Kennwort von einer Datenpanne oder einem Datenleck betroffen war. Kennwörter, die als kompromittiert bekannt und veröffentlicht sind, können durch Angreifer für Wörterbuchangriffe verwendet werden. Kennwörter, die noch nie auf anderen Systemen verwendet wurden, sind demgegenüber sicherer. Nähere Informationen hierzu erhalten Sie, indem Sie nach dem Stichwort "Pwned Passwords" suchen.

Mithilfe einer neuen Option im Konfigurationsdialog Benutzerkonten | Benutzerkonten-Einstellungen | Andere Funktionen | Kennwörter können Sie MDaemon veranlassen, Kennwörter dann zurückzuweisen, wenn diese in der Liste als kompromittiert bekannter Kennwörter enthalten sind. MDaemon kann wahlweise auch die Kennwörter der Benutzerkonten in konfigurierbaren Intervallen während der Anmeldung überprüfen und dem Benutzer per E-Mail eine Warnmeldung senden, falls das Kennwort in der Liste gefunden wird. Die Warnmeldungen können mithilfe zweier Vorlagen angepasst werden, die im Verzeichnis \MDaemon\App abgelegt sind. Da die Anweisungen zum Ändern des Kennworts unter anderem davon abhängen, ob das Kennwort durch MDaemon verwaltet wird oder die Benutzerprüfung über das Active Directory erfolgt, stehen zwei Vorlagen zur Verfügung: CompromisedPasswordMD.dat und CompromisedPasswordAD.dat. Die Empfänger, Betreffzeile und Nachrichtentext können mithilfe von Makros individuell angepasst werden.

[16696] SMTP MTA-STS (RFC 8461) - STRICT TRANSPORT SECURITY

Die Arbeiten der IETF an dem Verfahren MTA-STS sind abgeschlossen. Dieses Verfahren wird ab jetzt unterstützt. Das Verfahren SMTP MTA Strict Transport Security (abgekürzt MTA-STS, Verfahren für erzwungene Transportverschlüsselung für SMTP-Mailserver) gestattet es Anbietern von E-Mail-Dienstleistungen, bekannt zu geben, dass sie durch Transport Layer Security (TLS) transportverschlüsselte SMTP-Verbindungen unterstützen. Darüber hinaus können sie festlegen, dass SMTP-Server, die Nachrichten an sie übermitteln wollen, die Übermittlung von Nachrichten an solche MX-Hosts ablehnen sollen, die TLS mit einem vertrauenswürdigen Server-Zertifikat nicht unterstützen.

MTA-STS ist per Voreinstellung aktiv. Sie können dieses Leistungsmerkmal im Konfigurationsdialog Sicherheit | Sicherheits-Manager | SSL & TLS | SMTP-Erweiterungen deaktivieren.

Um MTA-STS für Ihre eigene Domäne zu konfigurieren, ist zunächst eine Richtliniendatei erforderlich. Diese Richtliniendatei muss über HTTPS von einem URL abrufbar sein, der nach dem Schema https://mta-sts.Domäne.TLD/.well-known/mta-sts.txt gebildet ist. An die Stelle "Domäne.TLD" ist dabei Ihr eigener Domänenname zu setzen. Der Inhalt der Richtliniendatei muss Einträge des folgenden Formats enthalten:

version: STSv1
mode: testing
mx: mail.domain.tld
max_age: 86400

Als "mode" (Modus) können Sie "none" (kein MTA-STS), "testing" (MTA-STS im Versuchsbetrieb) und "enforce" (Richtlinie ist verpflichtend) einsetzen. Für jeden Ihrer MX-Hostnamen soll eine eigene Zeile "mx" enthalten sein. Subdomänen können Sie durch Jokerzeichen erfassen, etwa "*.Domäne.TLD". Der Gültigkeitszeitraum für den Eintrag (max_age) wird in Sekunden angegeben. Häufig verwendete Werte hierfür sind 86400 (dies entspricht einem Kalendertag) und 604800 (dies entspricht einer Woche).

Weiter ist ein DNS-Eintrag des Typs TXT erforderlich. Dieser Eintrag muss unter _mta-sts.Domäne. TLD abrufbar sein. An die Stelle "Domäne.TLD" ist dabei Ihr eigener Domänenname zu setzen. Der Eintrag muss dem folgenden Format entsprechen:

v=STSv1; id=20200206T010101;

Der Wert der "id" muss immer dann geändert werden, wenn sich der Inhalt der Richtliniendatei ändert. Es ist üblich, als "id" einen Zeitstempel zu verwenden.

[21595] Berichte über SMTP TLS (RFC 8460)

Mithilfe des Leistungsmerkmals zur Berichterstellung über SMTP TLS können Domänen, die MTA-STS einsetzen, Benachrichtigungen erhalten, falls der Abruf der Richtliniendatei für MTA-STS oder die Herstellung einer verschlüsselten Verbindung mittels STARTTLS fehlschlagen. Wenn dieses Leistungsmerkmal aktiv ist, sendet MDaemon einmal täglich einen Bericht an alle Domänen, an die MDaemon während des zurückliegenden Tages Nachrichten versandt oder zu versenden versucht hat, und für die MTA-STS aktiv ist.

Dieses Leistungsmerkmal ist per Voreinstellung abgeschaltet. Sie können es im Konfigurationsdialog Sicherheit | Sicherheits-Manager | SSL & TLS | SMTP-Erweiterungen deaktivieren. Wenn Sie dieses Leistungsmerkmal aktivieren, müssen Sie sicherstellen, dass auch die Signatur abgehender Nachrichten über DKIM aktiv ist, da E-Mail-Nachrichten mit TLS-Berichten signiert werden sollen. Sie können die DKIM-Signatur im Konfigurationsdialog Sicherheit | Sicherheits-Manager | SSL & TLS | Echtheitsbestätigung für Absender | DKIM-Signatur aktivieren.

Wenn Sie sich TLS-Berichte an Ihre eigene Domäne senden lassen wollen, ist hierzu ein DNS-Eintrag des Typs TXT erforderlich. Dieser Eintrag muss unter _smtp._tls.Domäne.TLD abrufbar sein. An die Stelle "Domäne.TLD" ist dabei Ihr eigener Domänenname zu setzen. Der Eintrag muss dem folgenden Format entsprechen:

v=TLSRPTv1; rua=mailto:mailbox@domain.tld

An die Stelle "Postfach@Domäne.TLD" müssen Sie die E-Mail-Adresse setzen, an die die Berichte für Ihre Domäne gesandt werden sollen.

ÄNDERUNGEN UND NEUE LEISTUNGSMERKMALE

BEHOBENE FEHLER

MDaemon ist eine eingetragene Marke von MDaemon Technologies, Ltd.
Copyright ©1996-2020 MDaemon Technologies, Ltd.