Re: prversion.c

[Eugene Crosser <crosser@online.ru>]

> > The other thing is that I want to move to a now-standard mailbox quota
> > feature from the hack that is working now.
> 
>      Me too, in my own way.   But we need ability to pull '.forward'
>      from the background databases as well (in the router).
> 
>      Care to suggest a function call returning something ?

Not that I really understand what do you mean :)  but yes I have an
idea of making a kind of a wrapper around getpwnam(), that could accept
the complete local address (baybe split to local part and domain) and
return:

- userid (name)
- userid (numeric)
- groupid (numeric)
- home directory (arguable)
- contents of .forward file (not the pointer to the file, see below)
- mailbox quota
- [anything else?]

In the standard distribution, the said function could query realname
database, then issue getpwnam(), then check validity and try to read
..forward.

In custom installations, the function could query the client database
and retreive all this information from there.  It is important that
the customer may not have home directory (and consequently .forward
file) but he may have an interface (e.g. via WWW) to configure
forwarding information in the customer database.  This function may
also have mechanism to resolve realname to userid, and be aware of
local virtual domains.

e.g.

typedef struct _localuser {
	uid_t lu_uid;
	gid_t lu_gid;
	off_t lu_quota;
	char lu_user[9];
	char lu_fwdinfo[1];
} locauser_t;

int getlocaluser(char *localpart, char *domain, localuser_t *buf, int buflen);

The return codes might be: OK, NoSuchUser, RetriableDBError, FatalDBError.

It is important to use this function in every place where local users are
dealt with: namely in the router in in the mailbox transport.

Eugene