.SearchFilter

Filter string for selecting the desired emails (optional)

The filters are applied directly to the mail server.

This property only applies to the interfaces/protocols Graph, EWS, IMAP and Gmail. In each case, use the specific syntax of the interface or protocol for the filter:

For the Graph and EWS interfaces, the program uses the "Category" email property to set the current processing status and select new emails that do not yet have a status value. This fixed internal filter is implicitly combined with the value configured via .SearchFilter. This way, you can restrict the query result even more.

.SubjectFilter

.BodyFilter

.HasAttachFilter

Filters to select emails for further processing based on the subject, the message body, or the existence of a file attachment with a specific name (optional)

These filters are subsequently applied to the list of existing emails returned by the mail server.

Depending on the specific filter criterion and the mail interface, the complete mail object must be retrieved from the server in order to determine the relevant filter values. The use of these client-side filters is generally less performant and generates more data traffic than the server-side filters.

Syntax: see Name Filter Syntax.

.FileFilter

.IgnoreInlineAttach

File name filter to limit the file attachments extracted from the found emails (optional)

The Boolean value .IgnoreInlineAttach can be used to define whether inline attachments are generally ignored (default value: false). Inline attachments are, for example, graphics embedded in HTML message text, such as logos in email signatures.

.AttachMailBody

.AttachMailItem

Boolean values indicating whether the message text as a whole and the email object as a whole are attached to the xSuite Interface document as additional file attachments (default value: false)

The first attachment is given the base name body with the format-dependent extension .txt or .html. The second attachment is given the name mail.eml.

.PoBox[].Id

.PoBox[].User(*)

.PoBox[].Password(*§)

.PoBox[].UserMailForAutoUrl

.PoBox[].InputFolder(*)

.PoBox[].BackupFolder(%)

.PoBox[].ErrorFolder(%)

Definition of the properties for access to a single email folder of a specific user

The .Id property is a program-internal, unique and freely selectable identifier for identifying the folder from which an email was read. If it is omitted, a standard identifier with a consecutive number will be assigned.

The .User and .Password properties are required for authentication with the mail server. The user-specific password is not always relevant, depending on the interface used and the authentication procedure.

Under .UserMailForAutoUrl, you can specify the user's email address for the EWS interface to automatically determine the .Url value with the server address (optional).

.InputFolder, .BackupFolder, and .ErrorFolder are the names of the email folders from which new emails are read and the folders to which these emails are moved after having been read or after a processing error has occurred. These folders are not relevant for the POP3 protocol; it does not support folder structures.

At the Exchange interfaces, the emails remain in the inbox folder during xSuite Interface's ongoing processing. The Category property of these emails has the status value "Working." Once processed, the emails are moved to the backup folder. If an error occurs while the emails are being read in, the emails will remain in the inbox folder with the status "Error." If a processing error does not occur until later, the emails will be moved to the "Error" folder.

With the IMAP protocol, status values cannot be written to the email objects. In contrast to the standard behavior of the program, emails are therefore moved to the backup folder immediately after being read in so that they are not read repeatedly from the inbox folder. If no backup folder is defined, emails are deleted immediately after they have been successfully read. With POP3, as it does not offer any folder structures, emails are always deleted directly. The definition of an error folder is not useful in this constellation, as an email that has already been deleted cannot be moved any further. With Gmail, the processing logic is analogous to the IMAP protocol, but the emails are not stored in folders; instead, they are provided with the configured folder names as labels.

For the two Exchange interfaces, specify the display name of a folder (e.g., Inbox in English). One or more subfolders can be added using backslashes (\). For IMAP and Gmail, the input folder is always Inbox and a / is used as the separator.

In addition to the standard reading of a user's personal messages, the Exchange interfaces also allow access to other users' shared folders. To enable shared access, prefix the folder name with \shared\email-address\. For the email address, specify that of the user who is sharing the folder. The EWS interface also allows public folders to be queried; to specify this, use the prefix \Public\.

When using the Graph API in conjunction with app-only authentication (see property .OAuthClientSecret), the shared folders are accessed via the sharing user. The .User property is not relevant in this case.