Information Systems:Mail flow

This page discusses the flow of email (mail flow), including Exchange connectors, MDaemon smart host configuration, and mail rules.

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.

Connectors

Understanding connectors is crucial to understanding the overall mail flow.

A connector in Exchange is defined when special is routing is needed between Exchange and another mail server. It is required for our environment because email hosting for the domains unipharm.com and medicinecentre.com is split between Exchange and MDaemon i.e. there are mailboxes for both domains on Exchange and MDaemon. It is worthwhile to first state that all inbound mail goes through Exchange (MX records point to EOP). For addresses that correlate to Exchange mailboxes, the routing of inbound mail is straightforward. When Exchange receives an email that is destined for an MDaemon mailbox, it sends it to MDaemon through a connector, which must be properly configured. Although the name may suggest it, a connector isn't a stateful connection between 2 servers. It's more just a route.

A connector can be from Exchange to another mail server or vice versa. This is called Send and Receive connectors in on-prem Exchange, but these labels are not applicable to connectors in Exchange Online. There are 2 connectors defined in our configuration, one for each direction:

• MDaemon to Exchange by Hostname - This connector accepts mail from MDaemon and is needed for email from MDaemon mailboxes to Exchange mailboxes. For example, when a shareholder (one that uses a unipharm.com email) sends to a staff member, the message goes through this connector.
• Exchange to MDaemon - This connector sends mail destined for MDaemon mailboxes to MDaemon.

Now for the fun part. The latter connector (Exchange to MDaemon) is rule-based. TBC...

Mail Rules

This section discusses mail rules (server-side rules) and their business impact e.g. their desired function and the rationale behind their implementation.

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.

Proof of the rule taking effect:

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.