[freeside] svc_acct_sm - Domain mail aliases

[ivan]

On Tue, Jul 18, 2000 at 01:21:00PM +0100, Shez wrote:
> On Tue, 18 Jul 2000, you wrote:
> >> Because I'm not sure in what situation storing non local addresses in
> >> svc_acct would be useful apart from mail forwarding.
> >
> >A single use for a subset of data is not an excuse for a poorly-designed
> >database schema.
> I agree, my database design is poor at the best of times, so please excuse my
> ignorance :(  
> 
> It still seems that storing a remote email address in a table with fields like
> quota, slipip, gecos information etc. is wrong.  In setups where most mail is
> forwarded actual local accounts would quickly become a minority in svc_acct. 

So?

> Maybe you would want a separate user table that svc_acct and svc_acct_sm link
> to. Then remote addresses (domuser,domain) can be stored without having the
> implication that they have known quota's etc.

No.  Again, this increases complexity for no reason.

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

> >>  And for mail forwarding it
> >> seems unnecessarily complex compared with storing a fully qualified email
> >> address. If there are such use
> >
> >The schema I outlined in my earlier message would support all of these
> >types of exports, including yours.  Adding an additional field and special
> >behavior for that field would increase complexity, not decrease it. 
> Fair enough.
> 
> >
> >> >> 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.  
> >> True, it does.  However it will happily forward to <arbitrary at email-address> and
> >> work out for it self whether this is a local or remote address.
> >> This is part
> >> of qmail's job and something that the higher level applications should be able
> >> to generally ignore.
> >
> >That's irrelevant to the assertation that your particular schema changes
> >and export are for qmail+fastforward, not stock qmail.
> 
> My point was, that in general, whether the destination address is local or
> remote should be irrelevent to freeside.

In the database schema, yes.

For most kinds of exports, some subsection of svc_acct (by domain) would
be treated as local.

> I thought that the mail subsystem
> should take care of deciding that.  Qmail _however_ it is setup allows
> forwarding to arbitary email addresses - man qmail-local confirms this.
> 
> Just to be clear by ``destination address'' I mean ``shez at nsl.net'' where mail
> originaly to numpty at nsl.net is forwarded to shez at nsl.net.

I don't understand the relevancy of the above.  I suspect it isn't.

> >It's also untrue;  qmail's virtualdomain file causes it to *explicitly*
> >treats addresses as local even when they are not.  qmail-send(8) says: 
> >
> >  When qmail-send sees the recipient address user at domain, it converts it to
> >  prepend-user at domain and treats it as local.
>
> This (along with control/locals) is how qmail decides whether an address is
> local or remote.

I know how qmail works, thank you very much.

> A decision which is qmail's not freeside's.

What is this supposed to mean?

>  If you put a
> single line containing ``test at domain.com'' in a ~user/.qmail file then mail to
> that user will be forwarded to test at domain.com.

> Qmail will decide given its
> virtualdomains and locals files whether or not it is local.

No, qmail will decide the account is local and perform local delivery.
The fact that we know that the "local delivery" is a forward to another
address is not relevant.
 
> These locals and virtualdomains files would of course be built from sm_acct_sm,

Freeside exports `virtualdomains' configuration files currently, but I see
no reason why the software would export `locals' files. 

> but could certainly be done without reference to the ``destination'' address.

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. 

> >> If your not using qmail+fastforward then using the domuid
> >> as the user who ``control's'' a particular domain would work in stock qmail.
> >
> >Which would require different database schemas for different sorts of
> >exports - a totally unacceptable situation.
> I agree completly, I was merely thinking aloud :(
> 
> >> And you would create a qmail virtualdomains file with a 
> >> ``domain:account''
> >> line for each distinct (domain,account) pair.
> >> and do an ``echo destination > ~domuid/.qmail-domuser''
> >
> >That won't work.  Rhetorical question: What happends when more than one
> >domain is forwarded to the same local user (same domuid)? 
> Okay, I was simplifying.  The way you'd do this is of course to do something
> like 
> ``domain:acount-:domain:-$domainname'' and create
> ~domuid/.qmail-:domain:-$domainname to control the mail.

Still incorrect, but closer.

> >You should check out the *current* virtual domain handling for stock
> >qmail, especially in the import and export scripts.
> Am doing now, apologies for not studying them more indepth originaly.
> 
> >(Incidentally, the current qmail support does need some small changes for
> >the elimination of the recipientmap file in qmail 1.01->1.02) 
> 1.0.3 is current for qmail, if you don't already have it in the pipeline I
> shall look at doing the necessary changes.

If it's not in the CVS tree then it's not "in the pipeline".  Patches
speak louder than intention and uninformed criticism.

> >>  If not then why not allow forwarding to arbitrary addresses in the
> >> intuitive way?
> >
> >Because the "intuitive way" (well, maybe your intuition - mine tells me
> >otherwise ;) is bad database design, and isn't flexible enough. 
> 
> Bad database design I'll take your word for, flexibility would appear to be
> equivilent....

No.

> Anyway for now my intuition tells me I should read some more of
> the docs & source ;)

On this, we agree.

-- 
meow
_ivan