E-Mail-Trigger
Der E-Mail-Trigger überwacht ein Postfach und löst Transfers aus, wenn neue E-Mails eingehen. E-Mails im MIME-Format werden ebenfalls verarbeitet.
Damit ist der Trigger die Empfangsseite des E-Mail-Plug-ins, während das E-Mail-Transferobjekt für den Versand zuständig ist.
„Allgemein“-Tab
| Eigenschaft | Beschreibung |
|---|---|
| Server | Adresse des Mailservers, von dem E-Mails abgeholt werden. |
| Protokoll | Vom Mailserver unterstütztes Abrufprotokoll für den E-Mail-Empfang, zum Beispiel IMAP oder IMAP Idle. Die Auswahl beeinflusst, welche Zeitoptionen im Dialog aktiv sind. |
| Port | Netzwerkport des Mailservers für das gewählte Protokoll. |
| Verschlüsselung | Legt fest, ob und wie die Verbindung verschlüsselt wird. Verfügbare Optionen sind Automatisch, SSL/TLS, STARTTLS, STARTTLS (Optional) und Keine. |
| Vertraute Zertifikate | Legt fest, welchen Zertifikaten für die TLS-Verbindung vertraut wird. - Router: akzeptiert Zertifikate, die im OPC Router als vertrauenswürdig hinterlegt sind. - Windows: verwendet die vertrauenswürdigen Zertifikate aus dem Windows-Zertifikatsspeicher. - Alle (unsicher): akzeptiert auch Zertifikate, die nicht explizit als vertrauenswürdig hinterlegt wurden. |
| Mail-Ordner | Ordner im Postfach, den der Trigger überwacht, z. B. den Posteingang oder einen benutzerdefinierten Unterordner. |
| Polling Intervall (s) | Zeitabstand in Sekunden, in dem auf neue E-Mails geprüft wird. Bei IMAP Idle ist diese Eigenschaft deaktiviert. |
| Idle Timeout | Hält die Verbindung für den angegebenen Zeitraum offen. Geht in dieser Zeit eine E-Mail ein, wird der Wartezustand sofort beendet. Diese Funktion muss vom Mailserver unterstützt werden. Bei IMAP ist diese Eigenschaft deaktiviert. |
| No-Op Intervall | Zeitspanne für Leerlaufprüfungen, wenn keine neuen E-Mails gefunden wurden. Bei IMAP Idle ist diese Eigenschaft deaktiviert. |
| Delay (ms) | Zusätzliche Wartezeit vor der nächsten Aktion nach einer erfolgreichen Triggerauslösung. |
| Wiederholungen | Anzahl der Wiederholungsversuche, bevor der Transfer mit einem Fehler beendet wird. |
| Verarbeitungsreihenfolge | Legt fest, in welcher Reihenfolge E-Mails aus dem überwachten Ordner verarbeitet werden, zum Beispiel Älteste zuerst. |
| Aktion | Bestimmt, wie verarbeitete E-Mails nach der Triggerauslösung weiterbehandelt werden, zum Beispiel ob sie als gelesen markiert und ggfs. archiviert oder gelöscht werden. |
„Anmeldung“-Tab
| Eigenschaft | Beschreibung |
|---|---|
| Anmeldetyp | Legt fest, mit welchem Verfahren sich der Trigger am Mailserver authentifiziert. Im gezeigten Dialog ist Basic Authentication ausgewählt. |
| Windows Anmeldedaten verwenden | Verwendet den Benutzerkontext des OPC-Router-Dienstes anstelle explizit eingetragener Zugangsdaten. |
| Benutzername | Benutzername des Mailkontos für die Anmeldung am Mailserver. |
| Passwort | Verweis auf das verwendete Secret für das Kennwort des Mailkontos. Über die Schaltflächen neben dem Feld können Secrets angelegt, bearbeitet oder entfernt werden. |
| Domäne | Windows-Domäne für die Authentifizierung, falls der verwendete Benutzer zu einer Domänenumgebung gehört. |
Prüfen Sie bei Problemen im E-Mail-Empfang zuerst Protokoll, Port, Verschlüsselung und die verwendete Authentifizierung.
Anmeldetypen
Je nach ausgewähltem Anmeldetyp ändert sich der Inhalt des Reiters Anmeldung. Die folgenden Beispiele zeigen die jeweiligen Dialogvarianten.
Für die OAuth-basierten Anmeldetypen gilt: Die Authority URI ist die Adresse des Anmelde- oder Mandantenendpunkts des Identity-Providers. Über sie wird festgelegt, bei welchem Anbieter und gegebenenfalls in welchem Mandanten die Authentifizierung erfolgt.
Die Redirect URI ist die Rücksprungadresse, die beim Identity-Provider für den Client registriert ist. Sie muss mit der dort hinterlegten Adresse übereinstimmen, damit der Autorisierungsvorgang korrekt abgeschlossen werden kann. Bei nicht interaktiven Verfahren wie Client Credentials wird sie häufig nur aus Konfigurationsgründen verlangt.
Die Scopes legen fest, welche Berechtigungen mit dem Zugriffstoken angefordert werden. Verwenden Sie nur die für den E-Mail-Abruf oder -Versand erforderlichen Berechtigungen und achten Sie darauf, dass diese in der App-Registrierung freigegeben wurden. Bei Microsoft 365 wird für Client Credentials häufig ein .default-Scope verwendet, während bei benutzerbezogenen Verfahren wie Device Code oder ROPC einzelne Berechtigungen wie IMAP.AccessAsUser.All, SMTP.Send oder offline_access üblich sind.
Basic Authentication
Bei Basic Authentication authentifiziert sich der Trigger mit Benutzername, Passwort und optionaler Windows-Domäne.
Microsoft OAuth 2.0 über Client Credentials Flow
Diese Variante ist für technische Konten oder App-Registrierungen ohne interaktive Benutzeranmeldung geeignet. Zusätzlich zu Benutzername, Application ID und Tenant ID konfigurieren Sie den Sicherheitstyp, ein Client Secret oder Clientzertifikat sowie Authority URI, Redirect URI und Scopes.
Microsoft OAuth 2.0 Device Code
Diese Variante eignet sich für Szenarien, in denen die Anmeldung über einen separaten Gerätecode-Prozess erfolgt. Im Dialog konfigurieren Sie Benutzername, Application ID, Tenant ID, Authority URI, Redirect URI und die benötigten Scopes.
Microsoft OAuth 2.0 Benutzername und Passwort (ROPC)
Bei ROPC werden Benutzername und Kennwort direkt für den Tokenabruf verwendet. Zusätzlich konfigurieren Sie Application ID, Authority URI, Redirect URI und die benötigten Scopes.
