Re: prversion.c

[mea@nic.funet.fi]

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

	There are a bit problems at choosing what to feed to
	the interface routines.  If your login-ids at POP/IMAP
	are  "full.name@domain"  with separate entry telling
	which server to use, then you could perhaps get away
	with this idea of yours feeding   localpart + domain
	to the wrapper -- key being their catenate.

	On overall we have a generic problem in fully virtualized
	environment where the MTA uses user databases of which
	are not related to whatever people have real login rights
	at the system running the MTA.

	At Sonera Corporation [http://www.sonera.fi/english.html]
	we are moving towards virtualization model of:
		- users receive email as    something.local@some.domain
		- It is mapped to   somelogin@some.server.box  via
		  one mapping file  (fqdnaliases, of course) in front-
		  end systems (which were needed with sendmail, but
		  will likely be thrown away with ZMailer..)
		- At user's designated message store the ".forward"
		  data is consulted, and some possibly esoteric
		  operations are executed -- like conditional sending
		  of arrived email to persons GSM, or Pager along
		  with collecting billing data related to such an
		  operation.
		- Users are NOT told which server box their email
		  resides at.  They retrieve it as:
			somelogin @ mail.inet.fi
		  and pop3-proxy (no IMAP(4+) yet..) connects to
		  the real server.
		  Address  <somelogin@mail.inet.fi>  does NOT work.

	The problems:

	"something.local@some.domain"
		This is not quite easy to virtualize in all environments.
		(At least not in the one I have built here, which bases
		 on having login-ids's as the keys for lookup.)
		We use  fqdnaliases  for this mapping.

		Perhaps it could be LDAP lookup as well ?

	".forward"
		This IMO needs to be part of some database type.
		Again perhaps LDAP ?

> - userid (name)
> - userid (numeric)
> - groupid (numeric)
	Are these uid/gid truly needed ?
	Hmm... perhaps they are; at least to separate from 'trusted',
	and 'nobody' users.  All normal users have some third value
	there which does not match any of 'trusted', nor 'nobody'.
> - home directory (arguable)
	Perhaps, but also the server in which this id is
	valid -- see above about multiple message store servers.
> - contents of .forward file (not the pointer to the file, see below)
> - mailbox quota
	Multiple values ?  Total size in bytes, and max number of messages ?
> - [anything else?]
	Expiration timestamp ?  "Account has expired"...

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

	I think there can be multiple different 'aliases.cf' files for
	the router for this.

> 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];
		Nope, At least here the userids are way longer, like
		up to 40 chars or so.
> 	char lu_fwdinfo[1];
> } locauser_t;
> 
> int getlocaluser(char *localpart, char *domain, localuser_t *buf, int buflen);

	Why not... supplying the buffer where to store received data.
	Structure of the  localuser_t  can be altered to be more
	generic, though.

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

	I have to think it more.

> Eugene

	/Matti Aarnio <mea@nic.funet.fi>