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.
