Email processor (email)

Table of Contents

Description
Opportunities
Limitations
Parameters
Configuration example
See also

Description

Processor for exchanging email messages with mail servers.

Provides communication with mail servers (IMAP, STMP). Monitors included IMAP directories, places messages received from senders in the data model collection /rest/v1/model/email/Messages, and sends `sending` messages created in it to recipients via SMTP.

Forms collections/classes: email/Profiles, email/Accounts, email/Folders, email/Messages. Allows their further modification in the direction of extending the composition of properties and variants of values of enumerated fields.

Interaction with external business logic is performed using message statuses (`sending`, `sent`, `error`, `received`, `raw`).

Table 1. System Characteristics

Code	`email`
Mode of operation	`Service`
Backup mode	`Active-Passive.`
Types of sites	`Any`
Layer	`Adapter/processor`
Placement	`Internal`
Saving and restoring state on reboot	`No`
appendix	`era_email`

Opportunities

Mail messages can be text, html, or contain both alternatives.
Attachments are saved as attachments to the entity email/Messages (file field) and are accessible via the /rest/v1/model/email/Messages/ID_MESSAGE/attachments.
HTML The content is also saved as an attachment in the html field and can be accessed via the /rest/v1/model/email/Messages/ID_MESSAGE/html.
All inlines (files used within HTML) are saved as attachments in the inlines field and can be accessed via the /rest/v1/model/email/Messages/ID_MESSAGE/inlines.
When a message is received, its original RFC822 content is stored in the entity in the rawMessage field as an attachment and is accessible via /email/Message and accessible via the /rest/v1/model/email/Messages/ID_MESSAGE/rawMessage.
If a message cannot be parsed and decomposed by fields, its uncompressed content is saved and a special status is set `raw`
When an account is created (/rest/v1/model/email/Accounts) and there is a corresponding profile (/rest/v1/model/email/Profiles), it surveys the composition of directories and places them in the collection email/Folders). Polls the composition of directories and places them in the collection email/Folders). Once the directory is turned on, it is monitored for incoming messages, as well as monitoring the email/Messages collection with a filter on the directory for messages ready to be sent.

Limitations

Works in the mode of periodic polling of the IMAP server for incoming messages. The default timeout between polls is 30 seconds. It is controlled by the `after_read_timeout` value in the options field in descending order: /email/Folder, /email/Account, /email/Profile.
The `deleteOnServer` parameter of the directory entity is responsible for deleting emails in the IMAP directory.

Parameters

Description of columns in the table

Table 2. Parameters
Name	Type	Default	Description
`name`	`str`	required	Name. May consist of Latin letters and numbers, must begin with a letter.
`roletype`	`str`	required	Role Type. Possible values: `"email"`.
`iface`	`str`	required	The alias of the server network interface on which the roles will interact internally with each other.
`ext`	`json`	empty	Additional role options. Contains a json object or list.
`enabled`	`bool`	empty	Role activity flag. When set to false, the role does not participate in validation and is not started.
`group`	`int`	required	Group Number. As part of horizontal scaling, a role can be divided into multiple groups on a site, with only one instance active in each group and the rest reserved. Responsibilities between groups are shared across domain sets. Together, all groups maintain a complete domain set. All roles in the same group must have the same responsibility. Integer from `1` to `9999999`.
`order`	`int`	required	The order of a role instance within a group. Defines in what order the flow in the mode will take place Active-Passive.
`include_domains`	`array<str>`	empty	A list of domain names served by this group. Any domain of any level can be specified. Specifying a domain causes its subdomain tree to be served on this group and not on other role groups, excluding only those branches mentioned in other groups. Collectively, all role groups on a site serve a complete domain tree.

Configuration example

The configuration is managed in an application available to master domain administrators. The application hides the full content of the configuration, but it is nevertheless accessible via the API.

The configuration contains a section to describe all instances of all roles. Parameters are defined for each specific role instance.

Example node

{
  "name": "im1",
  "roletype": "im",
  "iface": "eth0",

  "group": 11330,
  "order": 1
}