My Oracle Support Banner

$P causes problem with Milter callout. How to prevent this? (Doc ID 2733924.1)

Last updated on APRIL 22, 2021

Applies to:

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

Goal

On : Oracle Communications Messaging Server 8.1.0.6.20200729 version

We need to do an unusual recipient validation. We have our own groupmailer that runs on a pipe channel.

Group addresses are all groupname@group.example.com and there is no dc=group,dc=company,dc=com,o=internet, so those addresses are NOT normally recognized by the MTA rewrite rules.
Instead, the normal . rule sends them to our "core-routing MTAs", where there is a rewrite rule which sends it to the appropriate pipe channel, runs our groupmailer, etc.
But this has always left us with the problem of accepting messages for non-existent-group@group.example.com which gets routed to groupmailer, which generates an appropriate bounce. So it works, but...

Wouldn't it be nice if we could have the ingress MTA validate those addresses and reject anything that does not exist?

There are other reasons groupmailer might bounce messages. But at least we could avoid passing the invalid recipient messages all the way thru the system.
And yes, that's not hard. The $]...[ LDAP lookup in an ORIG_SEND_ACCESS mapping was simple enough to put together.
But...

What if the LDAP fails?
We occasionally have trouble with communication with the LDAP server.
We can't have that causing erroneous "550 5.1.1 unknown or illegal alias:..." rejections.
So we tried $.. and $P ... and the $P seems to be causing a problem with the milter callout to proofpoint.

The problem seems to be that the MTA does not send the recipient info to the milter when $P has indicated the message should go to reprocess.
That causes some "Illegal division by zero" errors in Proofpoint and eventually Proofpoint returns 't':



causing the MTA to respond to the end of the DATA phase with "451 4.3.2 Milter rejected message".

How can the message go to the reprocess channel and not cause this weird error on the milter server?

As a workaround, instead of using $P, we are just always (when LDAP has a problem) returning "$X4.0.0|$NTemporary$ lookup$ failure".
For the type of system we are working on at the moment, that is perfectly reasonable.
But for normal user-agent ingress systems, we will need to be able to send to reprocess instead. How to get around this issue?

Solution

To view full details, sign in with your My Oracle Support account.

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


In this Document
Goal
Solution
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.