[freeside] svc_acct_sm - Domain mail aliases

[Shez]

Hi there,
	It appears we've been talking at slight cross purposes....

>The presence of fields in the database schema does not necessarily imply
>*anything* about your local export.  Unused fields for accounts that
>aren't local isn't a problem of any sort.
I was of the belief if you have a table with ~(12 fields+ x radius fields) and
99% of the records in the said table only use 3 of those fields then you may
want to rethink your schema design.  I was speaking from a position of
ignorance for which I apologise.

>
>> >I'm attempting to design a schema which would be a superset of *all* of
>> >the ways ISPs maintain mailboxes and domains - forwarding virtual domains
>> >to a real system mailbox, like Freeside does currently (and was the only
>> >way to do when the software was originally written), sendmail /etc/aliases
>> >and qmail+fastforward (arbitrary remote addresses), or true virtual
>> >hosting ala qmail+vpopmail/vchkpw or sendmail with the funky domain names
>> >in the /etc/passwd file (as I've seen on a customer's Red Hat box
>> >recently).
>
>> Of course, but for this all you need is a (domuser,domain name) ->
>> (destination user,destination domainanme) mapping. Whether the destination
>> user is local or remote should surely be irrelevent?
>
>Yes.  Which is what I've been trying to tell you.  (destination user,
>destination domainname) would be represented by the svcnum of a record in
>svc_acct.  (In retrospect, using the uid instead of the svcnum was a bad
>choice).  (domuser, domain name) would be part of the svc_acct_sm record,
>as domuser and domsvc.
>
>Upon further consideration, I'll probably eliminate the svc_acct_sm table
>completely, and just add a field for the svcnum of a domain and the svcnum
>of a destination mailbox to svc_acct (or perhaps a one-to-many
>relationship - multiple svcnum(s) for multiple destination mailboxes. 
>hmm.) 
One to many would be useful.  

<snip>
>Freeside doesn't get involved in user mail forwarding, either with
>.forward files or .qmail files, other than touching
>/home/user/.qmail-domain:tld-default when necessary. 
This is where I was misunderstanding - I wanted to put user mail forwarding
info into freeside, to support setups where the user doesn't have shell access.
If you don't feel this should be part of the freeside core then thats fair
enough, I will implement it separatly.

>If it's not in the CVS tree then it's not "in the pipeline".  Patches
>speak louder than intention and uninformed criticism.
I read somewhere that you prefered people to ask on the list before starting
work on things.   I'm not intending to be critical and shall try and phrase my
email better in the future.  

>> Anyway for now my intuition tells me I should read some more of 
>> the docs & source ;) 
>> On this, we agree.

Oh well  one point is better than none :) 

Seeya
Shez