Re: [vchkpw] php vpopmail daemon etc. - developing story

2004-04-03 Thread Rick Widmer


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

2004-04-02 Thread Rick Macdougall
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

2004-04-02 Thread Ken Jones
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

2004-04-02 Thread X-Istence
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

2004-04-02 Thread Marcin Soltysiak
  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

2004-04-02 Thread X-Istence
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

2004-04-02 Thread Ken Jones
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

2004-04-02 Thread Rick Macdougall
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

2004-04-02 Thread Rick Macdougall
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

2004-04-02 Thread Marcin Soltysiak
 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

2004-04-02 Thread Iavor Raytchev
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

2004-04-02 Thread Ken Jones
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

2004-04-02 Thread Iavor Raytchev
[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

2004-04-02 Thread Iavor Raytchev
[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

2004-04-02 Thread Iavor Raytchev
[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

2004-04-02 Thread Alejandro Borges
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

2004-04-02 Thread 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.

Just my $0.02

Regards,

Rick



Re: [vchkpw] php vpopmail daemon etc. - developing story

2004-04-02 Thread Alejandro Borges

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

2004-04-02 Thread Iavor Raytchev
[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

2004-04-02 Thread Iavor Raytchev
[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

2004-04-02 Thread Rick Widmer


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

2004-04-02 Thread Jeremy Kitchen
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

2004-04-02 Thread Paul Oehler
 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

2004-04-02 Thread X-Istence
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

2004-04-02 Thread X-Istence
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

2004-04-02 Thread X-Istence
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

2004-04-02 Thread Rick Widmer


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

2004-04-02 Thread Rick Widmer


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

2004-04-02 Thread Marcin Soltysiak
  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

2004-04-02 Thread Marcin Soltysiak
 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

2004-04-02 Thread Doug Clements
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

2004-04-02 Thread Doug Clements
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

2004-04-02 Thread Rick Widmer


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

2004-04-02 Thread X-Istence
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