Re: [vchkpw] php vpopmail daemon etc. - developing story
Iavor Raytchev wrote: (on the wiki) * brief idea - combination of extension and daemon I think that should be changed. 'Extension' implies C code that is compiled into PHP. With a daemon there is no need for such drastic measures. 'Module' or 'library' would be better since the whole thing can be done using the PHP sockets interface with no C code outside of the daemon. Rick
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
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] 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
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
> 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? Thanks again, Paul
Re: [vchkpw] php vpopmail daemon etc. - developing story
Paul Oehler wrote: Is this something related to how qmailadmin (which I know the least about re: vpopmail) does authentication? 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. 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? > > 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
> > 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
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
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
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] 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
Rick Widmer wrote: [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
> 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
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
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.)
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] 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] 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
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
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
[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
[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 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.
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
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
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
> >>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
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
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
On Friday 02 April 2004 2:15 pm, Marcin Soltysiak 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. > > 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
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
> > 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
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
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
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] php vpopmail daemon etc. - developing story
On Friday 02 April 2004 7:11 am, Iavor Raytchev wrote: [snip] > 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. [snip] 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: Authentication: open tcp connection or unix socket to deamon send "auth [EMAIL PROTECTED] pass" If not auth line close connection else authenticate user, close connection if invalid passwd From then on we could pass commands like: For admin accounts: vadduser [EMAIL PROTECTED] pass vdeluser [EMAIL PROTECTED] vadddomain domain postmaster-pass vdeldomain domain etc... I already have server code to handle this kind of daemon in both single threaded and multithreaded modes. Ken Jones inter7.com
[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
