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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> !EXCUBATOR:1,44fd2a4445111833019801!

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply via email to