[freeside] svc_acct_sm - Domain mail aliases

Shez shez at nsl.net
Tue Jul 18 03:33:50 PDT 2000


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?

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.


>> >> 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.

Seeya
Shez



More information about the freeside-users mailing list