Am Sonntag, den 10.09.2006, 13:12 +0200 schrieb Stefano Bagnara: > >> 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. > Ok. I will mark LocalDelivery as deprecated.
> >> 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. Agree. > > 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? I prefer the way like VUTs manage it. > > 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 +1 Thx for the explanation. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
