On Sun, Dec 14, 2008 at 2:18 PM, Stefano Bagnara <[email protected]> wrote: > Robert Burrell Donkin ha scritto: >> On Sun, Dec 14, 2008 at 1:55 PM, Norman Maurer <[email protected]> wrote: >>> Ah ok now I see what makes you wonder... thats right. isLocalEmail >>> works only after the vut mappings was done. Thats prolly a problem in >>> some cases.. >> >> it's the problem in my case :-) >> >> (the code's very messy since it's trying to ensure backwards compatibility.) > > Sorry but I don't agree on this one.
the user code is very messy - lots of casts everywhere, lots of proxy layers, no way to implement a clean API, too many user POJOs, too many deprecated methods. the VUT stuff is annoying since it's tacked on to this mess. > The way VUT works is by design. We added some support for easy virtual > hosting leaving there the backward compatibility, but the underlying > system is not aware of the VUT so you have to run the VUT in the mailet > chain before any check for "isLocalEmail" is done. AFACT VUT is resolved in LocalDelivery but LocalDelivery is - in the default configuration - only called after an isLocalEmail match > This applies to every "redirecting" mailet, such as Redirect/Forward and > not only to the VirtualUserTable stuff. AIUI these features are not part of LocalDelivery whereas VUT is > There is not a API to know what the final recipient will be given an > input email and IMHO there should not be a similar API, because I could > have some mailet with my own rules accepting some address now and some > other address later and redirecting them to some address now and some > other address later. > > I and Norman simply extracted the VUT to a service so to be able to use > the same data both from a mailet and from the in protocol smtp filters, > but this is only for advanced tuning and there is no out of the box > solution at all, IMHO. IMHO if LocalDelivery supports VUT then it should be a core feature and supported out of the box. if not then create a VUT mailet which using the service. > If you have a proposal try to describe it and I'll try to show you the > issues I see with the proposal ;-) reduce the complexity: come up with a new clean consolidated user API without the need for casts etc - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
