This content has been marked as final. Show 3 replies
you should not be using the expandlimit channel keyword to trying to accomplish deferred processing.
In normal circumstances this deferred processing of groups should be done automatically. It can be controlled with the ldap attribute mailDeferProcessing, or with overwriting the defaul of DEFER_GROUP_PROCESSING in the option.dat file .
See more on this here :
SMTP Timeout Errors Sending to a Large Mailing List / Group (Doc ID [1334609.1|https://support.oracle.com/rs?type=doc&id=1334609.1] )
I think one point of clarification might help a little. When you say "large email lists" we are all thinking of a list defined in LDAP. So the client does "RCPT TO: list@yourdomain" and yes, that is the sort of work you might want to defer to the reprocess channel, but the MTA does that automatically by default - depending on the mailDeferProcessing attribute on the LDAP group object and/or the DEFER_GROUP_PROCESSING option.
But I think you are talking about a case where a mail client has a locally defined list, so it is submitting a single message with many envelope recipients ("RCPT TO"). And after a certain number of RCPT TO, you want the MTA to accept the rest of them and defer processing of the entire message.
How many recipients are we talking about?
How long does it take to process them and accept the message if you don't have expandlimit on the tcp_local channel?
Is there any problem other than how long it takes?
I just noticed we never closed this out. The final answer is that there is nothing to be gained by trying to defer processing of individual recipients on a single message after a certain number. It must still do the work of verifying the recipients are valid. So deferring the after that gains nothing. And if you could prevent it from verifying them, you could be accepting invalid recipients and then own having to return those copies of the message.
Also, there was no real problem with the performance. The idea was to try to be proactive to prevent one, but it is a problem that does not exist.
And the "unknown host or domain" about addresses @ims-ms-daemon was because of a problem with reprocess and this mapping entry:
The reprocess channel is running the mapping table as if it was the original submitting channel, which is what it usually should do. But in this case it is not correct.
ORIG_SEND_ACCESS: tcp_*|*|ims-ms|* $N
But the best answer is still to not do that. There is nothing to be gained by trying to defer individual recipients after a certain number.
Edited by: kellyc on May 10, 2013 8:29 AM