>> I already splitted LocalDelivery into UsersRepositoryAliasingForwarding >> and ToMultiRepository. The first one is the one that is needed to >> support the aliasing/forwarding. We may remove LocalDelivery from our >> config.xml and insert the 2 mailets as separate instances so that it >> will be much more clear what happens and when. > > +1 > Im not sure if we should do this in 2.3 or in later versions. IF we want > todo it not now we should mark LocalDelivery as @deprecated before > release 2.3 final.
Imho we should change as little as possible in 2.3 so we can start working on 2.4. So let's fix JAMES-609 and let's hope no other showstopper will show up by the end of the month so we can release the final. >> This may mean that also UsersRepositoryAliasingForwarding is movable >> around like the VUTs and that we could write a fastfail for it like for >> VUTs. > > I don't understand this. Can you explain ? UsersRepositoryAliasingForwarding (URAF) take each recipient of the mail and for each send the mail to one or more of this: - error : if it find any problem in the aliasing/forwarding - remoteRecipient: if a forwarding has been specified - localRecipient: if an alias has been specified If you think more at this you will find that this is the same thing that we do in AbstractVirtualUserTable. This mean that both VUTs and URAF can be classified as "recipients mappers". This mean that you could decide to put the URAF at the start of the spool instead of using it just before the localdelivery (or better the ToMultiRepository). >> I always thought that all of this stuff should be accessed via a common >> interface so we may create services and have generic >> mailets/matchers/fastfailfilters to access them. >> >> Stefano > IF we could manage this this whould be great. An interface that take a recipient in input and return an error or a collection of recipients would be enough to merge a lot of common code. I think that there is a difference that we should analyze: In URAF you can put a local address both in alias and in forward: the result is different because the aliasing is done on the current mail that will move forward in the processor while the forwarding creates a new mail that will enter the spool from the root. VUTs do not allow this distinction because local addresses are considered aliases while remote addresses are sent to the root processor in a new mail. What do you think? My best solution is to make it returns a collection of "destinations" including "errors", "forwards", "aliases". Having this association between an input recipient and its "expansion" will allow us (later) to manage DSN correctly. In fact we may need to track the original recipient and its rewrites to be able to create a compliant DSN. This may be a first step in the right direction. And this is a small thing just to get our feet wet. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
