Difference between revisions of "Information Systems:Mail flow"

From uniWIKI
Jump to navigation Jump to search
Line 16: Line 16:
 
'''Implemented in:''' Exchange
 
'''Implemented in:''' Exchange
   
When emails are sent to shareholder distribution lists, it is currently a "business rule" to BCC select staff members, with the intent being so that staff remain informed of any mass correspondence in the case they receive calls and questions regarding said correspondence. Rather than implement this business rule by including staff members in the distribution lists themselves (which simply, is bad design), it is more apprporiate to institute a mail flow rule to achieve this same outcome. By doing this, you can also specify the senders to which this rule applies, because some senders that use distribution lists traditionally may intend to send only to recipients suggested by the list name (sending to shareholders should only go to shareholders, because the name of the list is...Shareholders!).
+
When emails are sent to shareholder distribution lists, it is currently a "business rule" to BCC select staff members, with the intent being so that staff remain informed of any mass correspondence in the case they receive calls and questions regarding said correspondence. Rather than implement this business rule by including staff members in the distribution lists themselves (which simply, is bad design), it is more apprporiate to institute a mail flow rule to achieve this same outcome. By doing this, you can also specify the senders to which this rule applies, because some senders that use distribution lists in a more conventional fashion may intend to send only to recipients suggested by the list name (i.e. sending to shareholders should only go to shareholders, because the name of the list is...Shareholders!).
   
 
The implementation of this rule is straightforward - if an email is sent to any of the specified lists, then place these users (individual users specified) in the Bcc field.
 
The implementation of this rule is straightforward - if an email is sent to any of the specified lists, then place these users (individual users specified) in the Bcc field.

Revision as of 22:53, 11 March 2021

This page attempts to discuss mail flow rules and their business impact e.g. their desired function and the rationale behind their implementation.

A mechanism to set up "rules" specifying actions when certain criteria are met (i.e. matching certain message properties) is central to most mail server systems. In MDaemon, this is known as the Content Filter. In Exchange, there is a Rules section within Mail flow.

Noteworthy Mail Rules

Substitute Reply-to header for document distribution emails

Implemented in: MDaemon

Document distribution emails describe emails such as remittance advices, A/R statements, invoices (PDF copy), purchase orders etc. These originate from JetForm (ultimately ASW), or custom mailer scripts on Bart, and are therefore sent using their assigned email accounts - unipharm@unipharm.com and uphadmin@unipharm.com. Recipients that reply by (naturally) hitting the reply button and accepting the suggested To address unknowingly send these emails back to these addresses, which are then forwarded to IT and require manual forwarding to get to their "true" intended recipient.

The MDaemon Content Filter rule (many rules, but based on the same template) that pertain to this policy works by looking for properties specific to these emails and then changing the Reply-To header. For example, in A/R statement emails, the subject always contains "AR STATEMENT" and contains a From: header with the value unipharm@unipharm.com. Replies to these emails should always go to accountsreceivable@unipharm.com, and so the rule specifies this as the Reply-To. The rule actually deletes this and 2 other headers as well, as these pertain to replies. For example, the Return-Path header is so that mail servers know where to send bounces in scenarios where the message cannot even be delivered to the intended recipient.

Note that the rules avoid changing the From: header. This should not be modified (i.e. it should remain as unipharm@unipharm.com or uphadmin@unipharm.com), because recipients may have email rules in place to detect this, or more importantly, machine recipients (servers that accept PO emails) may already be set to only accept messages from these addresses. The Reply-To header is more appropriate as it is only implicated when replying to the message.

Include staff in shareholder correspondence

Implemented in: Exchange

When emails are sent to shareholder distribution lists, it is currently a "business rule" to BCC select staff members, with the intent being so that staff remain informed of any mass correspondence in the case they receive calls and questions regarding said correspondence. Rather than implement this business rule by including staff members in the distribution lists themselves (which simply, is bad design), it is more apprporiate to institute a mail flow rule to achieve this same outcome. By doing this, you can also specify the senders to which this rule applies, because some senders that use distribution lists in a more conventional fashion may intend to send only to recipients suggested by the list name (i.e. sending to shareholders should only go to shareholders, because the name of the list is...Shareholders!).

The implementation of this rule is straightforward - if an email is sent to any of the specified lists, then place these users (individual users specified) in the Bcc field.

Exempt messages to email order catch-all addresses from most scanning

Implemented in: Exchange, MDaemon

There are still numerous shareholder stores (big ones at that) that use POS systems or versions of POS systems which transmit orders via email. These orders go to certain email addresses. Rules are set in both Exchange and MDaemon to relax/bypass the regular spam/threat scanning for messages intended for these addresses. The premise is that the priority of having these messages delivered trumps the low risk of impact from any email threats that are accepted. This is because the IBM i, where these messages eventually arrive, can't execute these threats anyway, and the i has demonstrated an admirably unwavering patience in dealing with unsolicited spam/bulk email.