Mailing List Archive

You're better off not loading user passwords into the database.

You should hack out the authentication routines and have then operate directly
with the system's authentication mechanisms (in fact, this may be of great
benefit to many people if, say, you set it up to use PAM).

If you check back in the archives, I posted an authentication mechanism that
worked with an LDAP server. Basically, the process was to check passwords
against the LDAP, and create a dummy user in the database that matched the
LDAP user so that there would be an id to assign in the relations between
messages and mailboxes and users.

I suggested that the authentication layer be abstracted out a little bit, and
I think that suggestion made it onto the drawing board for post-1.0 development.

Aaron

eddy <eddy@5687.net> said:

> Eelco,
>
> Since I am planning to take over a 20G email system, I am immediate
> facting the file size problem. I can't wait !!
>
> Another suggestion, I don't want to re-asign the password for all users. I
> looking for a solution to import existing hashed passwd from /etc/shadow
> file into the "password" field. I suggest as following :
>
> - in the table user the password field keep the crypt hashed password in
> form of "{crypt}:<hashed password value>"
>
> - the following program need to rewrite to reflect the changes:
> dbmail-imapdB
> - support crypt mode password
> dbmail-pop3d
> - support crypt mode password
> dbmail-adduser
> - add a flag to copy passwd from shadow file.
> - add a flag to hash the clear text password
>
>
> On Sat, 23 Feb 2002, Eelco van Beek wrote:
>
> > Hi Eddy,
> >
> > You're right, in case of mysql there could occur (depending on which OS and
> > filesystem are being used) some problems. Thanks for offering to write a fix
> > for this, however we're currently working on a more abstract database layer
> > and since the 4 GB limit is a shortcoming of MYSQL it should be fixed in
> > that specific layer. Fixing it in the current code would, in my opinion be a
> > waste of your time.
> >
> > What do you think?
> >
> > Best regards,
> >
> > Eelco
> >
> > On 23-02-2002 11:54, "eddy" <eddy@5687.net> wrote:
> >
> > > I was teeting the dbmail and have some suggestion :
> > >
> > > - For a huge email system, add a tablename field for individual user can
> > > guarantee its growing future. I know that a file size over 4G may have
> > > problem or have performance issue.
> > >
> > > May I rewrite this part ?
> >
> >
>
> --
> Eddy Lai
> http://www.5687.net/
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>



--

Its a shame that there isn't some kind of kernel-based default
authentication system in the Linux or BSD kernel.. something like this:

valid_user = kernel_auth("john", ui_passwd);

That would've made things much more easier :)

- Henry

