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.
Zusammenspiel mit dem Postfach
Wie diese Darstellung zu lesen ist, erklärt der Abschnitt Sequenzdiagramme.
Der E-Mail-Trigger überwacht einen Ordner eines IMAP-Postfachs; ein POP3-Abruf ist nicht vorgesehen, das Feld „Protokoll“ kennt nur IMAP und IMAP Idle. Aus jeder gefundenen Nachricht baut der Trigger die Triggerdaten auf und reiht einen Transfer ein, ohne auf dessen Ergebnis zu warten. Die unter „Aktion“ gewählte Behandlung der Nachricht – als gelesen markieren, löschen oder in den Archivordner verschieben – führt der Trigger erst aus, wenn der Transfer beendet ist, und nur, wenn das Transferergebnis zur gewählten Aktion passt. Andernfalls bleibt die E-Mail unverändert im Ordner liegen und wird erneut gefunden.
Das Diagramm zeigt beide Abrufarten des E-Mail-Triggers gegen denselben IMAP-Server und macht sichtbar, dass die unter „Aktion“ gewählte Behandlung der Nachricht erst nach dem Transfer erfolgt und am Transferergebnis hängt. Im Betrieb mit IMAP Idle muss das laufende IDLE dafür abgebrochen werden, und die Nachrichten selbst holt eine zweite, eigens geöffnete Verbindung. Beherrscht der Server kein IDLE, sendet der Trigger stattdessen nur NOOP und wartet zwischen den Versuchen das „No-Op Intervall“ ab. Der letzte Hinweis schließt den Kreis zur Suchmenge: passt das Transferergebnis nicht zur gewählten „Aktion“, bleibt die E-Mail unverändert im Ordner liegen - mit dem Protokoll IMAP greift sie der nächste SEARCH des Polling-Zyklus wieder auf, mit IMAP Idle erst dann, wenn eine weitere neue E-Mail im Ordner eintrifft.
Ablauf des E-Mail-Triggers: Der Trigger holt die Nachrichten aus dem überwachten IMAP-Ordner, startet den Transfer ohne auf ihn zu warten und schreibt erst nach dem Transferende den Status der E-Mail ins Postfach zurück.