>From a preceding quote " 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. "
Yes thats me !!! For me its politicaly impossible !!! Im using dbmail for my school board, using ldap and writing codes for tying into are school board employes databases is overkill for me. I mith try and ask are financial department analyst to let write codes to acces is microsoft sql payroll database but i think is answer will be (and should be) "over my dead body" But if i ask im for a text file of employes (location,supervisor,telephone number,,,,) so i can automaticaly update fieds in dbmail the anwers will be "no problem you'll have it tomorow" If adding a field or table (thats is not use by a dbmail administrtor) is not overkill for the dbmail system and database then "why not" Dbmail administrators may chose to use it or not. Jacques Selon Feargal Reilly <[EMAIL PROTECTED]>: > 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. > >
