[freeside] svc_acct_sm - Domain mail aliases

[Shez]

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


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

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

>
>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.  A decision which is qmail's not freeside's.  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.

These locals and virtualdomains files would of course be built from sm_acct_sm,
but could certainly be done without reference to the ``destination'' address.

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

>
>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 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.... Anyway for now my intuition tells me I should read some more of
the docs & source ;)

Take care
Shez