- 16 Aug 2024
- 9 Minutes to read
- Print
- PDF
Configure Sender
- Updated on 16 Aug 2024
- 9 Minutes to read
- Print
- PDF
The sender configuration screen is displayed for Email medium. As the selected option to configure for is Email, the Sender screen consists of the following sections. By default all these sections are displayed in the expanded view.
Figure: Sender
Allow or Block Email domains
In the Allow or Block email Domains section, the Application Designer can select Domain Type. Type options provided in the dropdown are Allow and Block.
Note
This section will display a subtitle below the heading section as follows:
Select below options to parse or to block the incoming mails.
To configure Allow and Block Email domains, perform the following:
Select Domain Type from the following options:
Allow: Select Allow to parse Emails.Block: Select Block to restrict Emails.
Figure: Allow or Block Email Domains
Note
Help-text icon for Domain field provides an example on the usage.
Example: If Allow is selected, (user@xyzdomain.com) sends an Email then, email from xyzdomain.com will be parsed as the user belongs to xyzdomain.com. If Block is selected, then the email will not be considered for parsing.
Upon selecting Domain Type, an additional field Email Domains is displayed.
Enter Email Domains separated by comma and they appear chips on the field.
Example: Novatech.com, zacme.comNote
Hovering over help-text icon will display the following message:
Enter Domain names separated by comma.Figure: Allow or Block Email Domains
Restrict Email Ids
The Application Designer can restrict individual Email Ids. This enables the system to restrict any incoming mails from the mentioned Ids to be parsed.
Note
This section will display a subtitle below the heading section as follows:
Mention the email ids that should not be considered for parsing
Upon hovering on Help Text of Email Ids, following message is displayed.
Any specific Email Ids that should not be considered for parsing should be entered here. Separated by comma.
Enter the Email Ids separated by comma in the Restrict Email IDs field.
Figure: Restrict Email Ids
Block Headers
Blocking specific email headers when parsing email notifications can serve several important purposes in managing your email notifications effectively and securely. Email headers can contain a lot of technical details that may not be relevant to the content of the notification. By blocking headers, you can reduce the amount of unnecessary information.
Processing of Block Headers
When an email contain any of the Headers from the Block Headers section then, the Mail is not parsed and ticket is not generated. Parser checks these from the key details in the Message.
Following is a sample figure of automatic reply that contain Block Header.
Figure: Block Headers
These headers are commonly used in email systems to identify and handle automated or system-generated messages, preventing email loops and reducing the impact of bulk mailings.
For more information on default Block Headers, refer to the following:
System Default Block Headers
x-auto-response-suppress
autoreply
x-autorespond
auto
auto-submitted
precedence
bulk
junk
x-auto-response-suppress
Purpose: To prevent automatic responses to automated messages, reducing email loops.
This header is used to tell email clients or receiving email servers not to send automated responses to this message. It is often included in automatic replies, calendar invites, or out of office messages to prevent email loops or the unnecessary exchange of auto-generated emails.
autoreply
Purpose: Indicates that the message is an automatic reply, helping recipients and email systems identify it as such.
While not a standardized header in email protocols, when present, this header usually indicates that the email is an automated reply. The purpose is to make it clear to both system (email processing scripts) and humans (email recipients) that the message was generated automatically, often as a response to another email.
x-autorespond:
Purpose: Similar to Autoreply it signals that the message is an automated response.
Similar to Autoreply, this non-standard header signifies that the email was generated automatically in response to another action or message. Email systems or applications may use this to filter or categorize messages as auto-generated.
auto
Purpose: A general indicator that the message is automated, though less standardized than other headers.
This header is not standard and its usage can vary. Generally, if used, it might indicate that the email is automatically generated. Email servers or clients might not universally recognize this header, but it could be used internally within specific systems for sorting or filtering purposes.
auto-submitted
Purpose: An official header defined in RFC 3834 to indicate the degree of automatic generation of the message.
This is a standard header defined in RFC 3834. It's used to indicate that a message was submitted automatically, and not by a human user. Valid values include "no" (message was not submitted automatically), "auto-generated" (message was generated by an automated process),"auto-replied" (message was an automatic reply by the mail system),among others. This header is important for preventing automatic responses to other automatic responses, thereby avoiding email loops.
precedence
Purpose: Originally used to indicate message priority, now commonly used to identify bulk or automated messages.
This header is often used to indicate the type of email, with common values including "bulk," "junk," or "list." When set to values like "bulk" or "list," it may imply the email is part of a large-scale sending, often automated. This header can influence how email systems handle replies, such as not sending "out-of-office" replies to bulk emails.
bulk
Purpose: Indicates that the message is part of a bulk mailing, often used in conjunction with the "precedence" header.
Not typically a standalone header, but seen as a value in other headers like "Precedence." It indicates that the email is part of a mass mailing, which is usually automated. Systems may use this information to filter or manage emails differently, such as reducing the priority of delivery or affecting how the email is displayed.
junk
Purpose: Suggests that the message may be considered low-priority or potentially unwanted, often used for automated or bulk mailings.
Similar to "Bulk," "Junk" isn't usually a standalone header but can appear as a value or in association with filtering systems. It suggests the email is considered unsolicited or less important. This can be used by email systems to automatically sort such messages into a "junk" or "spam" folder.
Actions for New Users
This section is used to configure the details of the Sender. The Application Designer can configure how the system should recognize and react to emails from users if the Email ID is not registered in the User List.
The configuration for unregistered users is based on the following options. By default Discard Email is auto selected.
Discard Email
The Discard Email functions in a way that, upon receiving an Email from an unregistered user the email can be discarded.
Figure: Action for New Users
Upon discarding an Email from an unregistered user, the next action to be performed is configured by the Application Designer. Following are the options that can be configured after discard:
Notify Sender
Using this option, we can send a notification mail to the sender of the mail stating that their email has been discarded. A pre-defined notification will be sent to the user when their mail gets discarded. This pre-defined notification template will be used only for this option and not anywhere else.
In the text editor, enter the required notification message.
Figure: Notify Sender
Notify Administrator
Selecting this option, enables Application Designer to configure user(s) in the Recipients field using a filter option. We can send a notification mail to the selected user(s) of the mail stating that their email has been discarded. A pre-defined notification will be sent when their mail gets discarded. This pre-defined notification template will be used only for this option and not anywhere else.
Figure: Notify Administrator
Create User
When an email from unregistered user sends an email and if the mailbox is configured with a parser rule as to create a new user. Providing control over the creation of a new or unregistered user based on domains. These options the unregistered user can be created in the User List by mapping them to its Fields and its subsequent values. When the mail id of the unregistered user gets created the Fields and Values mapped from here to the user will automatically reflect in the User List.
The following actions can be configured:
Allow Domain
The Allow Domain field is used to enter the names of the domains for which the new user should be created in the user list. The system will create a new user for the allowed domains and also the mail is considered for parse.
Block Domain
The Block Domain field is used to enter the names of the domains for which the new user should not be created in the user list. The system will not create a new user for the blocked domains and the mail is not considered for parse.
Enter Domain names separated by comma in the Allow Domain and Block Domain fields.
Allow and Block Domain Functionality in Create User
The system will recognize as a Domain when the text has a dot(.) without space and separated by comma(,). Multiple Domain names can be added.
Following use-cases apply:
Scenario 1: New Users are created for the listed domains in Allow Domain field.
Scenario 2: New Users are not created for domains listed in Block Domain field.
Scenario 3: New Users are created only for domains allowed in the Allow or Block Email Domains section.
Scenario 4: New Users are created for domains listed in Allow Domain field under Create User even though Domain is not configured in Allow or Block Email Domains section.
Scenario 1
There are two domains added in Allow and Block email Domains.
Example: acme.com, zacme.comFigure: Allow or Block domains
Both of these domains(acme.com, zacme.com) are added in Allow Domain under Create User as Action for New Users.
Figure: Action for New Users
The system will create new users for both the domains.
Scenario 2
In the Create User, Allow Domain has two domains as listed below:
Example: acme.com, zacme.comFigure: Allow Domain
Block Domain has one domain that is listed Allow Domain.
Example: zacme.comFigure: Block Domain
The system will not create new users for domains listed in Allow Domain if it is present in Block Domain.
In this case new users are not created for emails with zacme.com as it exists in both Allow and Block domain.
Scenario 3
There are two domains added in Allow and Block email Domains.
Example: acme.com, zacme.comFigure: Allow or Block domains
There is one more domain with new value is added in Allow Domain under Create User.
Note: This domain is not listed in previous step.
Example: novatech.com (new value in Allow Domain)Figure: Allow Domain in Create User
The system will create new users only for acme.com and zacme.com, since these are the only domains applicable to be allowed. The system will not create new users for novatech.com domain because, this domain is not allowed in the Allow or Block Email Domains section.
Scenario 4
The Domain list is not configured under Allow or Block Email Domains.
Figure: Domain list in Allow or Block Email domains
Domains are listed in Allow Domain field under Create User as Action for New Users.
Figure: Allow Domain in Create User
New Users are created for the Domains listed in Allow Domain field and not present in Block Domain field. Though the Allow or Block Email domains section is not configured.
Fields and Values
The fields and values will display the Domain and Sub-Domain fields by default. The Value field of Domain & Sub-Domain will be auto populated to the selected Domain and Sub-Domain of the parser.
Without selecting a Domain and Sub-Domain create new user cannot be saved.
Multiple layers of Fields can be added by clicking the + icon.
The attributes in the field dropdown cannot be repeated if it’s already been used once.
Figure: Create User
Field Value Functionality
The Users created from here will be automatically mapped to the selected Domain and Sub-Domain of the parser.
The Domain and Sub-Domain will be displayed under the Fields and Values section as mandatory fields and the value will be auto populated.