Noel J. Bergman wrote:

OK. If I want to work around this it seems I have to build something
that sits in front of James to accept new messages, sort by domain
and slowly dispatch emails with similar domains



That would not be helpful. See http://wiki.apache.org/james/JamesV3/HighVolume for some discussion on changes related to remote delivery. Also, the mailing list manager will end up impacting remote delivery (probably with a specialized delivery agent) because of VERP, which also renders your problem moot.

--- Noel


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




I don't know much about this but here is an idea:

If the error message about too many recipients occurs in the SMTP-connection you should be able to code the RemoteDelivery to handle it, just keep halving the number of recipients to that domain and retry until it goes through. Worst case is n + log n connections.

This could alternately be achieved by a mailet in the error-processor, splitting the recipients list of a message with that error in half and putting two messages to remote delivery instead. Worst-case: 2n attempts.

This would at least get the messages through even if it takes extra time, and perhaps it might complicate some other things that are currently done to handle mailing-list messages.

You can store a known value per domain and use that value next time. If you can preconfigure, great, otherwise one of the above schemes should enable auto-configuration.

Personally, I would prefer RemoteDelivery to be as stupid as possible and leave all sorts of retry-decisions to a mailet-pipeline.

/tobe


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to