[freeside] svc_acct_sm - Domain mail aliases

ivan ivan at 420.am
Mon Jul 17 11:21:09 PDT 2000


On Mon, Jul 17, 2000 at 05:46:45PM +0100, Shez wrote:
> On Mon, 17 Jul 2000, you wrote:
> >On Mon, Jul 17, 2000 at 04:09:36PM +0100, Shez wrote:
> >> 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.
> 
> The problem is that unless I'm mistaken you would still need an entry in
> svc_acct before you could forward to an address(*) - I want to be able to
> forward mail to arbitary, remote or local, addresses.

Well (and I'm talking from the POV of the new framework, not the current
code) you would need an entry in svc_acct for every target of a mail
alias; but you could forward to arbitrary local or remote addresses.  The
only distinction betwen "remote"  and "local" addresses would be that
"local" addresses mapped to accounts on your machine(s), and "remote" 
addresses wouldn't. 

> >> 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?
> There is a qmail related package ``fastforward'', from man setforward (which
> reads from stdin):
> 
> INSTRUCTION FORMAT
>        A forwarding instruction contains a  target,  a  colon,  a
>        series  of  commands,  and a semicolon.  Each command is a
>        recipient address, owner address, external  mailing  list,
>        or program.  Commands are separated by commas.
>  
>        For example,
>  
>           root at yp.to: god at heaven.af.mil, staff at af.mil;
>  
>        says  that  mail for root at yp.to should be forwarded to the
>        recipient addresses god at heaven.af.mil and staff at af.mil.
>  
> Given this all I need to do is have db tables that map target -> destination(s)
> and have a simple export script.  Does this make sense?

Sure.

> >> 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. 
> 
> Okay, am I correct in my interpretation (*) above?  

Well, you're correct that you would need an entry in svc_acct, but
incorrect that this necessarily limits you to "local" addresses.

-- 
meow
_ivan



More information about the freeside-users mailing list