Last updated on JULY 20, 2017
Applies to:Oracle Communications Messaging Server - Version 8.0.0 and later
Information in this document applies to any platform.
We are starting to use ldap_capture as part of an upgrade. It is the understanding that Ldap_capture engages any time the sender or recipient matches a user who has it set.
We have a path where mail will loop through the system twice.
Eventually, the reason for that loop will be replaced with milter callout, but that planned for another time.
We want to be able to enable or disable ldap_capture on a per-channel basis so it happens when one of those passes through this system, but not the other.
Doc ID 1470146.1 says,
"Note that with any of the techniques discussed above, issues of ... elimination of duplicate copies of the same message captured at different stages of processing) may arise; it is the responsibility of sites to devise strategies appropriate for their goals."
Preventing the duplicate in the first place would be best. Can this be done with ldap_capture? Or is a sieve method needed instead? Or, any suggestions on how to eliminate duplicates after the fact?
We have the normal recipient validation and expansion basically at every hop: at the ingress points, on the core routing MTAs, and on the backends (and some looping in between).
We were planning to do capture on the core routing MTAs.
When we say looping through the MTA, we are referring to, for example:
Client -> MSA -> Relay -> MTA -> (group expansion) -> MTA -> relay -> MTA -> Backend
For the case where groups are not involved, it is simpler:
Client -> MSA -> Relay -> MTA -> Backend
MSA is Oracle Messaging Server. We call those systems "MMP". They run both the MMP and the MTA component. The normal $* rule happens there. But we have daemon on the appropriate channels to force mail to go to "Relay" instead of directly where it should go.
"Relay" is Symantec Brightmail. It currently does capture, redirect, and some other content based filtering as well as anti-virus.
MTA is the "core routing" MTA we are talking about upgrading. Above is the simplified picture we are working toward. Current reality is worse.
We are totally open to suggestions about how this should be done better than this.
And rather than having to use enqueueremoveroute or dequeueremoveroute to get rid of the source-route for next-hops that can't ignore it, should we be making more use of aliasdetourhost when we need to force a next hop?
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