Re: [vchkpw] php extension or daemon
From: Iavor Raytchev [EMAIL PROTECTED] I posted here a couple of days ago a note about the php vpopmail extension and I got in touch with Rick Widmer who has done some progress on it. As I wrote then - we want to write high level php/Smarty GUI for vpopmail management module. The main stumbling block seems the need to run Apache as vpopmail user. I have not investigated deep enough, but this seems to be one of the main reasons why the extension is somehow dead. In our company we had a discussion on the issue and the prevailing opinion is that we should not waste time with the extension, but write a daemon. This weekend we will experiment with that. Today, searching more in depth on the issue - I found some postings on this list by people who are in favour of daemon. Hi, On the server side I'd suggest either daemon or (simplier one) triggering. By triggering I mean, that applying changes from UI would cause a creation of special trigger file with some instructions for a cron job started every minute. In other project we widely use triggering for publishing data from staging CMS to live one. Besides we crate new virtual hosts etc using same way. Triggering could only do things tha require running dedicated to vpopmail programs that need to have an RW access to ~vpopmail/ The rest could be done at the level of PHP extension as it only requires MySQL access. Ok, I know there are other auth modules that MySQL but AFAIK the latter is most widespreaded. On the other hand, a daemon would give an opprotunity to have a centralized management since many vpopmailinstallations could be managed from one client. That I'd like also since I got many vpopmails installed on my customers servers. Anyway we choose I can give my 0,03EUR to PHP coding :-) Solt
[vchkpw] php vpopmail daemon etc. - developing story
Hello everybody, Sorry for cross posting if you get this message two or three times. This is a milestone message and I will not make it a practice. First, thank you everybody who wrote back (all in the CC:). Your comments were great and lead to much better visibility in the situation php vpopmail. In this e-mail I make a summary of the situation and propose a direction. Summary --- Our original goal was to write a php/Smarty/PostgreSQL (the db type is optional) open source mail management module that can allow small (or bigger) dedicated servers to offer mail (qmail/vpopmail/ezmlm) services including billing with super user/domain administrator/mail account owner interfaces that can be used as stand alone or integrated easily in other applications. It is mean to fill in the gap in this technology niche (php/Smarty). qmailadmin does a good job, but does not give tools to the php community - especially to be built into other systems or expanded. More about the project here - http://sourceforge.net/projects/vs-mail-manager/ (the project is very young) However, we hit a bottleneck. The bottleneck -- After we researched into the matter we found the bottleneck - the php vpopmail communication. The current php vpopmail extension is half dead for a number of reasons, one of the mail - the security issues - Apache must run as the vpopmail user in order for this to work. Looking for solution As we do not produce 'private' solutions - we tried to spark a community process on the matter. We talked to more than 20 people and on the two main lists - vpopmail and PECL. We talked to the current php vpopmail extension maintainer James Cox, to one of the original authors Boian Bonev and to one of the current active developers Rick Widmer. We have not escalated the issue to the vpopmail and php maintainers so far. May be this should happen at some point. Our goal is to try to produce a simple and easy to use community supported solution. So far the conclusion is that the interest in the vpopmail extension is far from encouraging. It is used here and there - but all people who use it acknowledge that this is a 'strange' thing. So the answer seems not to be there. Broad series of brainstorming lead to the idea that the solution might be rather in direction of a daemon rather than php extension. This idea was supported by more than ten people from all those who replied. I had a chat with Boian Bonev (one of the original authors of the php vpopmail extension) and he also supports the daemon idea - but he added that it is important to be decided where the daemon will live - in vpopmail, in php or elsewhere (alone). So this is the idea we want to explore now - php vpopmail - daemon or? First code -- Rick Macdougall has written a daemon for somebody and this somebody has agreed to open the source. This might be a starting point. Waiting from Rick to write back with details. Invitation -- In order to avoid fragmented communication I would like to invite everybody interested to join the list vs-mail-manager-daemon on the http://sourceforge.net/projects/vs-mail-manager/ page - we will use this list for temporary initial discussion until we see if there is future in the daemon project. There we can also discuss extension or daemon or triggering (as Marcin Soltysiak suggested) ... After the initial stage we might kill the daemon project or wrap it up and freeze it or develop it - the stage is open. At the end we need clear and simple solution that can be easy to use by the php community. Please, feel free to forward this communication to anybody you think will be interested in the matter. Notice -- I guess I do not need to say it - but I'll say it - we are not forking anything neither trying to split the development of any project. We try to isolate the case in a neutral environment (as it is a cross-project one), solve the conceptual and community problems and see where is its home. Looking forwards to see you there. Please, note that the list was just created so it might take some hours before it is activated. In order not to miss some of you - I will wait with the first posting about 24 hours. Best, Iavor -- CEE Solutions Ltd. is the brand behind very small technologies and very small media www.verysmall.org
Re: [vchkpw] php extension or daemon
Iavor Raytchev wrote: snip interesting request about vpopmail admin server Ok... here is what i do...i take a Python based soap server with https. I use python's facilities to execute all the vpopmail/bin commands from a shell. How insecure is it? Well, if someone broks your webserver, and you are carefull, they will certaintly gain root to the mail server. Advantages of this php extension: Lets build a soap server from php executable from php-cgi. We will need to implement http in php Disadvantages of this php extension Lets build a soap server from php executable from php-cgi. We will need to implement http in php So, maybe if we can find a reputable http server built on php for this kind of thing we can slap soapy (or an xml-rpc lib) on it and we would have a pretty scary box, driveable from any webservice client.
[vchkpw] Re: Blackholing a sender
Hello Devendra, On Friday, April 2, 2004 at 7:26:47 AM you wrote (at least in part): This gives me a clue that perhaps we should be able to do it using qmail-scanner-queue.pl code. Let me try it out. If anyone else too can give some pointer on this angle do let us know. qmail_requeue() seems to be the function that does pass the mail to qmail-queue after qmail-scanner has processed it. So before AV- and spam-check simply check for $sender (or $env_returnpath, or whatever the variable is named at the location you introduce the check) and instead of init_scanners call a the requeue with different recipient ($env_recips or the like). The new recipient should be a local/virtualdomain recipient address that has a blackholed delivery: a dot-qmail file containing only one line: ,- [ .qmail-blackhole ] | # `- HTH -- Best regards Peter Palmreuther All Tagelines are currently busy. Please try again later.
[vchkpw] Encryption
Hello, I am currently working on setting up an extranet site for my company. I would like to import the information from the mysql vpopmail db into the cms's (Content Management System) user database, however the cms db stores passwords like so: 7729ca956c9bdb1ea9e498ebeb57ffda However the passwords in the vpopmail db are stored like so: $1$D065m$p8ZGr5V/L.rnHmYvi1KAu/ So I was wondering if anyone knows of a way that I can: 1. Convert the passwords in the vpopmail database to work with the other database (without making changes to the email system) or 2. Change the way the email system stores its passwords to match the way the cms stores its passwords. The cms uses php. Thanks for the help
[vchkpw] Re: pw_gid flags was: OT: Radius server
Hello Charles, On Friday, April 2, 2004 at 6:21:55 AM you wrote (at least in part): I hope this isn't some kind of bitmasking thing, because that just makes my head spin. That is exactly what it is... So how does one deal with that? Carefully. How does this work? Good. :-) OK, an example: PW_GID is set to 44 (0x2C), that's 0x04 + 0x08 + 0x20, means NO_WEBMAIL, NO_IMAP NO_RELAY. To figure if the user is set to NO_DIALUP check: PW_GID 64 (0x40 for NO_DIALUP): 4464 = 0 0x2C 0x40 = 0 Or in binary notation: 00101100 0100 == = 0x00 == 0 decimal. So this user has not NO_DIALUP set. No imagine a user set to NO_DIALUP, NO_WEBMAIL and NO_RELAY: 0x04 + 0x20 + 0x40 = 0x64 4 + 32 + 64 = 100 (decimal) PW_GID 64 (0x40 for NO_DIALUP): 10064 = 64 (decimal) 0x64 0x40 = 0x40 01100100 0100 == 0100 = 0x40 == 64 decimal. So to see if a flag is set AND operate on PW_GID and FLAG and see if the result is different from zero. As every flag gets a different bit assigned this bit, and only this bit, will be set when you AND operate and this bit was set in PW_GID's value. In cat it is really quite easy to handle and most programming languages should be able to bit-operate with integer values too. So you wouldn't even have to convert PW_GID into a real bitmask, in fact the integer already is one: just use an arbitrary calculator to translate an arbitrary decimal value into binary representation. No translate all the hex values for different flags into binary and you'll see: they all have /exactly/ one bit set to 1. Not more, not less. And this is all about how it works :-) HTH -- Best regards Peter Palmreuther Once a job is fouled up, anything done to improve it only makes it worse.
[vchkpw] Re: Vpopmail, qmailadmin maildrop issue
This was emailed directly to me, but I think it is of importance to the
list. I don't have time to look into it further, but we definitely
need a change. vdelivermail() calls qmail-inject when processing
forwards in a .qmail file, but does not wait for qmail-inject to finish
before exiting.
On Mar 26, 2004, at 9:01 AM, Salvatore Lazzari wrote:
I've a question for you.
State of art:
- maildrop filter mail delivery
- i have some forwards sett'up via qmailadmin
Problem:
Vdelivermail doesn't process .qmail fw file created by qmailadmin
when
called by maildrop
Vdelivermail processes it well when called directly.
I solved it modifing the code in vdelivermail.c:
=if ( inject == 1 ) {
=close(write_fd);
+sleep(2);
=return(0);
=}
Question:
Is there a kind of security/performance related issue to add the
sleep()
call?
Instead of the sleep, vdelivermail should wait for the qmail-inject
process to finish.
Thanks for catching this, it will require a bit of extra coding and
testing to be sure that we're doing things correctly. It should work
something like this (I think).
pid_t pid;
int childstatus;
pid = qmail_inject_open(address);
...
if ( inject == 1 ) {
close(write_fd);
waitpid (pid, childstatus, 0);
/* we should check childstatus here and fail accordingly if
qmail-inject failed */
return (0);
}
Perhaps someone with more experience with forked processes can take a
closer look at this.
--
Tom Collins - [EMAIL PROTECTED]
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] Re: Vpopmail, qmailadmin maildrop issue
On Friday 02 April 2004 12:07 pm, Tom Collins wrote:
This was emailed directly to me, but I think it is of importance to the
list. I don't have time to look into it further, but we definitely
need a change. vdelivermail() calls qmail-inject when processing
forwards in a .qmail file, but does not wait for qmail-inject to finish
before exiting.
On Mar 26, 2004, at 9:01 AM, Salvatore Lazzari wrote:
I've a question for you.
State of art:
- maildrop filter mail delivery
- i have some forwards sett'up via qmailadmin
Problem:
Vdelivermail doesn't process .qmail fw file created by qmailadmin
when
called by maildrop
Vdelivermail processes it well when called directly.
I solved it modifing the code in vdelivermail.c:
=if ( inject == 1 ) {
=close(write_fd);
+sleep(2);
=return(0);
=}
Question:
Is there a kind of security/performance related issue to add the
sleep()
call?
Instead of the sleep, vdelivermail should wait for the qmail-inject
process to finish.
Thanks for catching this, it will require a bit of extra coding and
testing to be sure that we're doing things correctly. It should work
something like this (I think).
pid_t pid;
int childstatus;
pid = qmail_inject_open(address);
...
if ( inject == 1 ) {
close(write_fd);
waitpid (pid, childstatus, 0);
/* we should check childstatus here and fail accordingly if
qmail-inject failed */
return (0);
}
one two continuing
Here is a patch. Tested on my machine and working nicely.
It is also in the cvs version. Basicly the same code as Tom
has above with a return(wait_exitcode(childstatus) instead
of return(0);
--- vpopmail-5.5.1/vdelivermail.c 2004-03-14 12:00:40.0 -0600
+++ vpopmail.new/vdelivermail.c 2004-04-02 12:40:52.0 -0600
@@ -448,8 +448,9 @@
time_t tm;
off_t file_count;
long unsigned pid;
+ long unsigned inject_pid = 0;
+ int child;
int write_fd;
- int inject = 0;
FILE *fs;
char tmp_file[256];
#ifdef SPAMASSASSIN
@@ -589,9 +590,8 @@
char *atpos;
int dtlen;
- qmail_inject_open(address);
+ inject_pid = qmail_inject_open(address);
write_fd = fdm;
- inject = 1;
/* use the DTLINE variable, but skip past the dash in
* [EMAIL PROTECTED]
@@ -729,9 +729,10 @@
}
}
}
-if ( inject == 1 ) {
+if ( inject_pid != 0 ) {
close(write_fd);
-return(0);
+waitpid(inject_pid,child,0);
+return(wait_exitcode(child));
}
/* if we are writing to a Maildir, move it
Re: [vchkpw] php vpopmail daemon etc. - developing story
Hi, Ken Jones wrote: I've been thinking about this and I think the daemon is definitly the way to go. If Rick can't release the code I can write one. I think the protocol could be like this: I found the code and although it is not as pretty as I remember it is available for release. It's in php with a tcpserver front end. It currently lacks user authentication though. From then on we could pass commands like: For admin accounts: vadduser [EMAIL PROTECTED] pass vdeluser [EMAIL PROTECTED] vadddomain domain postmaster-pass vdeldomain domain Very easy to add modules to the server, just add a case statement. I already have server code to handle this kind of daemon in both single threaded and multithreaded modes. Since it's written in php, and uses tcpserver as the socket connector, it should scale quite well. Regards, Rick
Re: [vchkpw] Encryption
Cory Barton wrote: Hello, I am currently working on setting up an extranet site for my company. I would like to import the information from the mysql vpopmail db into the cms's (Content Management System) user database, however the cms db stores passwords like so: 7729ca956c9bdb1ea9e498ebeb57ffda However the passwords in the vpopmail db are stored like so: $1$D065m$p8ZGr5V/L.rnHmYvi1KAu/ So I was wondering if anyone knows of a way that I can: 1. Convert the passwords in the vpopmail database to work with the other database (without making changes to the email system) or 2. Change the way the email system stores its passwords to match the way the cms stores its passwords. The cms uses php. Thanks for the help Well, let me answer this one. The first one is MD5 generated, the second one i believe is general crypt generated. What this means is that you would either need to rewrite the CMS so it accepts crypt'ed passwords, or rewrite vpopmail to instead of crypt use MD5, as there is no way to convert one to the other. X-Istence
Re: [vchkpw] php vpopmail daemon etc. - developing story
On Friday 02 April 2004 1:27 pm, Rick Macdougall wrote: Hi, Ken Jones wrote: I've been thinking about this and I think the daemon is definitly the way to go. If Rick can't release the code I can write one. I think the protocol could be like this: I found the code and although it is not as pretty as I remember it is available for release. It's in php with a tcpserver front end. It currently lacks user authentication though. From then on we could pass commands like: For admin accounts: vadduser [EMAIL PROTECTED] pass vdeluser [EMAIL PROTECTED] vadddomain domain postmaster-pass vdeldomain domain Very easy to add modules to the server, just add a case statement. I already have server code to handle this kind of daemon in both single threaded and multithreaded modes. Since it's written in php, and uses tcpserver as the socket connector, it should scale quite well. That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. Ken
Re: [vchkpw] php vpopmail daemon etc. - developing story
Rick Macdougall wrote: Hi, Ken Jones wrote: I've been thinking about this and I think the daemon is definitly the way to go. If Rick can't release the code I can write one. I think the protocol could be like this: I found the code and although it is not as pretty as I remember it is available for release. It's in php with a tcpserver front end. It currently lacks user authentication though. From then on we could pass commands like: For admin accounts: vadduser [EMAIL PROTECTED] pass vdeluser [EMAIL PROTECTED] vadddomain domain postmaster-pass vdeldomain domain Very easy to add modules to the server, just add a case statement. I already have server code to handle this kind of daemon in both single threaded and multithreaded modes. Since it's written in php, and uses tcpserver as the socket connector, it should scale quite well. Regards, Rick Now what i want to ask is, could we write it efficiently. As i would want to deploy this over multiple servers, and having everything written out in normal ASCII would be a waste of bandwidth (all bytes count), i think that we should make it binary communication, just like DJB is trying to do with IM2000. just my 0.02$. X-Istence
Re: [vchkpw] php vpopmail daemon etc. - developing story
Ken Jones wrote: I've been thinking about this and I think the daemon is definitly the way to go. If Rick can't release the code I can write one. I think the protocol could be like this: I found the code and although it is not as pretty as I remember it is available for release. It's in php with a tcpserver front end. It currently lacks user authentication though. From then on we could pass commands like: For admin accounts: vadduser [EMAIL PROTECTED] pass vdeluser [EMAIL PROTECTED] vadddomain domain postmaster-pass vdeldomain domain Very easy to add modules to the server, just add a case statement. I already have server code to handle this kind of daemon in both single threaded and multithreaded modes. Since it's written in php, and uses tcpserver as the socket connector, it should scale quite well. How about security? If we got it secures by SSL we coiuld use it on multiple servers from one console. Rick, could you post a URL to the code? That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. That woudl be the best way. However, then we'd need a PHP API to use in web-apps Solt
Re: [vchkpw] php vpopmail daemon etc. - developing story
Marcin Soltysiak wrote: Ken Jones wrote: I've been thinking about this and I think the daemon is definitly the way to go. If Rick can't release the code I can write one. I think the protocol could be like this: I found the code and although it is not as pretty as I remember it is available for release. It's in php with a tcpserver front end. It currently lacks user authentication though. From then on we could pass commands like: For admin accounts: vadduser [EMAIL PROTECTED] pass vdeluser [EMAIL PROTECTED] vadddomain domain postmaster-pass vdeldomain domain Very easy to add modules to the server, just add a case statement. I already have server code to handle this kind of daemon in both single threaded and multithreaded modes. Since it's written in php, and uses tcpserver as the socket connector, it should scale quite well. How about security? If we got it secures by SSL we coiuld use it on multiple servers from one console. Rick, could you post a URL to the code? That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. That woudl be the best way. However, then we'd need a PHP API to use in web-apps Solt why? We could talk to it using normal sockets. I dont see why it would require a special API to talk to a normal deamon on a TCP/IP. Even Unix sockets. X-Istence
Re: [vchkpw] php vpopmail daemon etc. - developing story
On Friday 02 April 2004 2:15 pm, Marcin Soltysiak wrote: snip How about security? If we got it secures by SSL we coiuld use it on multiple servers from one console. Rick, could you post a URL to the code? I was talking this over with Jeremy and he recommended running it under tcpserver. So we could run it over ssl with the ssl patch to tcpserver. That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. That woudl be the best way. However, then we'd need a PHP API to use in web-apps Yep, a php module api to talk to the daemon. Apparently that is what the vmailmgr daemon has. Solt
Re: [vchkpw] php vpopmail daemon etc. - developing story
Ken Jones wrote: On Friday 02 April 2004 1:27 pm, Rick Macdougall wrote: That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. Fine by me, although I'd prefer a C daemon myself, I do find php easier to read and to debug. Regards, Rick
Re: [vchkpw] php vpopmail daemon etc. - developing story
Hi, Ken Jones wrote: On Friday 02 April 2004 2:15 pm, Marcin Soltysiak wrote: I was talking this over with Jeremy and he recommended running it under tcpserver. So we could run it over ssl with the ssl patch to tcpserver. Yup, that's what we were doing. It was originally written to handle requests from a Delphi written tool running on a windows machine to manage a firewall/web/mail server. Yep, a php module api to talk to the daemon. Apparently that is what the vmailmgr daemon has. Written in C and calling the vpopmail API's directly is a much better solution than running my php daemon and calling vadduser, vadddomain etc. Regards, Rick
Re: [vchkpw] php vpopmail daemon etc. - developing story
That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. That woudl be the best way. However, then we'd need a PHP API to use in web-apps Solt why? We could talk to it using normal sockets. I dont see why it would require a special API to talk to a normal deamon on a TCP/IP. Even Unix sockets. Yeah, but why waste time and efficiency? Currently I am involved in Midgard CMD project and at the very begining we choosed ows PHP API as well as DB layer and we gained a boost that lets our CMS run on heavily loaded sites. I'd suggest a vpopmail PHP extension with deamon communication layer. So that operations would be performed on lower level and would be free from lazy programmer faults. Most of PHP apps are non-efficient because of bad implementation of basic procedures like SQL calls, file handling etc. Solt
RE: [vchkpw] php vpopmail daemon etc. - developing story
Hello everybody, As it seems that the daemon idea prevails - what about a 'home' for the daemon? When I spoke to Boian Bonev (one of the authors of the php vpopmail extension) he was absolutely for the daemon idea, but he said that it is very important to decide about its home - Is it going to be somewhere around vpopmail or somewhere around php or somewhere around itself. In certain way it somehow belongs to all these places. As in addition to a home - it will need also a group of people who believe in it - the place where it lives should be easily accessible. Would be best to open a Sourceforge.net project and open a wiki for an easy white board? Iavor
Re: [vchkpw] php vpopmail daemon etc. - developing story
On Friday 02 April 2004 2:32 pm, Iavor Raytchev wrote: Hello everybody, As it seems that the daemon idea prevails - what about a 'home' for the daemon? When I spoke to Boian Bonev (one of the authors of the php vpopmail extension) he was absolutely for the daemon idea, but he said that it is very important to decide about its home - Is it going to be somewhere around vpopmail or somewhere around php or somewhere around itself. In certain way it somehow belongs to all these places. As in addition to a home - it will need also a group of people who believe in it - the place where it lives should be easily accessible. Would be best to open a Sourceforge.net project and open a wiki for an easy white board? Iavor I'd like to keep it in the vpopmail project. The daemon could be part of the regular code and the php client module could be part of contrib? I really like the idea of a wiki, too bad we don't have one for vpopmail. Ken
RE: [vchkpw] php vpopmail daemon etc. - developing story
[snip] Ken Jones wrote: That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. [snip] I would also vote for that approach. However we should not forget that this is a php gate into vpopmail and it should be 'as easy as php' to use - otherwise it will not get popularity.
RE: [vchkpw] php vpopmail daemon etc. - developing story
[snip] Marcin Soltysiak: Ken: That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. That woudl be the best way. However, then we'd need a PHP API to use in web-apps [snip] Ken, actually how do you imagine php to talk to the daemon?
RE: [vchkpw] php vpopmail daemon etc. - developing story
[snip] X-Istence: why? We could talk to it using normal sockets. I dont see why it would require a special API to talk to a normal deamon on a TCP/IP. Even Unix sockets. [snip] I heard this idea several times and I think I like it.
Re: [vchkpw] php vpopmail daemon etc. - developing story
I dont think implementing an independent tcp transport (even if its a very simple protocol) is a good idea nowdays. I would do it in a soap or xmlrpc wrappers, over an already well made, very lean, http server library. So then the clients could be made in any language without having to implement a client for the strange protocol we would be implementing. I dont think speed or network load is an issue here. I mean, i dont see deployments where a bit of latency in changing passwords, adding users...etc. would be an issue. If you have a 30 million users mailfarm, then your bw and iron is having a hard time in smtp or imap, really, a bit of extra traffic in thease kinds of transactions is not important.
Re: [vchkpw] php vpopmail daemon etc. - developing story
Ken Jones wrote: I'd like to keep it in the vpopmail project. The daemon could be part of the regular code and the php client module could be part of contrib? I really like the idea of a wiki, too bad we don't have one for vpopmail. Hi, My only problem with that solution is that I wouldn't want to see the daemon and related php client so closely tied to vpopmail that releases have to be based on releases of vpopmail itself. I think if it does stay in the vpopmail area of sourceforge (or else where) that it should be it's own separate downloadable package and not something that you have to download vpopmail to get. Just my $0.02 Regards, Rick
Re: [vchkpw] php vpopmail daemon etc. - developing story
That woudl be the best way. However, then we'd need a PHP API to use in web-apps [snip] Ken, actually how do you imagine php to talk to the daemon? With XML-RPC or SOAP!
RE: [vchkpw] php vpopmail daemon etc. - developing story
[snip] Ken Jones On Friday 02 April 2004 2:32 pm, Iavor Raytchev wrote: Would be best to open a Sourceforge.net project and open a wiki for an easy white board? I'd like to keep it in the vpopmail project. The daemon could be part of the regular code and the php client module could be part of contrib? I really like the idea of a wiki, too bad we don't have one for vpopmail. [snip] OK - in the vpopmail project it seems best to me. Only you have to promise to be serious about it :) A wiki - we can use this one - http://www.verysmall.org/vpopmail/ - I did it for the project. If you have better idea - we can move it under another sub-folder/domain. We host for example www.pgaccess.org (that had similar revival about 2-3 years ago). I am going to move my staff (the very small mail manager) form there to another location.
Re: [vchkpw] Encryption
Thank you. X-Istence wrote: Cory Barton wrote: Hello, I am currently working on setting up an extranet site for my company. I would like to import the information from the mysql vpopmail db into the cms's (Content Management System) user database, however the cms db stores passwords like so: 7729ca956c9bdb1ea9e498ebeb57ffda However the passwords in the vpopmail db are stored like so: $1$D065m$p8ZGr5V/L.rnHmYvi1KAu/ So I was wondering if anyone knows of a way that I can: 1. Convert the passwords in the vpopmail database to work with the other database (without making changes to the email system) or 2. Change the way the email system stores its passwords to match the way the cms stores its passwords. The cms uses php. Thanks for the help Well, let me answer this one. The first one is MD5 generated, the second one i believe is general crypt generated. What this means is that you would either need to rewrite the CMS so it accepts crypt'ed passwords, or rewrite vpopmail to instead of crypt use MD5, as there is no way to convert one to the other. X-Istence
RE: [vchkpw] php vpopmail daemon etc. - developing story
[snip] Rick Macdougall: Ken Jones wrote: I'd like to keep it in the vpopmail project. The daemon could be part of the regular code and the php client module could be part of contrib? I really like the idea of a wiki, too bad we don't have one for vpopmail. Hi, My only problem with that solution is that I wouldn't want to see the daemon and related php client so closely tied to vpopmail that releases have to be based on releases of vpopmail itself. I think if it does stay in the vpopmail area of sourceforge (or else where) that it should be it's own separate downloadable package and not something that you have to download vpopmail to get. [snip] Yes, that's what I mean when I told Ken that they must be very serious about it. We had similar siutaiton when we revived pgaccess (www.pgaccess.org) 3 years ago (a Tcl/Tk GUI for PostgreSQL). The PostgreSQL team wanted it closer and we wanted it not so close. At the end they must focus on PostgreSQL and we - on pgaccess. If the main project gets into a difficult time (change of maintainers, etc.) - and if the sub-project is too close - it can suffer. At the end - the spirit of qmail is modularity - why shouldn't we continue it? I am not against - I just think we should be aware of the dangers of the thing getting stuck and killing a lot of investment in infrastructure and code that uses it.
Re: [vchkpw] OT: Radius server
Charles Sprickman wrote: On Wed, 31 Mar 2004, Doug Clements wrote: Radiator (open.com.au) rules. You can do virtually anything, including custom SQL queries. I know, I used to use it. Best radius server ever. But it costs $$ that we don't have. A good start to getting something else working would be if someone could explain how the pw_gid values work and what the numbers represent; gnu-radius has some rewrite rules that may allow me to somewhat alter (in a sneaky and hackish way) my queries based on which NAS the request comes from. But so far I'm not finding any information on how to determine what particular numeric values in the pw_gid field mean... vpopmail.h lines 86-100
Re: [vchkpw] php vpopmail daemon etc. - developing story
X-Istence wrote: why? We could talk to it using normal sockets. I dont see why it would require a special API to talk to a normal deamon on a TCP/IP. Even Unix sockets. Here is my $0.02 on how to best implement a daemon... The daemon is in C [1] and runs under tcpserver. It opens a unix socket on the local machine, and/or a TCP port if we want to get into off machine access to the mail server. The deamon links to the vpopmail library, and makes calls to the library. The daemon MUST require all connections to be authenticated, preferably against the vpopmail user base. There isn't much use in a binary interface to the daemon, because almost all of the data it must pass is already ascii. I think about the only thing you could encode into a binary format is the identifier for which function you want to call. Domain names, user names, alias lines and everything else vpopail deals with is ASCII data, so that is the natural way to communicate with the daemon. I would suggest something like pop3: You send: It replies user rwidmer ok password mypassword ok addomain developersdesk.com mypassowrdok adduser [EMAIL PROTECTED] mypasswordok addalias [EMAIL PROTECTED] ok enter alias addr? [EMAIL PROTECTED]enter alias addr? [EMAIL PROTECTED] enter alias addr? [EMAIL PROTECTED] enter alias addr? [EMAIL PROTECTED] enter alias addr? [EMAIL PROTECTED]enter alias addr? ok list developersdesk.com minimaillist alias postmasteruser rick user ok list [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ok list inter7.com err - no such domain list [EMAIL PROTECTED] err - no such domain list [EMAIL PROTECTED] err - no such address exit ok Make it something that is conversational enough to telnet in to test the daemon without having to code both sides of the interface, and make sure . This syntax may not be exactly what it ends up using, but it should be close. Then you write a tidy little library in PHP, that uses sockets to open the daemon, and provides functions that make it look like you are accessing the vpopmail extension directly. I was hoping to report the list on sourceforge was up and running, but it seems to be taking a long time for my messages to be accepted. Even though I have already received the welcome message. Riok [1] Maybe it is my age showing, but it seems to me you want daemons lean and mean, and having to load the whole PHP interpreter just doesn't do it for me. (This is from someone who usually prefers to do everything in PHP.)
[vchkpw] indirect reasons for 5.7.1?
This is regarding qmail + vpopmail 5.3.12 running under tcpserver, on FreeBSD 4.6.1. My server was bouncing *everything* with 5.7.1, that is including stuff that should have been delivered to domains hosted by my server. I panicked and just rebooted my server (because reboot is very quick and it is the most reliable way to fix a bunch of things quickly without having to take time to identify a problem), and thus lost some of the evidence. But I am suspicious based on previous expeirences that if a certain process dies that some process starts responding to all smtp requests with 5.7.1. Or is there any other obvious reason why qmail might go into a permanent 5.7.1 mode? Thanks for any thoughts, and sorry to be so lacking in info. I did do a quick ps when I discovered the problem and I'm pretty sure that the tcpserver process involving qmail-smtpd was probably not there. I only remembered it should have been there after rebooting and doing another ps. Is there some default mode for smtp connections that takes over under such a circumstance? Thanks, Kurt Bigler
Re: [vchkpw] php vpopmail daemon etc. - developing story
On Friday 02 April 2004 08:21 pm, Ken Jones wrote: How about security? If we got it secures by SSL we coiuld use it on multiple servers from one console. Rick, could you post a URL to the code? I was talking this over with Jeremy and he recommended running it under tcpserver. So we could run it over ssl with the ssl patch to tcpserver. or just using ucspi-ssl (http://www.superscript.com/ucspi-ssl/intro.html -- hopefully that's the correct url, they appear to be down at the moment) That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. That woudl be the best way. However, then we'd need a PHP API to use in web-apps Yep, a php module api to talk to the daemon. Apparently that is what the vmailmgr daemon has. yes, vmailmgr has vmail.inc included with it that you can use with php programs to talk to the daemon. -Jeremy -- Jeremy Kitchen Systems Administrator [EMAIL PROTECTED] Kitchen @ #qmail on EFNet - Join the party! . Inter7 Internet Technologies, Inc. www.inter7.com 866.528.3530 toll free 847.492.0470 int'l 847.492.0632 fax GNUPG key ID: 93BDD6CE
Re: [vchkpw] php vpopmail daemon etc. - developing story
The daemon MUST require all connections to be authenticated, preferably against the vpopmail user base. user rwidmer ok password mypassword ok This is only slightly related to Rick's comments (which I think are very good by the way), but when he says against the vpopmail user base exactly what user base is he referring to? In his example, where is the rwidmer user information stored? Is this something related to how qmailadmin (which I know the least about re: vpopmail) does authentication? Thanks, Paul -- Paul Oehler NEXCESS.NET Internet Solutions http://nexcess.net 304 1/2 S. State St. Ann Arbor, MI 48104 1.866.NEXCESS
Re: [vchkpw] php vpopmail daemon etc. - developing story
Rick Widmer wrote: snip [1] Maybe it is my age showing, but it seems to me you want daemons lean and mean, and having to load the whole PHP interpreter just doesn't do it for me. (This is from someone who usually prefers to do everything in PHP.) I agree. X-istence
Re: [vchkpw] php vpopmail daemon etc. - developing story
Rick Macdougall wrote: Ken Jones wrote: On Friday 02 April 2004 1:27 pm, Rick Macdougall wrote: That sounds good. Of course as a C programmer I'd prefer it be written in C linking in the vpopmail API. I'd like to take a swing at building it in C over the weekend. vmailmgr has something like this already, including a php module to talk to it. Perhaps we can re-use some of that code. Fine by me, although I'd prefer a C daemon myself, I do find php easier to read and to debug. Regards, Rick C is smaller, and leaner. Id rather have it in C than PHP, running spamassassin allready eats server resources cause of perl, lets not get a PHP deamon written that needs PHP to run. X-istence
Re: [vchkpw] php vpopmail daemon etc. - developing story
Ken Jones wrote: On Friday 02 April 2004 2:32 pm, Iavor Raytchev wrote: Hello everybody, As it seems that the daemon idea prevails - what about a 'home' for the daemon? When I spoke to Boian Bonev (one of the authors of the php vpopmail extension) he was absolutely for the daemon idea, but he said that it is very important to decide about its home - Is it going to be somewhere around vpopmail or somewhere around php or somewhere around itself. In certain way it somehow belongs to all these places. As in addition to a home - it will need also a group of people who believe in it - the place where it lives should be easily accessible. Would be best to open a Sourceforge.net project and open a wiki for an easy white board? Iavor I'd like to keep it in the vpopmail project. The daemon could be part of the regular code and the php client module could be part of contrib? I really like the idea of a wiki, too bad we don't have one for vpopmail. Ken This would cause problems. Then it would not be in PHP releases, and only in the contrib directory, thus making it still an remote option and not likely a widely adopted one. X-Istence
Re: [vchkpw] indirect reasons for 5.7.1?
Kurt Bigler wrote: This is regarding qmail + vpopmail 5.3.12 running under tcpserver, on FreeBSD 4.6.1. My server was bouncing *everything* with 5.7.1, that is including stuff that should have been delivered to domains hosted by my server. 5.7.1 can mean a domain is not on your rcpthosts list. /var/control/rcpthosts I panicked and just rebooted my server (because reboot is very quick and it is the most reliable way to fix a bunch of things quickly without having to take time to identify a problem), and thus lost some of the evidence. Reboot should be your last thing to try, what if it was more serious and the box never came back up? But I am suspicious based on previous expeirences that if a certain process dies that some process starts responding to all smtp requests with 5.7.1. Or is there any other obvious reason why qmail might go into a permanent 5.7.1 mode? Check rcpthosts, restart qmail-smtpd, only things that would affect a 5.7.1. Which means permanent error, or permanent not allowed. Thanks for any thoughts, and sorry to be so lacking in info. I did do a quick ps when I discovered the problem and I'm pretty sure that the tcpserver process involving qmail-smtpd was probably not there. I only remembered it should have been there after rebooting and doing another ps. Is there some default mode for smtp connections that takes over under such a circumstance? Well, if your SMTP service was not there, your server could not be accepting mail, thus there would be nothing to bounce. Thus it would not be able to create 5.7.1 bounces in the first place. Thanks, Kurt Bigler
Re: [vchkpw] indirect reasons for 5.7.1?
on 4/2/04 1:53 PM, X-Istence [EMAIL PROTECTED] wrote: Kurt Bigler wrote: This is regarding qmail + vpopmail 5.3.12 running under tcpserver, on FreeBSD 4.6.1. My server was bouncing *everything* with 5.7.1, that is including stuff that should have been delivered to domains hosted by my server. 5.7.1 can mean a domain is not on your rcpthosts list. /var/control/rcpthosts No, rcpthosts was fine (or rebooting would have been vanishingly unlikely to fix it). I panicked and just rebooted my server (because reboot is very quick and it is the most reliable way to fix a bunch of things quickly without having to take time to identify a problem), and thus lost some of the evidence. Reboot should be your last thing to try, what if it was more serious and the box never came back up? Everything else *seemed* fine. Reboot has proven very reliable. It is a virtual server with the parent (?) server monitored/maintained by my provider, which makes a bit of a difference. Every moment lost not identifying the problem is a liability, so I used reboot to compensate for my lack of ready knowledge. In this particular case it turned out to be a good thing, but I hope to work now to reduce the chance of it happening again. But I am suspicious based on previous expeirences that if a certain process dies that some process starts responding to all smtp requests with 5.7.1. Or is there any other obvious reason why qmail might go into a permanent 5.7.1 mode? Check rcpthosts, restart qmail-smtpd, only things that would affect a 5.7.1. Which means permanent error, or permanent not allowed. Yes, I am thinking of having the server monitor and restart these things automatically. I know some people don't like that approach, but I don't have 24/7 staff coverage (just me who sleeps long hours). Thanks for any thoughts, and sorry to be so lacking in info. I did do a quick ps when I discovered the problem and I'm pretty sure that the tcpserver process involving qmail-smtpd was probably not there. I only remembered it should have been there after rebooting and doing another ps. Is there some default mode for smtp connections that takes over under such a circumstance? Well, if your SMTP service was not there, your server could not be accepting mail, thus there would be nothing to bounce. Thus it would not be able to create 5.7.1 bounces in the first place. I was wondering whether tcpserver on its own would start handling them if qmail-smtpd disappeared. It seems to me tcpserver can do quite a few things on its own. It would be very unfriendly if it were to do 5.7.1's rather than indicating a temporary failure though. Thanks, Kurt Bigler
Re: [vchkpw] indirect reasons for 5.7.1?
on 4/2/04 2:05 PM, Kurt Bigler [EMAIL PROTECTED] wrote: on 4/2/04 1:53 PM, X-Istence [EMAIL PROTECTED] wrote: Kurt Bigler wrote: Thanks for any thoughts, and sorry to be so lacking in info. I did do a quick ps when I discovered the problem and I'm pretty sure that the tcpserver process involving qmail-smtpd was probably not there. I only remembered it should have been there after rebooting and doing another ps. Is there some default mode for smtp connections that takes over under such a circumstance? Well, if your SMTP service was not there, your server could not be accepting mail, thus there would be nothing to bounce. Thus it would not be able to create 5.7.1 bounces in the first place. I was wondering whether tcpserver on its own would start handling them if qmail-smtpd disappeared. It seems to me tcpserver can do quite a few things on its own. It would be very unfriendly if it were to do 5.7.1's rather than indicating a temporary failure though. Oops sorry, I was thinking of inetd when I said tcpserver above. Maybe inetd provides some sort of default coverage for a port that no other process is watching? -Kurt Thanks, Kurt Bigler
Re: [vchkpw] php vpopmail daemon etc. - developing story
X-Istence wrote: I'd like to keep it in the vpopmail project. The daemon could be part of the regular code and the php client module could be part of contrib? Ken This would cause problems. Then it would not be in PHP releases, and only in the contrib directory, thus making it still an remote option and not likely a widely adopted one. I don't see much value in being part of the PHP release. You might convert a few people who need to pick a new mail server, but I suspect _most_ PHP developers aren't allowed to touch the mail server. A place in the vpopmail contrib is more likely to be found by the people who are deploying vopomail. We need to make sure contrib is mentioned in INSTALL and/or README! I'm embarrassed to say how recently I found out about it... Rick
Re: [vchkpw] php vpopmail daemon etc. - developing story
Paul Oehler wrote: The daemon MUST require all connections to be authenticated, preferably against the vpopmail user base. user rwidmer ok password mypassword ok This is only slightly related to Rick's comments (which I think are very good by the way), but when he says against the vpopmail user base exactly what user base is he referring to? In his example, where is the rwidmer user information stored? Is this something related to how qmailadmin (which I know the least about re: vpopmail) does authentication? By 'against the vpopmail user base', I mean the mail users in vpopmail. There should also be a group of users that don't get email, but have rights to every domain on the system. This could be accomplished by having a 'domain' that is not legal, like 'system.admins'. I am pretty sure vpopmail will allow you to create such a domain, but DNS won't allow it to receive mail. A proper system admin login would look like this: user [EMAIL PROTECTED] password mypassword Any user within vopomail should be able to login and do actions appropriate to assigned capabilities. Other than the system.admins domain the rules are already built into vpopmail. If you are a member of the system.admins domain, you have the right to create and delete domains, and full access to manage any domain on the system. It might be good to create system.admins domain and [EMAIL PROTECTED] user when the vpopmail daemon is installed. This user would be similar to root in the operating system. You could then use the daemon to create the rest of your mail system. Rick
Re: [vchkpw] php vpopmail daemon etc. - developing story
The daemon MUST require all connections to be authenticated, preferably against the vpopmail user base. user rwidmer ok password mypassword ok This is only slightly related to Rick's comments (which I think are very good by the way), but when he says against the vpopmail user base exactly what user base is he referring to? In his example, where is the rwidmer user information stored? Is this something related to how qmailadmin (which I know the least about re: vpopmail) does authentication? Well..does it matter? Daemon can do vchkpw so user DB can by any through vpopomail API call. Solt
Re: [vchkpw] php vpopmail daemon etc. - developing story
The daemon MUST require all connections to be authenticated, preferably against the vpopmail user base. user rwidmer ok password mypassword ok This is only slightly related to Rick's comments (which I think are very good by the way), but when he says against the vpopmail user base exactly what user base is he referring to? In his example, where is the rwidmer user information stored? Is this something related to how qmailadmin (which I know the least about re: vpopmail) does authentication? By 'against the vpopmail user base', I mean the mail users in vpopmail. There should also be a group of users that don't get email, but have rights to every domain on the system. This could be accomplished by having a 'domain' that is not legal, like 'system.admins'. I am pretty sure vpopmail will allow you to create such a domain, but DNS won't allow it to receive mail. A proper system admin login would look like this: user [EMAIL PROTECTED] password mypassword +1 That is very good idea. Any user within vopomail should be able to login and do actions appropriate to assigned capabilities. Other than the system.admins domain the rules are already built into vpopmail. If you are a member of the system.admins domain, you have the right to create and delete domains, and full access to manage any domain on the system. It might be good to create system.admins domain and [EMAIL PROTECTED] user when the vpopmail daemon is installed. This user would be similar to root in the operating system. You could then use the daemon to create the rest of your mail system. A step forward: using pw_gid [EMAIL PROTECTED] could have different level of access to system administration. Solt
Re: [vchkpw] php vpopmail daemon etc. - developing story
Iavor Raytchev wrote: [snip] X-Istence wrote: Now what i want to ask is, could we write it efficiently. As i would want to deploy this over multiple servers, and having everything written out in normal ASCII would be a waste of bandwidth (all bytes count), i think that we should make it binary communication, just like DJB is trying to do with IM2000. [snip] We must write it efficiently and with all (as many as possible) aspects in mind. If we create the next thing that 'works, but...' - it would be not very useful. Efficiency is good, but you lose a lot of debugging ease when you go to binary protocols. How many times have you used telnet to debug pop and smtp sessions? Converting to binary communications does not save that much bandwidth at all, and for a large price of complexity. --Doug
Re: [vchkpw] php vpopmail daemon etc. - developing story
Alejandro Borges wrote: That woudl be the best way. However, then we'd need a PHP API to use in web-apps [snip] Ken, actually how do you imagine php to talk to the daemon? With XML-RPC or SOAP! Or super-simple: over sockets using tcpserver. tcpserver is built for making these kinds of jobs easy. --Doug
Re: [vchkpw] php vpopmail daemon etc. - developing story
Paul Oehler wrote: There is a function that provides authentication: vpasswd( user, domain, password, is_apop ) that returns the user's password info if valid, or 0. The problem is, if you can execute the vpopmail library at all, you can execute every function within it. This is how QmailAdmin checks to see what you are allowed to do when you login. Thanks for both of your responses Rick, very helpful. Could you, or someone, point me toward where I can read about what these already built in rules are, and how they're defined and stored in the database? I'm assuming this would be pw_gid documentation, or code comments, or something similar? I am afraid about the only way to do it now is to spend a week or so studying QmailAdmin and Vpopmail source code. I haven't seen much of this written down anywhere. There is a list on the wiki of the vpopmail functions I found that QmailAdmin uses. The parm order has been changed in this list, which is the PHP side of my vpopmail extension. I think it might be a good start as a command list for the daemon. http://www.verysmall.org/vpopmail/index.php?page=php+vpopmail+extension There are some changes required, like having to authenticate before getting access, and adding the funcions for domain maintenance which I left out because I consider it hopeless to attempt them from PHP via an extension. Rick
Re: [vchkpw] New PHP extension
A new update to the vpopmail extension for PHP has been uploaded to http://kimberly.developersdesk.com/ I believe it now supports everything that QmailAdmin uses. Hi Rick, Is your PHP vpopmail extention able to create and manage Forwards, Robots (autoresponders), and mailing lists? I looked through all the source code and it didn't jump out at me, so I thought I'd ask. Thanks, Paul
Re: [vchkpw] how will php talk to the daemon
Iavor Raytchev wrote:
It seems now the next bottleneck is 'how will php talk to the daemon'.
My PHP interface to the daemon would work like this:
example.php
--
?
include( vpopmail.pobj );
# Information for login
$Domain = 'system.admins';
$User = 'rwidmer';
$Pass = 'mypassword';
$vpop = new vpopmail( $Domain, $User, $Pass );
# Information to create accounts
$Domain = 'developersdesk.com';
$User = 'rwidmer';
$Pass = 'mypassword';
$AliasName = ' minimaillist';
$AliasContents = array(
'[EMAIL PROTECTED]',
'[EMAIL PROTECTED]',
'[EMAIL PROTECTED]',
'[EMAIL PROTECTED]',
'[EMAIL PROTECTED]',
);
# Do it...
$vpop-domainAdd( $Domain, $Pass );
$vpop-userAdd( $Domain, $User, $Pass );
$vpop-aliasAdd( $Domain, $AliasName, $AliasContents );
$DomainUsers = $vpop-userList( $Domain );
# DomainUsers is an array containing:
# 'minimaillist' = 'alias',
# 'postmaster' = 'user',
# 'rick' = 'user',
$AliasList - $vpop-aliasList( $Domain, $AliasName );
# AliasList is an array containing:
# '[EMAIL PROTECTED]',
# '[EMAIL PROTECTED]',
# '[EMAIL PROTECTED]',
# '[EMAIL PROTECTED]',
# '[EMAIL PROTECTED]',
#
# Note they are in alpha order now.
$vpop-domainList( 'inter7.com' );
# This is an invalid domain error
$vpop-userList( 'inter7.com', 'kbo' );
# This is an invalid domain error
$vpop-userList( 'developersdesk.com', 'kbo' );
# This is an invalid user error
$vpop-close();
?
--
All of which should result in the same data stream as the 'telnet'
session I posted earlier. We need to add some kind of error handling,
probably return false, and set an error variable in the object which you
query with vpop-error().
Off the top of my head it might look like this... (never even
attempted to compile with PHP, so expect syntax errors... )
vpopmail.pobj
--
class Vpopmail {
var $socket;
var $error;
###
#
# c o n s t r u c t o r
#
function Vpopmail( $Domain, $User, $Password ) {
/* Set the port for our service */
$service_port = '1234';
/* Get the IP address for the target host. */
$address = gethostbyname('localhost');
/* Create a TCP/IP socket. */
$this-socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
if ($this-socket 0) {
$this-error = socket_create() failed: reason: .
socket_strerror($socket) . \n;
return;
}
#echo Attempting to connect to '$address' on port '$service_port'...;
$result = socket_connect($this-socket, $address, $service_port);
if ($result 0) {
$this-error =
socket_connect() failed.\nReason: ($result) .
socket_strerror($result) . \n;
return;
# Send the username
$in = user [EMAIL PROTECTED];
socket_write($this-socket, $in, strlen($in));
$out = socket_read($this-socket, 2048)) {
if( 'ok' != $out ) {
$this-error = Login failed - $Out\n;
socket_close( $this-socket );
unset( $this-socket );
return;
}
# Send the password
$in = pass $Password\n;
socket_write($socket, $in, strlen($in));
$out = socket_read($socket, 2048)) {
if( 'ok' != $out ) {
$this-error = Login failed - $Out\n;
socket_close( $this-socket );
unset( $this-socket );
return;
}
###
#
# f u n c t i o n c l o s e
#
function close() {
echo Closing socket...;
socket_close($this-socket);
}
###
#
# f u n c t i o n domainAdd
#
function domainAdd( $Domain, $Password ) {
# Build the request
$in = adddomain $Domain $Password\n;
# Send the request
socket_write($this-socket, $in, strlen($in));
$out = socket_read($this-socket, 2048)) {
if( 'ok' != $out ) {
$this-error = $Out;
return false
}
else {
$this-Error = '';
return true;
}
}
###
#
# f u n c t i o n userAdd
#
function userAdd( $Domain, $User, $Password ) {
# Build the request
$in = adduser $Domain $User $Password\n;
# Send the request
socket_write($this-socket, $in, strlen($in));
$out = socket_read($this-socket, 2048)) {
if( 'ok' != $out ) {
$this-error = $Out;
return false
}
else {
$this-Error = '';
return true;
}
}
###
#
# f u n c t i o n aliasAdd
#
function aliasAdd( $Domain, $AliasName, $AliasList ) {
# Build the request
$in = addalias $Domain $User $Password\n;
# Send the request
socket_write($this-socket, $in, strlen($in));
$out = socket_read($this-socket, 2048)) {
if( 'enter alias addr?' == $out ) {
while( list( , $Alias ) = each( $AliasList )) {
$in = $Alias\n;
socket_write($this-socket, $in, strlen($in));
$out = socket_read($this-socket, 2048));
if( 'enter alias addr?' != $out )
Re: [vchkpw] indirect reasons for 5.7.1? - behavior confirmed
on 4/2/04 1:15 PM, Kurt Bigler [EMAIL PROTECTED] wrote: This is regarding qmail + vpopmail 5.3.12 running under tcpserver, on FreeBSD 4.6.1. My server was bouncing *everything* with 5.7.1, that is including stuff that should have been delivered to domains hosted by my server. I panicked and just rebooted my server (because reboot is very quick and it is the most reliable way to fix a bunch of things quickly without having to take time to identify a problem), and thus lost some of the evidence. But I am suspicious based on previous expeirences that if a certain process dies that some process starts responding to all smtp requests with 5.7.1. Or is there any other obvious reason why qmail might go into a permanent 5.7.1 mode? Thanks for any thoughts, and sorry to be so lacking in info. I did do a quick ps when I discovered the problem and I'm pretty sure that the tcpserver process involving qmail-smtpd was probably not there. I only remembered it should have been there after rebooting and doing another ps. Is there some default mode for smtp connections that takes over under such a circumstance? Thanks, Kurt Bigler I confirmed that if I kill this process (line from ps output): qmaild86243 0.0 0.1 904 360 ?? SNJ 3:05PM 0:00.09 tcpserver -v -H -R -lvps.breathsense.com -x /var/vpopmail/etc/tcp.smtp.cdb -c200 -u1003 -g1001 0 25 fixcrio /var/qmail/bin/qmail-smtpd that incoming SMTP attempts are greeted by a 5.7.1 error. Does anyone understand how this happens? Thanks, Kurt Bigler
Re: [vchkpw] indirect reasons for 5.7.1? - behavior confirmed
Kurt Bigler wrote: snip I confirmed that if I kill this process (line from ps output): qmaild86243 0.0 0.1 904 360 ?? SNJ 3:05PM 0:00.09 tcpserver -v -H -R -lvps.breathsense.com -x /var/vpopmail/etc/tcp.smtp.cdb -c200 -u1003 -g1001 0 25 fixcrio /var/qmail/bin/qmail-smtpd that incoming SMTP attempts are greeted by a 5.7.1 error. Does anyone understand how this happens? Thanks, Kurt Bigler Well, considering that is your SMTP service, it looks like another server on the same system is taking over, or you configured something wrong. since its freebsd, take a look at: sockstat -4, and look for port 25 and what process has it in use if you kill that process you mentioned. X-Istence
Re: [vchkpw] php vpopmail daemon etc. - developing story
Doug Clements wrote: Iavor Raytchev wrote: [snip] X-Istence wrote: Now what i want to ask is, could we write it efficiently. As i would want to deploy this over multiple servers, and having everything written out in normal ASCII would be a waste of bandwidth (all bytes count), i think that we should make it binary communication, just like DJB is trying to do with IM2000. [snip] We must write it efficiently and with all (as many as possible) aspects in mind. If we create the next thing that 'works, but...' - it would be not very useful. Efficiency is good, but you lose a lot of debugging ease when you go to binary protocols. How many times have you used telnet to debug pop and smtp sessions? Converting to binary communications does not save that much bandwidth at all, and for a large price of complexity. --Doug I have written apps to test certain stuff for me. Telnet on windows at the time was horrible, and would not work for what i wanted. But good point. X-Istence
[vchkpw] Server Farm..
I am in the process of migrating our qmail/vpopmail/webmail box to a server farm (Using ServerIron for Load Balancing) I have decided to log everything to a central log server (To simplify support and generation of stats), and came across the following: The following describes how to log to remote host using multilog and tcpclient: http://smarden.org/socklog/network.html Has anyone used the above - Or has comments suggestions on an alternative? I was also thinking of having mysql servers(2 to begin with) in a Mutual Master-Slave relationship (Sitting behind a loadbalancer), and have all qmail/vpopmail/webmail boxes connect to the one (Loadbalanced) IP for authAlthough I have never used Mutual Master-Slave relationship with MySQL, and do not know how effective it is? (If anyone has an alternate solution, please let me know!) We are building the NAS ourselves, and I have had a few reports that NFS was a total bandwidth whore - Therefore was considering running Samba only? Would also appreciate anyones experiences(Difficulty in setting up, scalability etc) with using either LDAP, Kerberos or (maybe?) Radius for auth - As I've heard NIS has security issues? Thanks in advance. Regards, MB
Re: [vchkpw] indirect reasons for 5.7.1? - behavior confirmed
on 4/2/04 6:24 PM, X-Istence [EMAIL PROTECTED] wrote: Kurt Bigler wrote: snip I confirmed that if I kill this process (line from ps output): qmaild86243 0.0 0.1 904 360 ?? SNJ 3:05PM 0:00.09 tcpserver -v -H -R -lvps.breathsense.com -x /var/vpopmail/etc/tcp.smtp.cdb -c200 -u1003 -g1001 0 25 fixcrio /var/qmail/bin/qmail-smtpd that incoming SMTP attempts are greeted by a 5.7.1 error. Does anyone understand how this happens? Thanks, Kurt Bigler Well, considering that is your SMTP service, it looks like another server on the same system is taking over, or you configured something wrong. since its freebsd, take a look at: sockstat -4, and look for port 25 and what process has it in use if you kill that process you mentioned. The plot thickens. sockstat produced no output, apparently a limitation of the virtual server implementation. Inquiring into this, the parent server apparently had default processes answering (stupidly) when virtual server email servers were not running. The administrator fixed this with a quick configuration change, and now everything behaves as expected. Thanks for your help, which lead to the resolution. Still a mystery to me why a default SMTP answerer would respond with 5.7.1. I inquired about that but got no reply yet. -Kurt
