Re: [vchkpw] Old Problem Re-visited
- Original Message - From: Tom Collins [EMAIL PROTECTED] To: vpopmail list [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:51 PM Subject: Re: [vchkpw] Old Problem Re-visited On Tuesday, November 4, 2003, at 08:03 AM, Rick Macdougall wrote: Well my apologies. Mad props to Michael Bowe then, and a virtual beer :) I'll be meeting Michael face-to-face in a few days. It just so happens that he's less than 100km away from the Melbourne stop on my Australia vacation. Send a few bucks to my PayPal account and I'll buy us both a real beer! :-) Haha! Nice one! Michael.
Re: [vchkpw] IMP, vpopmail, and v-users changing passwords?
On Wednesday, November 5, 2003, at 12:22 PM, David Wolfskill wrote: Would anyone care to provide a pointer to a hint for how to accomplish allowing virtual users to change their own passwords? Take a look at qmailadmin. It's overkill for changing passwords, but one of the only ways I know to do it. A feature request for the next development cycle of qmailadmin is to have a simple change password interface where a user can type their email address, old password, and new password (twice) to make the change. -- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] qmailadmin version
On Wednesday, November 5, 2003, at 11:54 AM, Remo Mattei wrote: I have problem once I install qmailadmin on a version that is higher than .16 any suggestions? I do can log in but I cannot see anything else other than logout in the menu list any suggestions? I made changes in 1.0.28 that might be related to that problem, so please try it (download from qmailadmin.sf.net) and let us know if you continue to have problems. -- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
On Tuesday, November 4, 2003, at 05:40 AM, Nick Harring wrote:
Actually, this is already a right place to put this, which is in
randltr. Oddly that's what's used for generating the salt, but not
what's used for generating the password. Instead the password just
uses an ugly rand call.
I'd change vgen_pass to do this:
for (i = 0; i len; i++) {
k = randltr();
p[i] = gen_chars[k];
}
return p;
randltr selects from 64 valid salt characters. The password generator
pulls from a larger selection of possible characters.
I'd even consider modifying the random password generator to not use
letters that can be confused with each other (1/I/l and 0/O).
Also, randltr is relying on something else to seed srand, which is
really a bad idea. One mistake and suddenly everyone's vpopmail
everywhere is seeding with 1. Oops.
randltr is only used by mkpasswd3() which seeds srandom. You need to
be careful to seed rand/random only once.
I agree that we should use /dev/urandom (or /dev/random) if available.
The code should read in enough bytes to generate an entire salt or
random password (however the case may be). I'm willing to explore
adding this to the next development cycle. Right now, I want to get a
5.3.30 release done (and maybe even call it 5.4.0-pre1) so we can have
a stable release for people who've been waiting to upgrade from 5.2.2.
I'll still say that I think this is overkill. I find it extremely
unlikely that someone could determine the random password generated by
vpopmail.
--
Tom Collins - [EMAIL PROTECTED]
Note: The Tom Logic offices will be closed October 23 to November 18.
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] IMP, vpopmail, and v-users changing passwords?
Juging from the subject, if you're using IMP, you can get the 'Passwd' module that integrates a interface to change passwords for users. The new version includes support for the vpopmail, and in my case, I just hacked the code a little to fit my install (very easy to do). []'s Hugo Tom Collins wrote: On Wednesday, November 5, 2003, at 12:22 PM, David Wolfskill wrote: Would anyone care to provide a pointer to a hint for how to accomplish allowing virtual users to change their own passwords? Take a look at qmailadmin. It's overkill for changing passwords, but one of the only ways I know to do it. A feature request for the next development cycle of qmailadmin is to have a simple change password interface where a user can type their email address, old password, and new password (twice) to make the change. -- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
[vchkpw] skel
Isn't there a way to have like a /etc/skel but for vpopmail users like a skel with a dot qmail file and some extra imap folders and such? if not that would be a great feutre request.. /R
Re: [vchkpw] qmailadmin version
i recently install qmailadmin-stable (and latest devel) with vpopmail-5.3.29 with postgresql auth, instalation work fine, but qmailadmin not do his job. , i can login with postmaster account, but every link that i click, return with empty page. and error from apache; I have duplicated that fault on my test server I have an idea where it is coming from Hopefully I can post a patch soon. OK, I have found the bug. It is in the vauth_getall() function I have opened tracker on sourceforge for it [837139] Patch to be uploaded shortly. Michael.
RE: [vchkpw] Has the format of vpasswd file changed?
We added a clear password field that used to be default turned off for backwards compatibility. I think in later versions of 5.3 folks updated the code to support either. I'd recommend backing up your vpopmail/bin, lib and include directory then doing a regular install of vpopmail with --enable-clear-passwd=n. Re config/compile courier-imap from scratch. If that does not work you can put the old binaries back. I bet it would work. It's a good bet. Everything's working well now. Thanks for the suggestion. my 2cents Worth a lot more than that!
[vchkpw] vpopmail and smtp-auth...
Hello All, i have a stupid problem with vpopmail and smtp-after-pop or smtp-auth. I have read a howto in the web where vpopmail is used to make smtp-after-pop or smtp-auth. I have configured my run script for pop3d and smtpd like it was configured in the howto but it doesn't work. The virual Domains are running and the pop3d is running too but i could not get smtpd running with authentification. Here is my qmail-smtpd/run script: #!/bin/bash QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` exec /usr/bin/softlimit -m 6600 \ /usr/bin/tcpserver -H -R -v -p -x /etc/tcp.smtp.cdb \ -c $MAXSMTPD -u $QMAILDUID -g $NOFILESGID \ 0 smtp /var/qmail/bin/qmail-smtpd `hostname --fqdn` \ /var/vpopmail/bin/vchkpw /bin/true 21 could someone tell me whats wrong here? is it possible to do it like i want it? Only people who are in registered as virtual-domain-email-user should be allowed to send email thrue my smtp server. I don't need smtp-after-pop, smtp-auth is doing all i need but it could be smtp-after-pop too... Okay, sorry for my English and maybe stupid question... Regards hanez P.S.: My logs are looking okay... No Errors are registered there and smtp is working but without any control. -- BASH Boy for life! Key fingerprint = DCD0 990F 6BD8 6E5F 439D 4257 D5ED FB77 F58D 4435 http://pgp.mit.edu:11371/pks/lookup?search=you%40hanez.orgop=index
[vchkpw] RE: vpopmail and smtp-auth...
Hello All, i have a stupid problem with vpopmail and smtp-after-pop or smtp-auth. I have read a howto in the web where vpopmail is used to make smtp-after-pop or smtp-auth. I have configured my run script for pop3d and smtpd like it was configured in the howto but it doesn't work. The virual Domains are running and the pop3d is running too but i could not get smtpd running with authentification. Here is my qmail-smtpd/run script: #!/bin/bash QMAILDUID=`id -u vpopmail` NOFILESGID=`id -g vpopmail` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` exec /usr/bin/softlimit -m 6600 \ /usr/bin/tcpserver -H -R -v -p -x /etc/tcp.smtp.cdb \ -c $MAXSMTPD -u $QMAILDUID -g $NOFILESGID \ 0 smtp /var/qmail/bin/qmail-smtpd `hostname --fqdn` \ /var/vpopmail/bin/vchkpw /bin/true 21 could someone tell me whats wrong here? is it possible to do it like i want it? Only people who are in registered as virtual-domain-email-user should be allowed to send email thrue my smtp server. I don't need smtp-after-pop, smtp-auth is doing all i need but it could be smtp-after-pop too... Three questions: 1. have you checked to make sure that `hostname --fqdn` returns your domain name? 2. Did you apply the smtp-auth patch to qmail before running make? 3. Are you sure that the path to vchkpw is /var/vpopmail/bin and not /home/vpopmail/bin? I think that the default install directory for vpopmail is in /home.
Re: [vchkpw] RE: vpopmail and smtp-auth...
Three questions: 1. have you checked to make sure that `hostname --fqdn` returns your domain name? Yes, it returns the hostname of my Server but the domain name is not a virtual host... should it be that? 2. Did you apply the smtp-auth patch to qmail before running make? Yes, i use Gentoo-Linux and the Patch is inluded and qmail should be patched... I have thought that it could the problem already. 3. Are you sure that the path to vchkpw is /var/vpopmail/bin and not /home/vpopmail/bin? I think that the default install directory for vpopmail is in /home. Yes, thats right but in Gentoo they have changed the path from /home/vpopmail to /var/vpopmail. I have checked that and vchkpw is in this path. Is my solution possible? regards hanez -- BASH Boy for life! Key fingerprint = DCD0 990F 6BD8 6E5F 439D 4257 D5ED FB77 F58D 4435 http://pgp.mit.edu:11371/pks/lookup?search=you%40hanez.orgop=index
[vchkpw] RE: vpopmail and smtp-auth...
Three questions: 1. have you checked to make sure that `hostname --fqdn` returns your domain name? Yes, it returns the hostname of my Server but the domain name is not a virtual host... should it be that? No, shouldn't matter. 2. Did you apply the smtp-auth patch to qmail before running make? Yes, i use Gentoo-Linux and the Patch is inluded and qmail should be patched... I have thought that it could the problem already. OK. Had to ask, anyway. I'm not familiar with Gentoo. 3. Are you sure that the path to vchkpw is /var/vpopmail/bin and not /home/vpopmail/bin? I think that the default install directory for vpopmail is in /home. Yes, thats right but in Gentoo they have changed the path from /home/vpopmail to /var/vpopmail. I have checked that and vchkpw is in this path. Figured as much. Is my solution possible? It should be. How are you deducing that amtp-auth is not working? What have you tried?
Re: [vchkpw] RE: vpopmail and smtp-auth...
Three questions: 1. have you checked to make sure that `hostname --fqdn` returns your domain name? Yes, it returns the hostname of my Server but the domain name is not a virtual host... should it be that? No, shouldn't matter. 2. Did you apply the smtp-auth patch to qmail before running make? Yes, i use Gentoo-Linux and the Patch is inluded and qmail should be patched... I have thought that it could the problem already. OK. Had to ask, anyway. I'm not familiar with Gentoo. 3. Are you sure that the path to vchkpw is /var/vpopmail/bin and not /home/vpopmail/bin? I think that the default install directory for vpopmail is in /home. Yes, thats right but in Gentoo they have changed the path from /home/vpopmail to /var/vpopmail. I have checked that and vchkpw is in this path. Figured as much. Is my solution possible? It should be. How are you deducing that amtp-auth is not working? What have you tried? Yes that is it .. you may have tried it from telnet fqdn 25 but .. it should need a encripted password ... better try with Outlook or so ... also send the Telnet out put Also .. to the List Guys .. is there any problem with vpopmail to be used for smpt auth . [i mean some open relay probelm in any of the versions of vpopmail] regards Girish
Re: [vchkpw] RE: vpopmail and smtp-auth...
What have you tried? I'm using KMail in KDE and it has a function in the server setup where i can check what auhentication methods are supported by the server. KMail said that PLAIN, LOGIN and CRAM-MD5 are supported. When i'm configuring my SMTP Setup for using CRAM-MD5 the server said authorization failed (#5.7.0). Okay, i have found a permission problem on the dirs and smtp-after-pop is working now but shouldn't smtp-auth work too? It doesn't! I got the above message when trying to send a mail before i have logged in via pop3. hanez -- BASH Boy for life! Key fingerprint = DCD0 990F 6BD8 6E5F 439D 4257 D5ED FB77 F58D 4435 http://pgp.mit.edu:11371/pks/lookup?search=you%40hanez.orgop=index
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Tom Collins wrote:
On Tuesday, November 4, 2003, at 05:40 AM, Nick Harring wrote:
Actually, this is already a right place to put this, which is in
randltr. Oddly that's what's used for generating the salt, but not
what's used for generating the password. Instead the password just
uses an ugly rand call.
I'd change vgen_pass to do this:
for (i = 0; i len; i++) {
k = randltr();
p[i] = gen_chars[k];
}
return p;
randltr selects from 64 valid salt characters. The password generator
pulls from a larger selection of possible characters.
I'd even consider modifying the random password generator to not use
letters that can be confused with each other (1/I/l and 0/O).
That'd be foolish in the extreme. If the user, or administrator, wants
passwords that are easy to remember or hard to confuse then they
should take the onerous burden on themselves. The random password
function, by using the word random, is promising a certain functionality
and what you propose doesn't deliver it. Narrowing the possible scope
for each letter to 64 from some larger group but increasing the entropy
that goes into selecting each character seems like a good idea to me.
The valid salt chars for DES, with which we must maintain backwards
compatability, are [a-zA-Z0-9./]. The additional characters that
vgen_pass() can be using are [EMAIL PROTECTED]*()-_=+\|]}[{';:, by my count
that's 29 new characters. A decently larger set, but not substantially so.
This means that an 8 character password, which is what gets created when
vpopmail creates a random password for you, can be one of either
6.27710173538668e+57 or 9.71334446112865e+83 combinations, depending on
how many characters you allow. I personally think we should lean towards
higher entropy within a smaller field rather than dramatically lower
entropy within a somewhat larger field. I do not, however, have any
evidence to back this up at the moment. If you'd like me to back the
above up, or withdraw it, based on an actual expert opinion I'd be more
than happy to do some research this evening to see what the pro's say.
We could also increase the size of the MD5 salt, since we're allowed 8
characters plus the leading $1$ and an optional, terminating $. This'd
be easy to do, backwards compatible, and ought to increase security to
at least some extent.
Also, randltr is relying on something else to seed srand, which is
really a bad idea. One mistake and suddenly everyone's vpopmail
everywhere is seeding with 1. Oops.
randltr is only used by mkpasswd3() which seeds srandom. You need to
be careful to seed rand/random only once.
There's no real reason that I can determine, from either the man pages,
my experience, or the experience of the people around me that says you
need to be careful to seed the random pool only once. It doesn't break
anything. At worst its inefficient.
If you are so terribly worried you can waste 1 byte of memory with a
flag indicating that srand has been called and thus not do it again.
Since you've not yet done that, but instead relied on nobody calling
mkpasswd3() AND vgen_pass() in a series, I'm guessing you weren't that
worried.
I agree that we should use /dev/urandom (or /dev/random) if
available. The code should read in enough bytes to generate an entire
salt or random password (however the case may be). I'm willing to
explore adding this to the next development cycle. Right now, I want
to get a 5.3.30 release done (and maybe even call it 5.4.0-pre1) so we
can have a stable release for people who've been waiting to upgrade
from 5.2.2.
A stable release would be a Good Thing. I'm one of those people waiting
to upgrade, however I'd consider this a fairly serious, albeit still
theoretical, bug in the password generating and hashing functions.
I'll still say that I think this is overkill. I find it extremely
unlikely that someone could determine the random password generated by
vpopmail.
People found it extremely unlikely that anyone could brute force DES
crypted passwords for a long time. Then someone did it and everyone
moved to MD5. Remember, the crypted password used to be kept in
/etc/passwd, which was world readable, since no one worried about it.
Shrugging off easily fixable bugs as theoretical keeps getting people
into trouble, and yet everyone keeps trying to shrug them off. Even
worse, shrugging them off publicly seems to invite people to prove you
wrong.
As far as I'm concerned, when it comes to security the line between
enough and overkill is very very blurry. I usually draw it when
something is measurably secure AND the workload to continue making it
more secure begins going up dramatically. In this case I just don't see
the workload going up by very much, but the level of security would seem
to be going up dramatically.
--
Tom Collins - [EMAIL PROTECTED]
Note: The Tom Logic offices will be closed October 23 to November 18.
QmailAdmin: http://qmailadmin.sf.net/
Re: [vchkpw] RE: vpopmail and smtp-auth...
Johannes Findeisen wrote: What have you tried? I'm using KMail in KDE and it has a function in the server setup where i can check what auhentication methods are supported by the server. KMail said that PLAIN, LOGIN and CRAM-MD5 are supported. When i'm configuring my SMTP Setup for using CRAM-MD5 the server said "authorization failed (#5.7.0)". Didn't see this asked or answered earlier, but are you running a recent enough version of vpopmail that it supports cram-md5 auth? Also, are you running with cleartext passwords enabled? These both must be true for cram-md5 to work. Perhaps you should try forcing KMail to use plain or login, or test them yourself with telnet and perl. Okay, i have found a permission problem on the dirs and smtp-after-pop is working now but shouldn't smtp-auth work too? It doesn't! I got the above message when trying to send a mail before i have logged in via pop3. hanez Hope that Helps, Nick Harring
Re: [vchkpw] skel
On Thu, 2003-11-06 at 04:34, Raboo Treed wrote:
Isn't there a way to have like a /etc/skel but for vpopmail users
like a skel with a dot qmail file and some extra imap folders and such?
if not that would be a great feutre request..
Below is a copy of an email and patch submitted by David Winkler back in
September to handle just that.
--enable-vpopmail-skel=y
Hello again,
I seem to have answered my own question. Here
is my unified diff against cvs if anyone is interested.
Enjoy!
David
Index: vpopmail.c
===
RCS file: /cvsroot/vpopmail/vpopmail/vpopmail.c,v
retrieving revision 1.2
diff -u -r1.2 vpopmail.c
--- vpopmail.c 14 Sep 2003 22:17:30 - 1.2
+++ vpopmail.c 23 Sep 2003 19:12:45 -
@@ -1655,6 +1655,7 @@
struct vqpasswd *mypw;
char calling_dir[MAX_BUFF];
char domain_dir[MAX_BUFF];
+ char tmpbuf[MAX_BUFF];
verrori = 0;
/* record the dir where the command was run from */
@@ -1701,6 +1702,7 @@
return(NULL);
}
+#ifndef ENABLE_VPOPMAIL_SKEL
if (mkdir(Maildir,VPOPMAIL_DIR_MODE) == -1){
/* back out of changes made above */
chdir(domain_dir); chdir(user_hash); vdelfiles(username);
@@ -1743,6 +1745,12 @@
/* set permissions on the user's dir */
chdir(../..);
+#else
+ sprintf(tmpbuf, cp -rf %s/etc/skel/* %s/%s,
VPOPMAILDIR,domain_dir,username);
+ system(tmpbuf);
+ chdir(../);
+#endif
+
r_chown(username, uid, gid);
/* see if the user already exists in the auth backend */
Index: acconfig.h
===
RCS file: /cvsroot/vpopmail/vpopmail/acconfig.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 acconfig.h
--- acconfig.h 10 Sep 2003 20:43:14 - 1.1.1.1
+++ acconfig.h 23 Sep 2003 19:12:45 -
@@ -1,3 +1,5 @@
+#undef ENABLE_VPOPMAIL_SKEL
+
#undef PS_COMMAND
#undef ENABLE_PASSWD
Index: Makefile.am
===
RCS file: /cvsroot/vpopmail/vpopmail/Makefile.am,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile.am
--- Makefile.am 10 Sep 2003 20:43:12 - 1.1.1.1
+++ Makefile.am 23 Sep 2003 19:12:45 -
@@ -94,6 +94,12 @@
$(DESTDIR)@vpopmaildir@/@domains_dir@
$(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir/new
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir/cur
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir/tmp
+
echo [EMAIL PROTECTED]@/include @vpopmaildir@/etc/inc_deps
echo [EMAIL PROTECTED]@/lib -lvpopmail @auth_libs@
@vpopmaildir@/etc/lib_deps
Index: configure.in
===
RCS file: /cvsroot/vpopmail/vpopmail/configure.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure.in
--- configure.in10 Sep 2003 20:43:11 - 1.1.1.1
+++ configure.in23 Sep 2003 19:12:45 -
@@ -342,6 +342,23 @@
;;
esac
+AC_ARG_ENABLE(vpopmail-skel,
+ [ --enable-vpopmail-skel=y|nTurn on (y) or off (n,
default) to use
+vpopmail skeleton for new users.],
+ ENABLE_VPOPMAIL_SKEL=$enableval,
+ [
+ ENABLE_VPOPMAIL_SKEL=n
+ ])
+
+case $ENABLE_VPOPMAIL_SKEL in
+1*|y*|Y*)
+ ENABLE_VPOPMAIL_SKEL=1
+
AC_DEFINE_UNQUOTED(ENABLE_VPOPMAIL_SKEL,$ENABLE_VPOPMAIL_SKEL)
+ ;;
+*)
+ ;;
+esac
+
AC_ARG_ENABLE(md5-passwords,
[ --enable-md5-passwords=y|n Turn on (y default ) or off (n)
to store encrypted passwords as md5.],
ENABLE_MD5_PASSWORDS=$enableval,
@@ -1315,6 +1332,15 @@
;;
esac
+case $ENABLE_VPOPMAIL_SKEL in
+1*|y*|Y*)
+echo vpop skel = ON --enable-vpopmail-skel=y
+echo --enable-vpopmail-skel=y \\ vpopmail.config.sh
+ ;;
+*)
+echo vpop skel = OFF --enable-vpopmail-skel=n (default)
+ ;;
+esac
case $ENABLE_LOGGING in
1*|y*|Y*)
[vchkpw] disable/redirect bounce message using valias
I am using qmail with vpopmail. Using the valias functionality, I provide users an alias email address on our mail server. However, if e.g. the users email address is not valid or his account is full, the relayed message will bounce. Unfortunately, the bounced message will then also contain the users original email address. And thus his identity is no longer protected. Is there any chance that I can use the valias relaying technique without up the privacy of the user when a bounce occurs? Thanks a lot Klaus --- part of the bounce Hi. This is the qmail-send program at sun. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: 217.72.192.149 does not like recipient. Remote host said: 550 Unknown local part 34985785753857984 in [EMAIL PROTECTED] Giving up on --- log file --- 2003-11-06 21:09:38.841125500 info msg 6532: bytes 1217 from [EMAIL PROTECTED] qp 21688 uid 504 2003-11-06 21:09:38.981216500 starting delivery 218: msg 6532 to local [EMAIL PROTECTED] 2003-11-06 21:09:38.981235500 status: local 1/10 remote 0/20 2003-11-06 21:09:39.115389500 new msg 6534 2003-11-06 21:09:39.115498500 info msg 6534: bytes 1319 from [EMAIL PROTECTED] qp 21693 uid 89 2003-11-06 21:09:39.225814500 starting delivery 219: msg 6534 to remote [EMAIL PROTECTED] 2003-11-06 21:09:39.225832500 status: local 1/10 remote 1/20 2003-11-06 21:09:39.225886500 delivery 218: success: vdelivermail:_valiases_processed/did_0+0+1/ 2003-11-06 21:09:39.226298500 status: local 0/10 remote 1/20 2003-11-06 21:09:39.228225500 end msg 6532 2003-11-06 21:09:39.295339500 delivery 219: failure: 217.72.192.149_does_not_like_recipient./Remote_host_said:_550_Unknown_local_ part_34985785753857984_in_[EMAIL PROTECTED]/Giving_up_on_217. 72.192.149./ 2003-11-06 21:09:39.296037500 status: local 0/10 remote 0/20 2003-11-06 21:09:39.401720500 bounce msg 6534 qp 21695 2003-11-06 21:09:39.401978500 end msg 6534 2003-11-06 21:09:39.402656500 new msg 6581 2003-11-06 21:09:39.402749500 info msg 6581: bytes 1975 from qp 21695 uid 509 2003-11-06 21:09:39.524934500 starting delivery 220: msg 6581 to remote [EMAIL PROTECTED] 2003-11-06 21:09:39.524952500 status: local 0/10 remote 1/20
Re: [vchkpw] Has the format of vpasswd file changed?
On Friday, November 7, 2003, at 12:15 AM, Kleiner, Peter wrote: I'd recommend backing up your vpopmail/bin, lib and include directory then doing a regular install of vpopmail with --enable-clear-passwd=n. Re config/compile courier-imap from scratch. If that does not work you can put the old binaries back. I bet it would work. It's a good bet. Everything's working well now. Thanks for the suggestion. Vpopmail 5.2.2 includes the clear-passwd patches from the 5.3 series. You can --enable-clear-passwd and it will work properly with old vpasswd files. -- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] skel
Tom, Ken Can't anyone of you guys add this to the vpopmail code?
I think it's a great feautre, and I also think that many would agree with me
about this..
- Original Message -
From: Jay Tortorelli [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 7:52 PM
Subject: Re: [vchkpw] skel
On Thu, 2003-11-06 at 04:34, Raboo Treed wrote:
Isn't there a way to have like a /etc/skel but for vpopmail users
like a skel with a dot qmail file and some extra imap folders and
such?
if not that would be a great feutre request..
Below is a copy of an email and patch submitted by David Winkler back in
September to handle just that.
--enable-vpopmail-skel=y
Hello again,
I seem to have answered my own question. Here
is my unified diff against cvs if anyone is interested.
Enjoy!
David
Index: vpopmail.c
===
RCS file: /cvsroot/vpopmail/vpopmail/vpopmail.c,v
retrieving revision 1.2
diff -u -r1.2 vpopmail.c
--- vpopmail.c 14 Sep 2003 22:17:30 - 1.2
+++ vpopmail.c 23 Sep 2003 19:12:45 -
@@ -1655,6 +1655,7 @@
struct vqpasswd *mypw;
char calling_dir[MAX_BUFF];
char domain_dir[MAX_BUFF];
+ char tmpbuf[MAX_BUFF];
verrori = 0;
/* record the dir where the command was run from */
@@ -1701,6 +1702,7 @@
return(NULL);
}
+#ifndef ENABLE_VPOPMAIL_SKEL
if (mkdir(Maildir,VPOPMAIL_DIR_MODE) == -1){
/* back out of changes made above */
chdir(domain_dir); chdir(user_hash); vdelfiles(username);
@@ -1743,6 +1745,12 @@
/* set permissions on the user's dir */
chdir(../..);
+#else
+ sprintf(tmpbuf, cp -rf %s/etc/skel/* %s/%s,
VPOPMAILDIR,domain_dir,username);
+ system(tmpbuf);
+ chdir(../);
+#endif
+
r_chown(username, uid, gid);
/* see if the user already exists in the auth backend */
Index: acconfig.h
===
RCS file: /cvsroot/vpopmail/vpopmail/acconfig.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 acconfig.h
--- acconfig.h 10 Sep 2003 20:43:14 - 1.1.1.1
+++ acconfig.h 23 Sep 2003 19:12:45 -
@@ -1,3 +1,5 @@
+#undef ENABLE_VPOPMAIL_SKEL
+
#undef PS_COMMAND
#undef ENABLE_PASSWD
Index: Makefile.am
===
RCS file: /cvsroot/vpopmail/vpopmail/Makefile.am,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile.am
--- Makefile.am 10 Sep 2003 20:43:12 - 1.1.1.1
+++ Makefile.am 23 Sep 2003 19:12:45 -
@@ -94,6 +94,12 @@
$(DESTDIR)@vpopmaildir@/@domains_dir@
$(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir/new
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir/cur
+ $(INSTALL) -d $(DESTDIR)@vpopmaildir@/etc/skel/Maildir/tmp
+
echo [EMAIL PROTECTED]@/include @vpopmaildir@/etc/inc_deps
echo [EMAIL PROTECTED]@/lib -lvpopmail @auth_libs@
@vpopmaildir@/etc/lib_deps
Index: configure.in
===
RCS file: /cvsroot/vpopmail/vpopmail/configure.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure.in
--- configure.in10 Sep 2003 20:43:11 - 1.1.1.1
+++ configure.in23 Sep 2003 19:12:45 -
@@ -342,6 +342,23 @@
;;
esac
+AC_ARG_ENABLE(vpopmail-skel,
+ [ --enable-vpopmail-skel=y|nTurn on (y) or off (n,
default) to use
+vpopmail skeleton for new users.],
+ ENABLE_VPOPMAIL_SKEL=$enableval,
+ [
+ ENABLE_VPOPMAIL_SKEL=n
+ ])
+
+case $ENABLE_VPOPMAIL_SKEL in
+1*|y*|Y*)
+ ENABLE_VPOPMAIL_SKEL=1
+
AC_DEFINE_UNQUOTED(ENABLE_VPOPMAIL_SKEL,$ENABLE_VPOPMAIL_SKEL)
+ ;;
+*)
+ ;;
+esac
+
AC_ARG_ENABLE(md5-passwords,
[ --enable-md5-passwords=y|n Turn on (y default ) or off (n)
to store encrypted passwords as md5.],
ENABLE_MD5_PASSWORDS=$enableval,
@@ -1315,6 +1332,15 @@
;;
esac
+case $ENABLE_VPOPMAIL_SKEL in
+1*|y*|Y*)
+echo vpop skel = ON --enable-vpopmail-skel=y
+echo --enable-vpopmail-skel=y \\ vpopmail.config.sh
+ ;;
+*)
+echo vpop skel = OFF --enable-vpopmail-skel=n (default)
+ ;;
+esac
case $ENABLE_LOGGING in
1*|y*|Y*)
Re: [vchkpw] skel
Raboo Treed wrote: Tom, Ken Can't anyone of you guys add this to the vpopmail code? I think it's a great feautre, and I also think that many would agree with me about this.. snip Personally i have to disagree. It works fine the standard way it currently is, and i dont see a need for this. It would only add more confusion. Unless its a compile time configurable argument, in which case it would be okay. X
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
On Friday, November 7, 2003, at 02:27 AM, Nick Harring wrote:
I'd even consider modifying the random password generator to not use
letters that can be confused with each other (1/I/l and 0/O).
That'd be foolish in the extreme. If the user, or administrator, wants
passwords that are easy to remember or hard to confuse then they
should take the onerous burden on themselves. The random password
function, by using the word random, is promising a certain
functionality and what you propose doesn't deliver it.
I think that's somewhat extreme. A random password is just that --
randomly generated. No guarantees on the randomness of the random
number generator, or on the number of characters selected from.
Eliminating 5 characters from a possible 70-80 is not foolish. Having
admins set up new accounts with passwords like PASSWORD or the user's
last name is foolish.
Narrowing the possible scope for each letter to 64 from some larger
group but increasing the entropy that goes into selecting each
character seems like a good idea to me.
Remember that we're only selecting 8 random characters -- that's about
40-bits of random numbers. No one has shown that the current method
results in a limited set of possible passwords. I'm not arguing
against using /dev/[u]random, I'm just saying that it's possible to
over-engineer a random password generator...
The valid salt chars for DES, with which we must maintain backwards
compatability, are [a-zA-Z0-9./]. The additional characters that
vgen_pass() can be using are [EMAIL PROTECTED]*()-_=+\|]}[{';:, by my count
that's 29 new characters. A decently larger set, but not substantially
so.
This means that an 8 character password, which is what gets created
when vpopmail creates a random password for you, can be one of either
6.27710173538668e+57 or 9.71334446112865e+83 combinations, depending
on how many characters you allow. I personally think we should lean
towards higher entropy within a smaller field rather than dramatically
lower entropy within a somewhat larger field.
I'm not sure how to measure entropy, but with the small number of bits
we're looking at, you reach a point where additional entropy gains you
nothing, whereas additional characters to choose from does.
I do not, however, have any evidence to back this up at the moment.
If you'd like me to back the above up, or withdraw it, based on an
actual expert opinion I'd be more than happy to do some research this
evening to see what the pro's say.
I'm not an encryption expert, so I'm open to professional opinions on
the subject.
We could also increase the size of the MD5 salt, since we're allowed 8
characters plus the leading $1$ and an optional, terminating $. This'd
be easy to do, backwards compatible, and ought to increase security to
at least some extent.
The more recent versions of vpopmail use the full-size salt.
Also, randltr is relying on something else to seed srand, which is
really a bad idea. One mistake and suddenly everyone's vpopmail
everywhere is seeding with 1. Oops.
randltr is only used by mkpasswd3() which seeds srandom. You need to
be careful to seed rand/random only once.
There's no real reason that I can determine, from either the man
pages, my experience, or the experience of the people around me that
says you need to be careful to seed the random pool only once. It
doesn't break anything. At worst its inefficient.
If you seed it repeatedly with the same value (for example, based on
time() and pid) then you reset the random number generator and get
repeated results.
If you are so terribly worried you can waste 1 byte of memory with a
flag indicating that srand has been called and thus not do it again.
Since you've not yet done that, but instead relied on nobody calling
mkpasswd3() AND vgen_pass() in a series, I'm guessing you weren't that
worried.
You're right, I only use local flags for each routine. Making a global
flag would be better.
I agree that we should use /dev/urandom (or /dev/random) if
available. The code should read in enough bytes to generate an
entire salt or random password (however the case may be). I'm
willing to explore adding this to the next development cycle. Right
now, I want to get a 5.3.30 release done (and maybe even call it
5.4.0-pre1) so we can have a stable release for people who've been
waiting to upgrade from 5.2.2.
A stable release would be a Good Thing. I'm one of those people
waiting to upgrade, however I'd consider this a fairly serious, albeit
still theoretical, bug in the password generating and hashing
functions.
I disagree. I made improvements on the code because I ran into an
instance where vadduser could generate the same random password when
called twice in a row. Adding configure options to detect the presence
of /dev/random or /dev/urandom and modifying the code to use either is
not a simple change.
After we release 5.4.0, we can introduce the new code into the 5.5
series,
Re: [vchkpw] skel
On Friday, November 7, 2003, at 10:02 AM, Raboo Treed wrote: Tom, Ken Can't anyone of you guys add this to the vpopmail code? I think it's a great feautre, and I also think that many would agree with me about this.. It's a good feature, but not ready for the release version of vpopmail. It makes use of a system call to copy the files. I emailed the original author with code to handle the copying within vpopmail. If that gets integrated, replacing the system call to cp, then I'll consider adding it. -- Tom Collins - [EMAIL PROTECTED] Note: The Tom Logic offices will be closed October 23 to November 18. QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] skel
hmm well this patch was bad, cause it had some text-wrapping... I fixed that... but still that patch doesn't work with the latest devel of vpopmail Does anyone have a working one with 5.3.29? It's a good feature, but not ready for the release version of vpopmail. I think I'm gonna have to dissagree, thats exactly what many ppl are looking for in a new stable release, some new useful feautres, and this feautre is good for anti-spam, anti-virus setup's It makes use of a system call to copy the files. I emailed the original author with code to handle the copying within vpopmail. If that gets integrated, replacing the system call to cp, then I'll consider adding it. David Winkler would you fix that Tom just said if you by any chance are reading this or anyone else that got the times and knowdlege to do it? And seriously, I'm not a coder, but I think like this, the code is probibly(I would think) applied to the vadduser part of the code? So that would mean you must be either vpopmail or root to run it,, hence it isn't suid.. So if a intruder would get access as root or vpopmail user they wouldn't use some vadduser binary to insecure your system...?? Or just maybe someone would be able in some difficult way thru qmailadmin be able to haxx0r your system just cause of the vadduser code is using system?? I think it's safe enough.. I don't know about this for sure, but for me it sounds pretty hard??? /Raboo
Re: [vchkpw] skel
Raboo Treed wrote: hmm well this patch was bad, cause it had some text-wrapping... I fixed that... but still that patch doesn't work with the latest devel of vpopmail Does anyone have a working one with 5.3.29? So if a intruder would get access as root or vpopmail user they wouldn't use some vadduser binary to insecure your system...?? Or just maybe someone would be able in some difficult way thru qmailadmin be able to haxx0r your system just cause of the vadduser code is using system?? A root compromise of the system isn't the only thing one has to worry about. I'd be pretty pissed if someone inserted something into my skel that resulted in all of my email being duplicated and sent to someone else. Using cp when you could just copy the files in C in a secure manner is just silly. Its also less efficient, as an added bonus. I think it's safe enough.. I don't know about this for sure, but for me it sounds pretty hard??? /Raboo Exploitable just isn't safe enough. I've disagreed with Tom about the level of paranoia required (see the password/salt generation thread), but in this case he's absolutely right about requiring more than the current patch supplies. Cheers, Nick Harring Webley Systems
Re: [vchkpw] skel
X-Istence wrote: Raboo Treed wrote: Tom, Ken Can't anyone of you guys add this to the vpopmail code? I think it's a great feautre, and I also think that many would agree with me about this.. snip Personally i have to disagree. It works fine the standard way it currently is, and i dont see a need for this. It would only add more confusion. Unless its a compile time configurable argument, in which case it would be okay. X Notice the --enable-feature part of the description of the patch? By default this would suck, as an option its perfect. Cheers, Nick Harring Webley Systems
Re: [vchkpw] skel
A root compromise of the system isn't the only thing one has to worry about. I'd be pretty pissed if someone inserted something into my skel that resulted in all of my email being duplicated and sent to someone else. Using cp when you could just copy the files in C in a secure manner is just silly. Its also less efficient, as an added bonus. Exploitable just isn't safe enough. I've disagreed with Tom about the level of paranoia required (see the password/salt generation thread), but in this case he's absolutely right about requiring more than the current patch supplies. Who will be our saviour and take on the task to make the patch secure and worthy to be a part of vpopmail future releases ( P.S. sorry Nick if you've recived the message twice I pressed the wrong reply button at first )
Re: [vchkpw] skel
I'm planning on rewriting it correctly. At the time I really hadn't considered the implications of how it worked, and the fact that it isn't really cross platform. I'll submit another with a more secure, cross platform diff, as soon as I am able against whatever is current in cvs at the time. Thanks! David - Original Message - From: Raboo Treed [EMAIL PROTECTED] To: vpopmail list [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 6:25 PM Subject: Re: [vchkpw] skel A root compromise of the system isn't the only thing one has to worry about. I'd be pretty pissed if someone inserted something into my skel that resulted in all of my email being duplicated and sent to someone else. Using cp when you could just copy the files in C in a secure manner is just silly. Its also less efficient, as an added bonus. Exploitable just isn't safe enough. I've disagreed with Tom about the level of paranoia required (see the password/salt generation thread), but in this case he's absolutely right about requiring more than the current patch supplies. Who will be our saviour and take on the task to make the patch secure and worthy to be a part of vpopmail future releases ( P.S. sorry Nick if you've recived the message twice I pressed the wrong reply button at first )
