Konfiguration

Erste Schritte mit Maildaemon

Maildaemon besteht aus verschiedenen ausführbaren Dateien, jede mit ihrer eigenen appsettings-Datei. Dieser Abschnitt enthält Informationen über die appsettings-Datei, die grundlegende Anwendungskonfigurationen enthält, die auf alle ausführbaren Maildaemon-Programme angewendet werden können. Die in dieser Konfigurationsdatei vorgenommenen Änderungen haben unabhängig von der verwendeten ausführbaren Datei die gleichen Auswirkungen.

Bitte beachten Sie, dass beim Bearbeiten und Speichern einer appsettings-Datei die Konfiguration nicht automatisch neu geladen wird. Somit muss ein Neustart des Dienstes erfolgen.

Für anwendungsspezifische Konfigurationen lesen Sie bitte die entsprechende Dokumentation:

• API Konfiguration
• Service Konfiguration

Appsettings

Die Datei appsettings.[DOTNET_ENVIRONMENT].json wird verwendet, um verschiedene Einstellungen in maildaemon zu konfigurieren. Der Standardpfad für die Datei appsettings.[DOTNET_ENVIRONMENT].json unter Windows lautet D:\otris\OUC-Tools\maildaemon-service\configs\ bzw. D:\EASY\OUC-Tools\maildaemon-service\configs\ und für den API Dienst D:\otris\OUC-Tools\maildaemon-api\ bzw. D:\EASY\OUC-Tools\maildaemon-api\. DOTNET_ENVIRONMENT entspricht der in den Umgebungsvariablen/Systemvariablen gesetzter Wert für production oder development.

• 💡 Auf dem Produktionssystem lautet der Dateiname appsettings.production.json, wie er während der Installation festgelegt wurde.
• ⚠️ In einer lokalen Entwicklungs- oder Windows-Installation muss der Hostname für RabbitMQ auf localhost gesetzt werden.
• ⚠️ In einer Docker-Umgebung sollte der Hostname für RabbitMQ auf rabbitmq gesetzt werden, was der Name des Docker-Containers ist.
• ⚠️ Sowohl die API- als auch die Service-App stellen eine Verbindung zum RabbitMQ Message Broker her, stellen Sie also sicher, dass beide Konfigurationen identisch sind.
• ⚠️ Bitte ändern Sie nicht die Eigenschaft Default im Abschnitt Database, da dieser Wert für die API und die Service Appsettings gleich sein muss (Standard: Monitoring).
• ⚠️ Stellen Sie die Path-Werte für MailboxConfigs, FolderConfigs (nur im maildaemon-service) und im Bereich Database (nur in maildaemon-api) auf den richtigen Basis-Pfad D:\otris\OUC-Tools oder D:\EASY\OUC-Tools ein.

Limitierung der Abruftage von E-Mails

Ab Version 24.0.8 gibt es eine neue optionale Funktion RetrieveMailsSinceDays in der Datei appsettings.[DOTNET_ENVIRONMENT].json, die mit dem Standardwert 0 ausgeliefert wird.

Dies ist nützlich, wenn Sie nur E-Mails ab einem bestimmten Datum abrufen möchten.

tip

Der Wert wird in Tagen angegeben:

• Wird der Wert auf 0 gesetzt, werden alle E-Mails abgerufen.
• 1 für E-Mails ab gestern
• 2 für E-Mails ab vorgestern usw.
• Ein negativer Wert wird so behandelt, als ob der Wert positiv wäre, d.h. -2 entspricht 2.

💡 Es wird empfohlen den Wert auf 30 zu setzen, um die Anzahl der abgerufenen E-Mails auf die letzten 30 Tage zu begrenzen.

Allgemeine Protokollierung

Standardmäßig werden die Protokolle auf stdout/console mit dem LogLevel verbose ausgegeben. Zusätzlich werden alle Protokollebenen ab Information in einer Datei namens app[aktuelles Datum].log unter dem Verzeichnis logs protokolliert. Die Datenbankprotokollierung ist ebenfalls als Option verfügbar.

Wenn Sie detailliertere Protokolle benötigen, können Sie die folgenden Eigenschaften in der Datei appsettings an Ihre Bedürfnisse anpassen:

• consoleSwitch
• fileSwitch

Überprüfen Sie die folgenden Ereignisebenen:

Level	Verwendung
Verbose	Verbose ist die gesprächigste Stufe, die selten (wenn überhaupt) für eine Produktionsanwendung aktiviert wird.
Debug	Debug wird für interne Systemereignisse verwendet, die von außen nicht unbedingt beobachtbar sind.
Information	Informationsereignisse beschreiben Vorgänge im System, die mit seinen Zuständigkeiten und Funktionen übereinstimmen.
Warning	Ereignisse der Warnstufe werden verwendet, wenn der Dienst beeinträchtigt oder gefährdet ist oder sich möglicherweise außerhalb seiner erwarteten Parameter verhält.
Error	Fehlerereignisse werden verwendet, wenn eine Funktion nicht verfügbar ist oder Erwartungen nicht erfüllt werden.
Fatal	Fatale Ereignisse sind die kritischste Stufe und erfordern sofortige Aufmerksamkeit.