Looking For "redirect" Recommendations and Options In Messaging Server Scenario (Doc ID 2281021.1)

Last updated on JUNE 29, 2017

Applies to:

Oracle Communications Messaging Server - Version 8.0.1 and later
Information in this document applies to any platform.

Goal

At any given time, we may have a few hundred "redirect" rules in place on our BrightMail servers. We want to move that function to the Oracle MTA.

A "redirect" is when an executive admin requests we have all messages sent from some list of sender addresses (sometimes only one), addressed to a specific exec, instead delivered to the exec's admin or some one else for filtering.

A recent request asked for the sender list to include a regex specification for sender info (eg, "There's an external-to-company person with a grudge. We'll call him creepyguy. He has creepyguyXX@ hotmail, AOL, yahoo, and gmail. He also owns creepyguy domains in several TLDs. In BrightMail, that's an easy, if slightly expensive, regex").  There may be some redirects in place which specify multiple intended recipients (ie, if creepyguy is sending to any of a list of execs, instead deliver those to a specific admin).

Note that this is not for "legal intercept", but autoreply should not engage anyway.

Since FORWARD mapping or sieve redirect will only change the envelope recipient, any autoreply or sieve vacation, on the person to whom the message is redirected, should not engage because it will fail the test for whether the actual recipient is specifically identified in the recipient headers. Is that correct?

A first thought was to use the FORWARD mapping table, with an LDAP callout. We could create a new subtree in LDAP containing a new type of object with attributes for sender, intended-recipient, and redirect-to. That would be an additional LDAP search for every recipient of every message, but the index should be tiny compared to production ou=people.

An LDAP solution has the advantage that it is set once and applied instantly across all the systems where we want this to happen. But it won't handle anything like the regex requirement.

Using general.txt is probably faster and much less impact on LDAP, but no better at the regex requirement. And, it requires updating all the systems, though that may not be unacceptable with automation.

Putting them all directly in the FORWARD mapping table gives pattern matching capability. But starting off with a few hundred?

MTA-wide or per-channel sieve?
mailDomainSieveRuleSource?

Or... a "redirect" sieve action in an MTA-wide, per-channel, or mailDomainSieveRuleSource.

Doing it with mailDomainSieveRuleSource would have the advantage that it would only need to be applied once and instantly (mod caching) apply to all systems.
But we don't want it to apply to "all" systems. We want it done on what we consider the "core routing" MTAs, not necessarily the ingress points.

Using sieve would provide regex capability when necessary.
The script could be organized by the redirect destination, which is probably a much smaller list then all sender addresses. That would allow us to reduce something we might initially be tempted to code as:


 
However, the idea of a long list of if ... { redirect ...} elsif ... { redirect ... } elsif ... ... does not seem like a good plan.


What we think we need is a list of patterns (FORWARD mapping table?) but hundreds of entries in the FORWARD mapping table does not seem like a good plan either.

Personal sieve rules is another alternative. That would have the least impact on anything else. Only the processing of a very small number of users (out of the entire user-base) would have any impact.

That would end up being done at final delivery rather than "core routing MTAs".

 

Of course if "core routing MTAs" were using LMTP, that would be the same place. But switching to LMTP is a much larger project. We're not sure we see sufficient benefit to justify doing that.

The biggest problem with personal sieve rules would be managing the interaction of other sources of such rules.

We have a personal whitelist/blacklist feature implemented. It has only ever been used for one specific user.
This user has a personal sieve filter which uses extlists to do LDAP lookups to yet another separate LDAP substree.

The reasons for not pursuing expanding the use of personal whitelists/blacklists is that this has always been done in a central fashion and LDAP being a the core of whitelist / blacklist implementation means that it fails the regex requirement.
 

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms