[freeside] svc_acct_sm - Domain mail aliases

[ivan]

On Tue, Jul 18, 2000 at 11:59:44AM +0100, Shez wrote:
> On Tue, 18 Jul 2000, you wrote:
> >> 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 distinguishing between local and remote
> >> addresses.   Surely svc_acct should only contain local accounts of one sort
> >> another?
> >
> >Why?
> 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'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).

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

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

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.

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

> Then you would have:
> svc_acct_sm - Domain mail aliases 
>          svcnum - primary key 
>          domsvc - Domain (by svcnum) 
>          domuid - Account (by uid) 
>          domuser - domuser @ Domain forwards to destination
>          destination - address to forward mail for domuser at domain to
> 
> 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)? 

You should check out the *current* virtual domain handling for stock
qmail, especially in the import and export scripts.

(Incidentally, the current qmail support does need some small changes for
the elimination of the recipientmap file in qmail 1.01->1.02) 

> to setup the forwarding.
> I didn't want to think about doing this though as I have no idea how it would
> interact with the sendmail code.
> 
> >Another qmail addon package you may want to look at is
> >vpopmail/vchkpw <http://www.inter7.com/vchkpw/>
> Cheers for this, our existing systems were setup before this package was
> available and as yet we've not had time time migrate.  Of course having all the
> appropriate data in Freeside makes this a whole lot easier :)
> 
> >> Okay, but it does seem odd to have arbitrary username domain pairs in the
> >> svc_acct table.
> >
> >Why?
>
> If there are other uses for having remote addresses in this table then fair
> enough.

None I can think of.

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

-- 
meow
_ivan