[freeside-devel] svc_forward must die

[ivan]

On Thu, May 30, 2002 at 05:05:00PM -0700, Kristian Hoffmann wrote:
> Okay, maybe not, but I don't get it.  You have to create a svc_acct for a
> mailbox that will never have anything delivered to it?

Absolutely, yes.  No doubt the webinterface/UI to this could be better and
should work more intuitively, but that's what should happen "underneath". 

> This creates a problem for services that use svc_acct for authentication
> (which could include RADIUS, POP, IMAP, FTP, etc.).

What problem does it create?  You shouldn't be exporting mailbox-only
records to those services.

>  They have to check
> svc_acct to make sure the account is valid, and then check svc_forward to
> verify that it's really an account and not just a pseudo-account that
> exists to make mail forwarding work.

You've got things backwards.  Services should not be querying svc_acct and
svc_forward.  Services should check their own data, exported from a
_subset_ of the svc_* tables. 

Every svc_acct record isn't exported to every service.  Having an svc_acct
record as a "pseudo-account", as you say, for export to a mail system
should cause no conflict with an export somewhere else.

All that said, one vestige from the "old" way of doing things that hasn't
been fixed yet is the duplicate username/domain check in svc_acct.pm - it
needs to check for duplicate username/domain with conflicting exports, not
just duplicates.

> Contrast that to svc_acct_sm, which works more or less like /etc/aliases:

Yes, this is one of the reasons why svc_acct_sm was broken.  Not all mail
exports can be encapsulated by an /etc/aliases-like schema.

> the destination of the forward has to be a real account, but the source
> probably isn't.

The fact that the source is "not a real account" is a quirk of the
provisioning, not something that should be reflected in the database
schema.  It's certainly enough of a "real account" that it conflicts with
a regular mailbox with that username/domain.

Most non-sendmail mail systems seem to agree, having "forwarding" as a
property of the mailbox, not something separate.  And while some kinds of
provisioning couldn't be done with svc_acct_sm, /etc/aliases-like
provisioning _can_ be done with svc_forward, you just have to put a little
extra intelligence in the export.

-- 
_ivan