You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <nm...@byteaction.de> on 2006/09/04 19:19:45 UTC
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Ok if we "agree" to drop the current alias management and add commands
to remotemanager and JMX to do all the stuff via VirtualUserTable im
fine with it. But i never see that we agreed to deprecate or remove the
current alias management.
bye
Norman
Am Sonntag, den 03.09.2006, 16:06 -0700 schrieb Noel J. Bergman (JIRA):
> [ http://issues.apache.org/jira/browse/JAMES-562?page=comments#action_12432387 ]
>
> Noel J. Bergman commented on JAMES-562:
> ---------------------------------------
>
> What don't you like about the existing solution?
>
> We have a solution. Use a virtual user table, like pretty much every other mail server. You either have an account or you don't. Binary. If you do, we have the current scheme. If you don't, we have virtual user tables.
>
> My view is that the old Alias and Forward support should be removed, and replaced by a management interface for the virtual user table system. An point to remember is that we might want to perform the mapping after the pipeline, immediately before delivery, which is what the current scheme does.
>
> Also, keep in mind that we need to recognize whether a recpient is valid, which requires an account, an entry in a VUT, or a specific entry in config.xml.
>
> > Aliasmanagment should not depend on a user
> > ------------------------------------------
> >
> > Key: JAMES-562
> > URL: http://issues.apache.org/jira/browse/JAMES-562
> > Project: James
> > Issue Type: Improvement
> > Reporter: Norman Maurer
> > Assigned To: Norman Maurer
> >
> > If someone want to set a alias he must create a user fist and then use this user as alias. IMHO that makes no sense.. We don't need a password etc for an alias.. So we should change it to not need a created user first .
>
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Also, to speak directly to your concern, please consider that we already
> have JDBC and XML based VUT implementations. Doesn't it seem reasonable to
> unify the mapping code by writing a VUT that is populated from user
> repositories? For one thing, as I noted, the account-based alias/forwarding
> code happens only during local delivery, whereas virtual user table behavior
> can happen anywhere in the pipeline, from in-protocol to delivery.
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.
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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jira] Commented: (JAMES-562) Aliasmanagment should not depend on a user
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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
That is the same with a VUT. :-)
> 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.
I don't believe that the differences are intentional or significant.
> My best solution is to make it returns a collection of "destinations"
> including "errors", "forwards", "aliases".
Return to what?
> 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.
That would be equally so for a VUT. The point is that there are no
differences. We should merge the lot under a single virtual user table
interface, whatever changes we feel we should make to it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Posted by Stefano Bagnara <ap...@bago.org>.
>> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Posted by Norman Maurer <nm...@byteaction.de>.
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
RE: [jira] Commented: (JAMES-562) Aliasmanagment should not dependon a user
Posted by "Noel J. Bergman" <no...@devtech.com>.
Norman Maurer wrote:
> Stefano Bagnara:
> > Noel J. Bergman wrote:
> > > Also, to speak directly to your concern, please consider that we
already
> > > have JDBC and XML based VUT implementations. Doesn't it seem
reasonable to
> > > unify the mapping code by writing a VUT that is populated from user
> > > repositories? For one thing, as I noted, the account-based
alias/forwarding
> > > code happens only during local delivery, whereas virtual user table
behavior
> > > can happen anywhere in the pipeline, from in-protocol to delivery.
> > 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.
It isn't so bad as that. :-) But it should be for later. :-)
> > 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 ?
See below.
> > 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.
> IF we could manage this this whould be great.
We already have a common interface. The UsersRepositoryAliasingForwarding
code should be rewritten as a virtual user table, following the existing
interfaces.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Posted by Norman Maurer <nm...@byteaction.de>.
I just notice that i not answer to this post. So better late then never:
Am Dienstag, den 05.09.2006, 18:34 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> > Also, to speak directly to your concern, please consider that we already
> > have JDBC and XML based VUT implementations. Doesn't it seem reasonable to
> > unify the mapping code by writing a VUT that is populated from user
> > repositories? For one thing, as I noted, the account-based alias/forwarding
> > code happens only during local delivery, whereas virtual user table behavior
> > can happen anywhere in the pipeline, from in-protocol to delivery.
>
> 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.
>
> 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 ?
>
> 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.
bye
Norman
RE: [jira] Commented: (JAMES-562) Aliasmanagment should not depend on a user
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincenzo Gianferrari Pini wrote:
> Wait a moment, I may be the only one, but I'm using the "old Alias and
> Forward support" entirely for more than 60% of my end users, and the
> table entries are managed by an application that synchronizes every 10
> minutes our HR database and James database. So removing such support
> would immediately hurt my James production system.
Well, as you know, I'm not a fan of immediately removing anything, since
even if you weren't, I suspect that many if not most JAMES users who use
some forwarding use the current account-based approach. Furthermore, with
LDAP-based repositories, it is be quite natural to have a forwarding address
(see the InetOrgPerson schema) defined in the account.
But I certainly wouldn't invest in a THIRD approach to aliases! Please
notice that the issue "complains" that a user account is required for
aliasing. That's not so, and we should not develop yet another alternative.
My real point when talking about the old scheme is to emphasize that virtual
user tables should be the preferred approach for user mapping into which
education and effort is invested.
Also, to speak directly to your concern, please consider that we already
have JDBC and XML based VUT implementations. Doesn't it seem reasonable to
unify the mapping code by writing a VUT that is populated from user
repositories? For one thing, as I noted, the account-based alias/forwarding
code happens only during local delivery, whereas virtual user table behavior
can happen anywhere in the pipeline, from in-protocol to delivery.
> I know that if I had to build my synchronization application *now* I
> would use virtual user table, but it wasn't like that 3.5 years ago.
And I am sure that there are others in the same boat. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Wait a moment, I may be the only one, but I'm using the "old Alias and
Forward support" entirely for more than 60% of my end users, and the
table entries are managed by an application that synchronizes every 10
minutes our HR database and James database. So removing such support
would immediately hurt my James production system.
I know that if I had to build my synchronization application *now* I
would use virtual user table, but it wasn't like that 3.5 years ago.
So why remove the old support? let's just clearly deprecate it if we
really want to, but again why?
Vincenzo
Norman Maurer wrote:
>Ok if we "agree" to drop the current alias management and add commands
>to remotemanager and JMX to do all the stuff via VirtualUserTable im
>fine with it. But i never see that we agreed to deprecate or remove the
>current alias management.
>
>bye
>Norman
>
>Am Sonntag, den 03.09.2006, 16:06 -0700 schrieb Noel J. Bergman (JIRA):
>
>
>> [ http://issues.apache.org/jira/browse/JAMES-562?page=comments#action_12432387 ]
>>
>>Noel J. Bergman commented on JAMES-562:
>>---------------------------------------
>>
>>What don't you like about the existing solution?
>>
>>We have a solution. Use a virtual user table, like pretty much every other mail server. You either have an account or you don't. Binary. If you do, we have the current scheme. If you don't, we have virtual user tables.
>>
>>My view is that the old Alias and Forward support should be removed, and replaced by a management interface for the virtual user table system. An point to remember is that we might want to perform the mapping after the pipeline, immediately before delivery, which is what the current scheme does.
>>
>>Also, keep in mind that we need to recognize whether a recpient is valid, which requires an account, an entry in a VUT, or a specific entry in config.xml.
>>
>>
>>
>>>Aliasmanagment should not depend on a user
>>>------------------------------------------
>>>
>>> Key: JAMES-562
>>> URL: http://issues.apache.org/jira/browse/JAMES-562
>>> Project: James
>>> Issue Type: Improvement
>>> Reporter: Norman Maurer
>>> Assigned To: Norman Maurer
>>>
>>>If someone want to set a alias he must create a user fist and then use this user as alias. IMHO that makes no sense.. We don't need a password etc for an alias.. So we should change it to not need a created user first .
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-562) Aliasmanagment should not depend
on a user
Posted by Norman Maurer <nm...@byteaction.de>.
Well noel come up with that.. I just didn't like that i need to create
the user first to use it as alias. It make no sense to me ..
bye
Norman
Am Dienstag, den 05.09.2006, 09:41 +0200 schrieb Vincenzo Gianferrari
Pini:
> Wait a moment, I may be the only one, but I'm using the "old Alias and
> Forward support" entirely for more than 60% of my end users, and the
> table entries are managed by an application that synchronizes every 10
> minutes our HR database and James database. So removing such support
> would immediately hurt my James production system.
>
> I know that if I had to build my synchronization application *now* I
> would use virtual user table, but it wasn't like that 3.5 years ago.
>
> So why remove the old support? let's just clearly deprecate it if we
> really want to, but again why?
>
> Vincenzo
>
> Norman Maurer wrote:
>
> >Ok if we "agree" to drop the current alias management and add commands
> >to remotemanager and JMX to do all the stuff via VirtualUserTable im
> >fine with it. But i never see that we agreed to deprecate or remove the
> >current alias management.
> >
> >bye
> >Norman
> >
> >Am Sonntag, den 03.09.2006, 16:06 -0700 schrieb Noel J. Bergman (JIRA):
> >
> >
> >> [ http://issues.apache.org/jira/browse/JAMES-562?page=comments#action_12432387 ]
> >>
> >>Noel J. Bergman commented on JAMES-562:
> >>---------------------------------------
> >>
> >>What don't you like about the existing solution?
> >>
> >>We have a solution. Use a virtual user table, like pretty much every other mail server. You either have an account or you don't. Binary. If you do, we have the current scheme. If you don't, we have virtual user tables.
> >>
> >>My view is that the old Alias and Forward support should be removed, and replaced by a management interface for the virtual user table system. An point to remember is that we might want to perform the mapping after the pipeline, immediately before delivery, which is what the current scheme does.
> >>
> >>Also, keep in mind that we need to recognize whether a recpient is valid, which requires an account, an entry in a VUT, or a specific entry in config.xml.
> >>
> >>
> >>
> >>>Aliasmanagment should not depend on a user
> >>>------------------------------------------
> >>>
> >>> Key: JAMES-562
> >>> URL: http://issues.apache.org/jira/browse/JAMES-562
> >>> Project: James
> >>> Issue Type: Improvement
> >>> Reporter: Norman Maurer
> >>> Assigned To: Norman Maurer
> >>>
> >>>If someone want to set a alias he must create a user fist and then use this user as alias. IMHO that makes no sense.. We don't need a password etc for an alias.. So we should change it to not need a created user first .
> >>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,44fd2a4445111833019801!