> -----Original Message-----
> From: Aaron Stone [mailto:aaron@engr.Paly.NET]
> Sent: Monday, February 25, 2002 12:17
> To: dbmail@dbmail.org
> Subject: Re: [Dbmail] Re: Some suggestion for dbmail
>
>
> You're better off not loading user passwords into the database.
>
> You should hack out the authentication routines and have then
> operate directly
> with the system's authentication mechanisms (in fact, this
> may be of great
> benefit to many people if, say, you set it up to use PAM).
>
> If you check back in the archives, I posted an authentication
> mechanism that
> worked with an LDAP server. Basically, the process was to
> check passwords
> against the LDAP, and create a dummy user in the database
> that matched the
> LDAP user so that there would be an id to assign in the
> relations between
> messages and mailboxes and users.
>
> I suggested that the authentication layer be abstracted out a
> little bit, and
> I think that suggestion made it onto the drawing board for
> post-1.0 development.
>
> Aaron
>
> eddy <eddy@5687.net> said:
>
> > Eelco,
> >
> > Since I am planning to take over a 20G email system, I am immediate
> > facting the file size problem. I can't wait !!
> >
> > Another suggestion, I don't want to re-asign the password
> for all users. I
> > looking for a solution to import existing hashed passwd
> from /etc/shadow
> > file into the "password" field. I suggest as following :
> >
> > - in the table user the password field keep the crypt
> hashed password in
> > form of "{crypt}:<hashed password value>"
> >
> > - the following program need to rewrite to reflect the changes:
> > dbmail-imapdB
> > - support crypt mode password
> > dbmail-pop3d
> > - support crypt mode password
> > dbmail-adduser
> > - add a flag to copy passwd from shadow file.
> > - add a flag to hash the clear text password
> >
> >
> > On Sat, 23 Feb 2002, Eelco van Beek wrote:
> >
> > > Hi Eddy,
> > >
> > > You're right, in case of mysql there could occur
> (depending on which OS and
> > > filesystem are being used) some problems. Thanks for
> offering to write a fix
> > > for this, however we're currently working on a more
> abstract database layer
> > > and since the 4 GB limit is a shortcoming of MYSQL it
> should be fixed in
> > > that specific layer. Fixing it in the current code would,
> in my opinion be a
> > > waste of your time.
> > >
> > > What do you think?
> > >
> > > Best regards,
> > >
> > > Eelco
> > >
> > > On 23-02-2002 11:54, "eddy" <eddy@5687.net> wrote:
> > >
> > > > I was teeting the dbmail and have some suggestion :
> > > >
> > > > - For a huge email system, add a tablename field for
> individual user can
> > > > guarantee its growing future. I know that a file size
> over 4G may have
> > > > problem or have performance issue.
> > > >
> > > > May I rewrite this part ?
> > >
> > >
> >
> > --
> > Eddy Lai
> > http://www.5687.net/
> >
> > _______________________________________________
> > Dbmail mailing list
> > Dbmail@dbmail.org
> > https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
>
>
>
> --
>
>
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>

Actually, one of the reasons we adopted DBMail was the fact that a
mail user did not have to be a system user... allowing us to delegate
user management to people who we don't necessarily want to have root
privileges.

That restriction is what kept us from moving to a Linux-based email
system for 18 months, because our old NT-based system "spoiled" us.

MHv> Its a shame that there isn't some kind of kernel-based default
MHv> authentication system in the Linux or BSD kernel.. something like this:

MHv> valid_user = kernel_auth("john", ui_passwd);

MHv> That would've made things much more easier :)



--
Jeff Brenton
President,
Engineered Software Products, Inc
http://espi.com
Questionable web page: http://dididahdahdidit.com

Liberalism grants you the freedom to advocate any idea*.
* Please see http://www.dididahdahdidit.com/except.php for a
current list of exceptions

Eelco,

I have completed the crypt hash password section. It can enhance the
security. Even some one break into the database, he still don't know
user's password. It also keep backword compatible with clear text
password mode. The new password related function was :

