2011/1/7 Norman Maurer <nor...@apache.org>: > Hi there, > > I spend the last weeks to think about RemoteDelivery and how it is > implemented. I think putting the remote deliver code in a Mailet is > not a good idea. It does not give us much control about it and makes > it harder to customize or extend. I think it would make more sense to > make the delivery code a "core service" which should allow some kind > of pluggable policy out-of-the-box. The Mailet should just move the > mail to the right queue then which the mail will get pulled of from > the new "core service" and tried to get delivered. > > Beside of that I think we should add some kind of policy support which > allow to register policies/listener which customize the following > things: > > * Calculate the next delay > * Force an other ip address as source for the next delivery attemp > * Force an other ip address as destionation for the next delivery attemp > > After that is done I think it would be very easy to add JMX metrics to > the service as well... > > WDYT ?
Do you think of simply using a ToRepository or something more specific? The main issue with using a simple ToRepository is that currently RemoteDelivery had some "logic" before writing to the outgoing spool. In fact depending on the presence of a gateway conf or not it will split the message for each recipient (or recipient group) depending on the final domain. If we instead use a simple ToRepository then we'll have to do one more processing in order to split the message in a following step. So, i think we should still have a ToRemoteDelivery mailet or something similar. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
