Moving this to the dbmail-dev list. Summary: DBMail has no way of recording basic user information; Loss of GECOS information moving from system users to virtual users; Tying to external databases.
On Fri, 14 May 2004 13:11:23 -0400 Will Berry <[EMAIL PROTECTED]> wrote: > Feargal Reilly wrote: > > >I had a look last night and could not find a formal definition of it. > >Common usage however indicated that most flavours of unix treat it > >the same. It is a comma seperated list which takes the following > >order: Full name, Office Location/Room Number, Office/Work Phone > >Number, Home Phone Number, Other/Miscellaneous. > > > >Many applications look up the first field to insert a user's name. > >Some, such as finger, chfn, and adduser uses the other information > >too. I checked this on FreeBSD, Debian, Red Hat, and Solaris. > >Apparently Solaris they only used two labels - Full Name and other. > > > > > > This tells me that the field is basically a hack, and doomed to be > non-standard and non-portable until approximately 3 years after it > appears in an RFC. Maybe if there was a way to define the format in > dbmail.conf it would be portable enough. The format is the same on all systems: a comma separated list of values. On most systems this take the form "Full name, physical location, work number, phone number, miscellaneous". On Solaris it takes the form "Full name, miscellaneous"; miscellaneous can of course include commas so the same field works on both systems: Feargal Reilly, Dublin office, +353.12345678, +353.19012345, whinger Various tools and libraries such as postfix and sendmail use it to look up the user's name, by reading everything up to the first comma or end of field. There is absolutely no need to define the field in dbmail.conf as practical usage would be something like: dbmailadm ... --gecos='Feargal Reilly, who cares, no one every rings\ anyway' or perhaps for friendliness: dbmailadm ... --name='Feargal Reilly' --info='well, he never called me,\ when he said he would' > >I agree on you with using the client_idnr for tying to other > >databases; the GECOS field is not intended for that. I suggest it as > >it satisfies the needs of many people who do not need to develop a > >full blown user management database. > > > > > > Another issue with having a gecos field in the DBMail user table that > DBMail itself does not use is wasted space. A comma-separated list of > text data would probably be best implemented as a varchar(255) field, > or even a tinyblob (that's max 8K, right?). As you scale up, that > could be a lot of space, and for an awful lot of people this space > would be unused. As Peter Darley pointed out, if this is null this should cost one byte per row. /etc/passwd would be wasting a whole byte with the extra ':' field seperator. So that's actually a *saving* of seven bits... :) The Important Bit: DBMail currently has absolutely no mechanism to record the name of a user. While the ISPs among us will have various client management/billing databases, this, along with things like LDAP support etc. is overkill for many people who just want to let people receive email. Who is '[EMAIL PROTECTED]'? Unless someone made a note in a spreadsheet somewhere, or knows the person, you can't exactly find out. You could send him (her? Who knows?) an email and ask. Not exactly ideal though if the reason you want to know is because they've suddenly stopped collecting their mail. Personally, I wouldn't use it, as I have in-house systems that I'm tying into dbmail. But there are other for whom this is all they need. > On the other hand, the long int client_idnr field, while not strictly > necessary (the tie-in could be made in another table or db), is nice > and takes a lot less space per row than arbitrary text data. > > >I would suggest that if renaming the client_idnr field, it should be > >called 'group' or 'group_idnr'. > > > Naming it 'group' implies a specific meaning for the field, and > therefore would be confusing to new users/developers. Any new name > should imply *any* use the application desires. Something like > 'external_idnr' would be sufficiently generic. client_idnr is used to group users together, not to record a foreign key. Shared mailboxes makes use of this, I believe, (as will group quotas, if I finish writing it tomorrow). DBMail expects other databases to refer to it's user_idnr field. -- Feargal Reilly, Codeshifter, Chrysalink Systems.
pgpG5aPvy70k5.pgp
Description: PGP signature
