[freeside] svc_acct_sm - Domain mail aliases

[ivan]

On Mon, Jul 17, 2000 at 04:09:36PM +0100, Shez wrote:
> On Mon, 17 Jul 2000, you wrote:
> >On Mon, Jul 17, 2000 at 03:42:22PM +0100, Shez wrote:
> >> Hi there,
> >> 	I am in the process of setting up freeside, (nice bit of software btw
> >> :), and want to be able use freeside to manage aliases of the form:
> >> aliasuser at aliasdomain.com -> realuser at realdain.com rather than just 
> >> aliasuser at aliasdomain.com -> domuid at localdomain.com 
> >> 
> >> Is there any reason I'm missing for restricting domuid in svc_acct_sm to a
> >> reference to an existing entry in sm_acct?
> >
> >A more flexible implementation isn't written yet.
> heh, fair enough :)
> 
> >>  It would appear more flexible to
> >> simply have domuid being say varchar(80) containing a fully qualified email
> >> address (e.g ``shez at nsl.net'')
> >
> >It's not that simple.  See
> >http://www.sisd.com/freeside/list-archive/msg01414.html
> The above appears to be about domains being an integral part of the svc_acct
> table so that user at domain is required to be unique, but not ``user''.  This
> isn't required for what I'm talking about.  

Possibly, but that's the framework I plan on using to support more
flexible virtual domain mappings, including yours.

> All I want to be able to do is forward to arbitary email address(es).  It would
> appear that this should be simple enough to implement for qmail at least.

Specifically, how do you plan on exporting your expanded data set to
qmail?

> If we're contributing patches would you prefer this done as a separate
> svc_{tablename} table and object, or as a modification to the existing
> sm_acct_sm?

I'm probably not interested in any patches are further hacks against the
current virtual domain functionality.  I'd expect that current users who
need to deploy something ASAP would be more interested in a modification
to svc_acct_sm. 

-- 
meow
_ivan