Re: prversion.c

[Eugene Crosser <crosser@online.ru>]

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

It is quite OK to pass the complete "something.local@some.domain"
address to the function.  BTW, it even might be useful to have
a way to tell if the address is local to this particular host from
the same function: another return code might be "UserNotLocal".
Or is it a crazy idea?  The function could be smart enough to
tell different things on different machines...  But you'd better
think about it yourself: we still have one mail server here, and
I simply do not realize all the problems arising in multimachine
environment.

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

Oh, I am afraid of LDAP...  There should be an easier way...
LDAP, again, could be one of possible backends, wrapped into a
function serving fqdnaliases-style requests.

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

Like the above, this thing could go *inside* the function that we are
discussing.  In simple case, the function will deal with UNIX standard
things (like getpwnam and .forward), in more complicated setups, the
sysadmin will build a function that will query LDAP server or propriatery
database or whatever.  No need to include this in standard Zmailer source.

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

Actually, I think that home is not needed at all as long as .forward
data is dealt within the function.  But maybe if you allow delivery
to the files in the format "~user/incoming.mail@domain"?

Sure, the function may return NULL or something if this field is not
relevant for a given user at a given host.

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

I dout that no. of messages is interesting: you do not want to count
existing messages in the mailbox before you append the newly arrived one,
it is too expensive.

> > - [anything else?]
>      Expiration timestamp ?  "Account has expired"...

That could be another return code.  But yes, it could be useful to have
a "non-delivery comment" field.  E.g, the return code could say "No
such user", and the comment could be either "No such user" ot "User
account discontinued", to put it into non-delivery report.

> > In the standard distribution, the said function could query realname
> > database, then issue getpwnam(), then check validity and try to read
> > ..forward.
    ^^
[unrelated: looks like something (smtpserver?) does not remove extra dot
when it should]

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

Sure.  And if we have more than one variable length field (such as a
non-delivery comment), we'll have to have more complicated structure.

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

Probably there should be separate "NoSuchUser" and
"UserCurrentlyUnreachable", to return the sender 5.x.x ot 4.x.x DSN
codes respectively.

--
Eugene, who is sorry for being exessively verbose today.