Configure Sender

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.

• 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.

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

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

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.com

  

  Figure: 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.com

  

  Figure: Allow Domain
  

• Block Domain has one domain that is listed Allow Domain.
  Example: zacme.com

  

  Figure: 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.com

  

  Figure: 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.

• 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.