[freeside] svc_acct_sm - Domain mail aliases

[ivan]

On Tue, Jul 18, 2000 at 10:40:02AM +0100, Shez wrote:
> On Mon, 17 Jul 2000, you wrote:
> >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. 
>
> Yeah, it just seems slightly unnatural to have entries in svc_acct for remote
> addresses - if sm_acct_sm is purely for virtual email aliases then there
> doesn't seem to be much milage in distingishing between local and remote
> addresses.   Surely svc_acct should only contain local accounts of one sort
> another?

Why?
 
> Apologies if I've misunderstood.
> 
> >
> >> >> 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.
> I shall see about modifying sm_acct_sm, and providing such an export script. 
> Unfortuantly we it will be qmail only as I don't grok sendmail.

qmail+fastforward, specifically.  Stock qmail has a strong notion of
"local" addresses.  Another qmail addon package you may want to look at is
vpopmail/vchkpw <http://www.inter7.com/vchkpw/>

> >> >> 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.
>
> Okay, but it does seem odd to have arbitary username domain pairs in the
> svc_acct table.

Why?

-- 
meow
_ivan