dbmail-adduser c foo -p passwd (storage foo's passward in clean text)
dbmail-adduser c foo +p passwd (storage foo's password in hash mode)
dbmail-adduser c foo -P (copy foo's password from /etc/shadow)

Now it was suitable for all people. I want copy existing user's password
and they need not remember another new password. A virtual user can create
with enhanced security protection. 8)

I have been consider using PAM function. However it need root rights to
run the function. It may create potential security problem so I drop it.

Ecnlosed was the c program I have amended. I have some remark begin with
"/* eddy" to note the major change. The program in fact was copy from
"b_pam" by bengie@fire.wolfsburg.de and "cpu" by matheny@dbaseiv.net.
Please conside including it into your distribution.

Regards,
Eddy Lai

On Mon, 25 Feb 2002, eddy wrote:

> Eelco,
>
> Since I am planning to take over a 20G email system, I am immediate
> facting the file size problem. I can't wait !!
>
> Another suggestion, I don't want to re-asign the password for all users. I
> looking for a solution to import existing hashed passwd from /etc/shadow
> file into the "password" field. I suggest as following :
>
> - in the table user the password field keep the crypt hashed password in
> form of "{crypt}:<hashed password value>"
>
> - the following program need to rewrite to reflect the changes:
> dbmail-imapdB
> - support crypt mode password
> dbmail-pop3d
> - support crypt mode password
> dbmail-adduser
> - add a flag to copy passwd from shadow file.
> - add a flag to hash the clear text password
>
>

--
Eddy Lai
http://www.5687.net/

It would probably be better to use a new command line option, rather than
hacking on the existing option. There might be several styles of password hash
that people might want to use...

For example, what if I implemented my LDAP hack within your framework? So the
password field might be "{LDAP}:CN=username,OU=group,DC=domain,DC=com"
indicating that the user should be authenticated by connecting to that ldap
account with the supplied password.

This is just coming off the top of my head, so I need to think a little bit
more about the semantics of doing it this way, but I think we might be on to
something...

Aaron

eddy <eddy@5687.net> said:

> Eelco,
>
> I have completed the crypt hash password section. It can enhance the
> security. Even some one break into the database, he still don't know
> user's password. It also keep backword compatible with clear text
> password mode. The new password related function was :
>
> dbmail-adduser c foo -p passwd (storage foo's passward in clean text)
> dbmail-adduser c foo +p passwd (storage foo's password in hash mode)
> dbmail-adduser c foo -P (copy foo's password from /etc/shadow)
>
> Now it was suitable for all people. I want copy existing user's password
> and they need not remember another new password. A virtual user can create
> with enhanced security protection. 8)
>
> I have been consider using PAM function. However it need root rights to
> run the function. It may create potential security problem so I drop it.
>
> Ecnlosed was the c program I have amended. I have some remark begin with
> "/* eddy" to note the major change. The program in fact was copy from
> "b_pam" by bengie@fire.wolfsburg.de and "cpu" by matheny@dbaseiv.net.
> Please conside including it into your distribution.
>
> Regards,
> Eddy Lai
>
> On Mon, 25 Feb 2002, eddy wrote:
>
> > Eelco,
> >
> > Since I am planning to take over a 20G email system, I am immediate
> > facting the file size problem. I can't wait !!
> >
> > Another suggestion, I don't want to re-asign the password for all users. I
> > looking for a solution to import existing hashed passwd from /etc/shadow
> > file into the "password" field. I suggest as following :
> >
> > - in the table user the password field keep the crypt hashed password in
> > form of "{crypt}:<hashed password value>"
> >
> > - the following program need to rewrite to reflect the changes:
> > dbmail-imapdB
> > - support crypt mode password
> > dbmail-pop3d
> > - support crypt mode password
> > dbmail-adduser
> > - add a flag to copy passwd from shadow file.
> > - add a flag to hash the clear text password
> >
> >
>
> --
> Eddy Lai
> http://www.5687.net/
>



--

I'm thinking about this more, and more, and I like it. Minimal changes to and
of the tables, and very straight forward to set up the password layer here.

Two issues, though. One, why are we using a munged password field, that
requires some text processing and whatnot to discover the type of data stored?
Seems silly. Should just add a new field for the password type.

Two, there's two points at which a user is looked up. One for logging in, and
one for receiving mail. My LDAP hacks also obsolete the aliases table by
forcing all lookups for incoming email addresses to search in the LDAP for the
user supposed to receive that mail. I think this is the right way for that to
happen.

However, I did have a bunch of issues with certain "builtin" accounts. Like
postmaster. That account MUST exist according to RFC's, and so I had to set it
up on the LDAP end with an email alias to a user account. INHO, this account
should be built into dbmail (not hardcoded, but distributed in the database
definition certainly). This would also be the default administrative user
account for whatever web based administration interfaces that (if) ever get
written.

So lemme bottom line this: a "fallback list" of incoming lookups, and a type
field for existing user password lookups. What are thinks?

Aaron

Aaron Stone <aaron@engr.Paly.NET> said:

> It would probably be better to use a new command line option, rather than
> hacking on the existing option. There might be several styles of password hash
> that people might want to use...
>
> For example, what if I implemented my LDAP hack within your framework? So the
> password field might be "{LDAP}:CN=username,OU=group,DC=domain,DC=com"
> indicating that the user should be authenticated by connecting to that ldap
> account with the supplied password.
>
> This is just coming off the top of my head, so I need to think a little bit
> more about the semantics of doing it this way, but I think we might be on to
> something...
>
> Aaron
>
> eddy <eddy@5687.net> said:
>
> > Eelco,
> >
> > I have completed the crypt hash password section. It can enhance the
> > security. Even some one break into the database, he still don't know
> > user's password. It also keep backword compatible with clear text
> > password mode. The new password related function was :
> >
> > dbmail-adduser c foo -p passwd (storage foo's passward in clean text)
> > dbmail-adduser c foo +p passwd (storage foo's password in hash mode)
> > dbmail-adduser c foo -P (copy foo's password from /etc/shadow)
> >
> > Now it was suitable for all people. I want copy existing user's password
> > and they need not remember another new password. A virtual user can create
> > with enhanced security protection. 8)
> >
> > I have been consider using PAM function. However it need root rights to
> > run the function. It may create potential security problem so I drop it.
> >
> > Ecnlosed was the c program I have amended. I have some remark begin with
> > "/* eddy" to note the major change. The program in fact was copy from
> > "b_pam" by bengie@fire.wolfsburg.de and "cpu" by matheny@dbaseiv.net.
> > Please conside including it into your distribution.
> >
> > Regards,
> > Eddy Lai
> >
> > On Mon, 25 Feb 2002, eddy wrote:
> >
> > > Eelco,
> > >
> > > Since I am planning to take over a 20G email system, I am immediate
> > > facting the file size problem. I can't wait !!
> > >
> > > Another suggestion, I don't want to re-asign the password for all users. I
> > > looking for a solution to import existing hashed passwd from /etc/shadow
> > > file into the "password" field. I suggest as following :
> > >
> > > - in the table user the password field keep the crypt hashed password in
> > > form of "{crypt}:<hashed password value>"
> > >
> > > - the following program need to rewrite to reflect the changes:
> > > dbmail-imapdB
> > > - support crypt mode password
> > > dbmail-pop3d
> > > - support crypt mode password
> > > dbmail-adduser
> > > - add a flag to copy passwd from shadow file.
> > > - add a flag to hash the clear text password
> > >
> > >
> >
> > --
> > Eddy Lai
> > http://www.5687.net/
> >
>
>
>
> --
>
>
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>



--

> I'm thinking about this more, and more, and I like it. Minimal changes
> to and of the tables, and very straight forward to set up the password layer
> here.
>
> Two issues, though. One, why are we using a munged password field, that
> requires some text processing and whatnot to discover the type of data stored?
> Seems silly. Should just add a new field for the password type.

Addition field to indicate the password type is one of the method. But
using "{LDAP}:CN=username,OU=group,DC=domain,DC=com" to indicate the authorize
by LDAP is okay.

>
> Two, there's two points at which a user is looked up. One for logging
> in, and one for receiving mail. My LDAP hacks also obsolete the aliases
> table by forcing all lookups for incoming email addresses to search in
> the LDAP for the user supposed to receive that mail. I think this is the
> right way for that to happen.
>

It better to allow the dbmail to use multip authorization mothed. Not all
user can handle LDAP,.... For a starter, clear text password is the best
method. The buildin user, it can be dump in the dbase with sql command.

> However, I did have a bunch of issues with certain "builtin" accounts.
> Like postmaster. That account MUST exist according to RFC's, and so I
> had to set it up on the LDAP end with an email alias to a user account.
> INHO, this account should be built into dbmail (not hardcoded, but
> distributed in the database definition certainly). This would also be
> the default administrative user account for whatever web based
> administration interfaces that (if) ever get written.
>
> So lemme bottom line this: a "fallback list" of incoming lookups, and a
> type field for existing user password lookups. What are thinks?

Clear text mode is the best.

>
> Aaron
>
>Aaron Stone <aaron@engr.Paly.NET> said:

--
Eddy Lai
http://www.5687.net/

is there anyway i can look at the LDAP mod you have made

On Sat, 2002-03-02 at 18:59, Aaron Stone wrote:
> I'm thinking about this more, and more, and I like it. Minimal changes to and
> of the tables, and very straight forward to set up the password layer here.
>
> Two issues, though. One, why are we using a munged password field, that

I posted it to the list once or twice, a few months ago.

Aaron

Kerberus <kerberus@microbsd.net> said:

> is there anyway i can look at the LDAP mod you have made
>
> On Sat, 2002-03-02 at 18:59, Aaron Stone wrote:
> > I'm thinking about this more, and more, and I like it. Minimal changes to and
> > of the tables, and very straight forward to set up the password layer here.
> >
> > Two issues, though. One, why are we using a munged password field, that
>
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>



--

I also interest in the LDAP authorization. Can you give your code to me ?
I have my owned web page, I can publish the new code on my site. Since the
archive database didn't contain two months ago message, I can't find the
said coding.

> I posted it to the list once or twice, a few months ago.

> Aaron

--
Eddy Lai <eddy@5687.net>
http://www.5687.net/

Who'd a thunk it, but I've been searching around on this "munged password
field" and it is actually something of a de-facto standard now! Bah!

Basically, OpenLDAP's userPassword field (according to standards compliance)
only took plain text passwords. But lots of different vendors, with whom
OpenLDAP wanted to be compatible, were using different hashes (cough M$ cough)
and so they did this same extension to their password field.

So without too much more jabbering, I'd like to hear from Eelco or Roel on
possibly incorporating this mechanism (yeah yeah, don't worry, I'll write the
code ;-)

Aaron

Aaron Stone <aaron@engr.Paly.NET> said:

> I'm thinking about this more, and more, and I like it. Minimal changes to and
> of the tables, and very straight forward to set up the password layer here.
>
> Two issues, though. One, why are we using a munged password field, that
> requires some text processing and whatnot to discover the type of data stored?
> Seems silly. Should just add a new field for the password type.
>
> Two, there's two points at which a user is looked up. One for logging in, and
> one for receiving mail. My LDAP hacks also obsolete the aliases table by
> forcing all lookups for incoming email addresses to search in the LDAP for the
> user supposed to receive that mail. I think this is the right way for that to
> happen.
>
> However, I did have a bunch of issues with certain "builtin" accounts. Like
> postmaster. That account MUST exist according to RFC's, and so I had to set it
> up on the LDAP end with an email alias to a user account. INHO, this account
> should be built into dbmail (not hardcoded, but distributed in the database
> definition certainly). This would also be the default administrative user
> account for whatever web based administration interfaces that (if) ever get
> written.
>
> So lemme bottom line this: a "fallback list" of incoming lookups, and a type
> field for existing user password lookups. What are thinks?
>
> Aaron
>
> Aaron Stone <aaron@engr.Paly.NET> said:
>
> > It would probably be better to use a new command line option, rather than
> > hacking on the existing option. There might be several styles of password hash
> > that people might want to use...
> >
> > For example, what if I implemented my LDAP hack within your framework? So the
> > password field might be "{LDAP}:CN=username,OU=group,DC=domain,DC=com"
> > indicating that the user should be authenticated by connecting to that ldap
> > account with the supplied password.
> >
> > This is just coming off the top of my head, so I need to think a little bit
> > more about the semantics of doing it this way, but I think we might be on to
> > something...
> >
> > Aaron
> >
> > eddy <eddy@5687.net> said:
> >
> > > Eelco,
> > >
> > > I have completed the crypt hash password section. It can enhance the
> > > security. Even some one break into the database, he still don't know
> > > user's password. It also keep backword compatible with clear text
> > > password mode. The new password related function was :
> > >
> > > dbmail-adduser c foo -p passwd (storage foo's passward in clean text)
> > > dbmail-adduser c foo +p passwd (storage foo's password in hash mode)
> > > dbmail-adduser c foo -P (copy foo's password from /etc/shadow)
> > >
> > > Now it was suitable for all people. I want copy existing user's password
> > > and they need not remember another new password. A virtual user can create
> > > with enhanced security protection. 8)
> > >
> > > I have been consider using PAM function. However it need root rights to
> > > run the function. It may create potential security problem so I drop it.
> > >
> > > Ecnlosed was the c program I have amended. I have some remark begin with
> > > "/* eddy" to note the major change. The program in fact was copy from
> > > "b_pam" by bengie@fire.wolfsburg.de and "cpu" by matheny@dbaseiv.net.
> > > Please conside including it into your distribution.
> > >
> > > Regards,
> > > Eddy Lai
> > >
> > > On Mon, 25 Feb 2002, eddy wrote:
> > >
> > > > Eelco,
> > > >
> > > > Since I am planning to take over a 20G email system, I am immediate
> > > > facting the file size problem. I can't wait !!
> > > >
> > > > Another suggestion, I don't want to re-asign the password for all
users. I
> > > > looking for a solution to import existing hashed passwd from /etc/shadow
> > > > file into the "password" field. I suggest as following :
> > > >
> > > > - in the table user the password field keep the crypt hashed password in
> > > > form of "{crypt}:<hashed password value>"
> > > >
> > > > - the following program need to rewrite to reflect the changes:
> > > > dbmail-imapdB
> > > > - support crypt mode password
> > > > dbmail-pop3d
> > > > - support crypt mode password
> > > > dbmail-adduser
> > > > - add a flag to copy passwd from shadow file.
> > > > - add a flag to hash the clear text password
> > > >
> > > >
> > >
> > > --
> > > Eddy Lai
> > > http://www.5687.net/
> > >
> >
> >
> >
> > --
> >
> >
> >
> > _______________________________________________
> > Dbmail mailing list
> > Dbmail@dbmail.org
> > https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
>
>
>
> --
>
>
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>



--

It's on another machine someplace, I'll find the code and post it but it might
take a week or two to find :-\ ).

About "publishing" it... I would suggest not. I don't want to be responsible
for supporting an LDAP patch to DBMail, especially if there's a good chance
that the code will be part of a future version of DBMail.

Aaron

eddy <eddy@5687.net> said:

> I also interest in the LDAP authorization. Can you give your code to me ?
> I have my owned web page, I can publish the new code on my site. Since the
> archive database didn't contain two months ago message, I can't find the
> said coding.
>
> > I posted it to the list once or twice, a few months ago.
>
> > Aaron
>
> --
> Eddy Lai <eddy@5687.net>
> http://www.5687.net/
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>



--

Here they are...

Michael Rose, Jr.
Intrigent LLC
206-686-7600
michael@intrigent.com


-----Original Message-----
From: dbmail-admin@dbmail.org [mailto:dbmail-admin@dbmail.org] On Behalf
Of Aaron Stone
Sent: Saturday, March 02, 2002 10:07 PM
To: dbmail@dbmail.org
Subject: Re: [Dbmail] Re: Some suggestion for dbmail

It's on another machine someplace, I'll find the code and post it but it
might
take a week or two to find :-\ ).

About "publishing" it... I would suggest not. I don't want to be
responsible
for supporting an LDAP patch to DBMail, especially if there's a good
chance
that the code will be part of a future version of DBMail.

Aaron

eddy <eddy@5687.net> said:

> I also interest in the LDAP authorization. Can you give your code to
me ?
> I have my owned web page, I can publish the new code on my site. Since
the
> archive database didn't contain two months ago message, I can't find
the
> said coding.
>
> > I posted it to the list once or twice, a few months ago.
>
> > Aaron
>
> --
> Eddy Lai <eddy@5687.net>
> http://www.5687.net/
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>



--



_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

May be I am mis-understanding GPL. It allow you to change/enhance the
program and re-distribute the new code. I guess you need not response to
maintenance the code. If I am wrong please let me know.

I am not familiar to LDAP but I am testing a progarm "CPU". It help me to
maintenance the password in LDAP. Therefore I have interest to look for
the LDAP authorization code.

> It's on another machine someplace, I'll find the code and post it but it
> might take a week or two to find :-\ ).
>
> About "publishing" it... I would suggest not. I don't want to be
> responsible for supporting an LDAP patch to DBMail, especially if
> there's a good chance that the code will be part of a future version of
> DBMail.
>
> Aaron



--
Eddy Lai <eddy@5687.net>
http://www.5687.net/