How to Make a Permanent 5yz Error Return a Temporary 4yz Error Instead
(Doc ID 1955418.1)
Last updated on MAY 25, 2021
Applies to:
Oracle Communications Messaging Server - Version 7.0.4 and laterInformation in this document applies to any platform.
Goal
How can we make a relaying MTA (not an MTA directly receiving the submission from a client) return a temporary (4yz) failure instead a permanent (5yz) failure?
This being a relaying MTA means that the sending MTA has received the original submission from the actual client.
That means a temporary error will leave the sending MTA with the responsibility to retry the message, whereas if it was a client submitting the message, a temporary error would be essentially no different from a permanent error -- the client is still generally not prepared to retry later.
In this case, the client is an admin/provisioning system sending a welcome message at exactly the same time as creating the object in LDAP.
The application submitted that message to some other MTA (call it MTA#1).
The Messaging Server MTA (MTA#2) is receiving the relay of that message from MTA#1.
Due to LDAP replication performance issues, the first lookup of the recipient done by MTA#2 may find no matching results, because the replica LDAP server it is using has not yet received the object.
If MTA#2 could return a temporary error instead of a permanent error, then MTA#1 would retry the message instead of bouncing it.
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 |
New Enhancement |
As a workaround, pre-try and accept or override error |
Be more specific |
Example SMTP session |
Draw backs |
Tuning |
References |