Re: [vchkpw] test copy of vpopmaild.c
- Original Message - From: Ken Jones [EMAIL PROTECTED] I think it works pretty nicely. A single . on a line by itself represents End of File when sending or receiving multiple lines of infomation. Nice idea. [cut] Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command +1 for b) First, it would be a bit like chrooting, so potential exxploits would have harder way to get out of ~vpopmail/. Second, would be easier to user if there was no need for repeting full path everytime. Solt
Re: [vchkpw] test copy of vpopmaild.c
- Original Message - From: Ken Jones [EMAIL PROTECTED] On Monday 05 April 2004 8:08 pm, Charles Sprickman wrote: On Mon, 5 Apr 2004, Ken Jones wrote: I'd like any comments or votes on how this version is using a POP3 type protocol. Sounds good to me, this is getting exciting! One little question... What are you thinking of as far as encryption? I'm sure there's going to be some people running the client on a box seperate from the server. You looking at adding ssl support, or are you thinking of just letting something like stunnel handle that? My favorite is ucspi-tcp-ssl with a self signed certificate. It provides peer to peer encryption by just adding -s to the tcpserver options. Or use stunnel. It is similar to how email clients and mail servers encrypt pop3/smtp/imap communication. I thought so about ucspi. tcpserver is a good tool. Solt
Re: [vchkpw] test copy of vpopmaild.c
Marcin Soltysiak wrote: - Original Message - From: Ken Jones [EMAIL PROTECTED] Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command +1 for b) First, it would be a bit like chrooting, so potential exxploits would have harder way to get out of ~vpopmail/. Second, would be easier to user if there was no need for repeting full path everytime. I disagree. If he chooses b, then you have to worry about what the rights of the current user is when composing commands. If he uses full paths, it doesn't matter what kind of user is at the browser, you always send the same command. For example, using b to create a VacationMessage file for [EMAIL PROTECTED]: Sys Admin would send: write_file /test.com/user/VacationMessage The Domain admin would send: write_file /user/VacationMessage And the user would send: write_file /VacationMessage It would be much easier to write code for using the daemon if everyone always referenced that file using the System Admin example, and you don't have to do the same job three different ways depending on who happens to be logged in. Remember, there will be a whole bunch of PHP code on top of the daemon. Rick
Re: [vchkpw] test copy of vpopmaild.c
- Original Message - From: Rick Widmer [EMAIL PROTECTED] Marcin Soltysiak wrote: - Original Message - From: Ken Jones [EMAIL PROTECTED] Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command +1 for b) First, it would be a bit like chrooting, so potential exxploits would have harder way to get out of ~vpopmail/. Second, would be easier to user if there was no need for repeting full path everytime. I disagree. If he chooses b, then you have to worry about what the rights of the current user is when composing commands. If he uses full paths, it doesn't matter what kind of user is at the browser, you always send the same command. For example, using b to create a VacationMessage file for [EMAIL PROTECTED]: Sys Admin would send: write_file /test.com/user/VacationMessage The Domain admin would send: write_file /user/VacationMessage And the user would send: write_file /VacationMessage It would be much easier to write code for using the daemon if everyone always referenced that file using the System Admin example, and you don't have to do the same job three different ways depending on who happens to be logged in. Remember, there will be a whole bunch of PHP code on top of the daemon. Either I am missing something or... If we use full path then same operations would look like: Sys Admin would send same as The Domain admin would send same as And the user would send: write_file /path/to/vpopmail/home/domains/test.com/user/VacationMessage And this way we let the user know ~vpopmail. I know that in concepts, ordinary user should not use plain vpopmaild protocol but PHP application, but since we don't work in secret I can imagine that one day one of my customers that feels geek in programing would come and request Hey man, where is your ~vpopmail? I don't like your admin UI and I want to write my own. In case od b) I wouldn't have to tell him the path. He would just stick to write_file /VacationMessage when logging as [EMAIL PROTECTED] Solt
Re: [vchkpw] test copy of vpopmaild.c
Marcin Soltysiak wrote: Either I am missing something or... If we use full path then same operations would look like: Sys Admin would send same as The Domain admin would send same as And the user would send: write_file /path/to/vpopmail/home/domains/test.com/user/VacationMessage And this way we let the user know ~vpopmail. I know that in concepts, ordinary user should not use plain vpopmaild protocol but PHP application, but since we don't work in secret I can imagine that one day one of my customers that feels geek in programing would come and request Hey man, where is your ~vpopmail? I don't like your admin UI and I want to write my own. In case od b) I wouldn't have to tell him the path. He would just stick to write_file /VacationMessage when logging as [EMAIL PROTECTED] There is no need to send the ~vpopmail/domains/ part of the path, because the user has no choice on that part. If we always send the full path from that point down, then the path is always: $Domain/$User/$whatever or maybe /$Domain/$User/$whatever I think both should be allowed, and have the same meaning. Rick
Re: [vchkpw] test copy of vpopmaild.c
On Tue, 6 Apr 2004, Rick Widmer wrote: There is no need to send the ~vpopmail/domains/ part of the path, because the user has no choice on that part. If we always send the full path from that point down, then the path is always: $Domain/$User/$whatever or maybe /$Domain/$User/$whatever or 1/$Domain/K/$User/$whatever Just a reminder that vpopmail does directory hashing on domains and users. Charles I think both should be allowed, and have the same meaning. Rick
Re: [vchkpw] test copy of vpopmaild.c
On Mon, 2004-04-05 at 20:18, Ken Jones wrote: One little question... What are you thinking of as far as encryption? I'm sure there's going to be some people running the client on a box seperate from the server. You looking at adding ssl support, or are you thinking of just letting something like stunnel handle that? My favorite is ucspi-tcp-ssl with a self signed certificate. It provides peer to peer encryption by just adding -s to the tcpserver options. Or use stunnel. It is similar to how email clients and mail servers encrypt pop3/smtp/imap communication. or, my favorite, ucspi-ssl (http://superscript.com/ucspi-ssl/intro.html -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] test copy of vpopmaild.c
Anyone want a test copy of vpopmaild before it gets posted? It could use another set of eyes. Show me the money :-) Solt
Re: [vchkpw] test copy of vpopmaild.c
Ken Jones wrote: Anyone want a test copy of vpopmaild before it gets posted? It could use another set of eyes. Yes please. Regards, Rick
Re: [vchkpw] test copy of vpopmaild.c
Ken Jones wrote: Anyone want a test copy of vpopmaild before it gets posted? It could use another set of eyes. Yes, please. Rick
Re: [vchkpw] test copy of vpopmaild.c
- Original Message - From: Ken Jones [EMAIL PROTECTED] Here ya go. Look at README.vpopmaild Short test procedure: ./configure (your options) make ./vpopmaild login [EMAIL PROTECTED] user help ./configure with option PASSED make PASSED ./vpopmaild ./vpopmaild +OK login [EMAIL PROTECTED] password +OK domain_dir /home/vpopmail/domains/imedia.com.pl name office comment office quota NOQUOTA dir /home/vpopmail/domains/imedia.com.pl/office encrypted_password $1$L6UBr$.EzXzXSDy1PZiCiNT6Erm. clear_text_password password domain_admin_privileges . list_dir imedia.com.pl -ERR XXX unauthorized directory list_dir /home/vpopmail/domains/imedia.com.pl +OK .qmail-default postmaster office magda I think /home/vpopmail/domains should be ommited. list_dir domain.tld should do the job However, now as Ken introduced the daemon we cat have a boost :-) Great job, Ken! Solt
Re: [vchkpw] test copy of vpopmaild.c
On Monday 05 April 2004 2:46 pm, Ken Jones wrote: [snip] I'd like any comments or votes on how this version is using a POP3 type protocol. I think it works pretty nicely. A single . on a line by itself represents End of File when sending or receiving multiple lines of infomation. From the client side, responses come back from vpopmail as either: +OK or +OK line of text line of text . or -ERR XXX error message So the mod_user function would take it's options on additional lines, like: moduser [EMAIL PROTECTED] no_smtp quota 1234 . And the server would reply back +OK or -ERR XXX error message Do you think the protocol is simple enough to make it easy to use? I'd like to complete the full list of commands and responses for a first version. Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command Ken
Re: [vchkpw] test copy of vpopmaild.c
Ken Jones wrote: On Monday 05 April 2004 4:05 pm, you wrote: Ken Jones wrote: Anyone want a test copy of vpopmaild before it gets posted? It could use another set of eyes. Got it! It compiled and ran the first time. Good job Ken! Am I correct that any user can be a System admin, if given SA_ADMIN rights, which is a new addition to vpopmail? I just gave [EMAIL PROTECTED] SA rights, and I could list_domains, but not list_users on another domain. I got XXX not aurhorized for domain. I expect a system admin should have full access to the whole mail system. Do I have to do something to give system admin rights to individual domains? (Like have both SA_ADMIN and QA_ADMIN rights on the user.) What do you plan to do with XXX in all the error messages? Care for patches for some of the functions I requested? More as I play... Rick
Re: [vchkpw] test copy of vpopmaild.c
Ken Jones wrote: On Monday 05 April 2004 2:46 pm, Ken Jones wrote: [snip] I'd like any comments or votes on how this version is using a POP3 type protocol. I like it very much so far! The way you put the user name and password on the same transaction is even better than following pop3 exactly and requiring user and pass commands for login. I think it works pretty nicely. A single . on a line by itself represents End of File when sending or receiving multiple lines of infomation. That will work very well for parsing results. If you always check for ., +, and - as the first character of a result it should be pretty easy to keep from getting lost when parsing responses. So the mod_user function would take it's options on additional lines, like: moduser [EMAIL PROTECTED] no_smtp quota 1234 . And the server would reply back +OK or -ERR XXX error message If I wanted to add no_smpt and no_dialup, do both go on the same line that specifies GID options, or is it one item per line. If the latter, it should not matter what order they are specified in. Do you think the protocol is simple enough to make it easy to use? It looks good so far. I will attempt to modify my sample PHP code that uses sockets to connect to the daemon and see how it goes... I'd like to complete the full list of commands and responses for a first version. Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command As long as you tell me where ~vpopmail is when I login, always using fully qualified paths will be easiest, I think. That way I don't have to change how I build commands depending on the access level of the user. That requires the daemon to verify that requests point to the proper directories, but already does.
Re: [vchkpw] test copy of vpopmaild.c
On Monday 05 April 2004 7:36 pm, Rick Widmer wrote: Ken Jones wrote: On Monday 05 April 2004 2:46 pm, Ken Jones wrote: [snip] I'd like any comments or votes on how this version is using a POP3 type protocol. I like it very much so far! The way you put the user name and password on the same transaction is even better than following pop3 exactly and requiring user and pass commands for login. Great! looks like a keeper. I think it works pretty nicely. A single . on a line by itself represents End of File when sending or receiving multiple lines of infomation. That will work very well for parsing results. If you always check for ., +, and - as the first character of a result it should be pretty easy to keep from getting lost when parsing responses. So the mod_user function would take it's options on additional lines, like: moduser [EMAIL PROTECTED] no_smtp quota 1234 . And the server would reply back +OK or -ERR XXX error message If I wanted to add no_smpt and no_dialup, do both go on the same line that specifies GID options, or is it one item per line. If the latter, it should not matter what order they are specified in. Just one item per line. The only order dependent option I could think of is the clear_all_flags option. So you could start clean and only add in exactly what you wanted. Do you think the protocol is simple enough to make it easy to use? It looks good so far. I will attempt to modify my sample PHP code that uses sockets to connect to the daemon and see how it goes... Excellent :) I'd like to complete the full list of commands and responses for a first version. Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command As long as you tell me where ~vpopmail is when I login, always using fully qualified paths will be easiest, I think. That way I don't have to change how I build commands depending on the access level of the user. On login I could send vpopmail_dir /base/path/to/~vpopmail That requires the daemon to verify that requests point to the proper directories, but already does. Gotcha. There is code for validating directory input to restrict each level of user to their respective base directories. Also it is checking for .. in any part of the directory. In case input tries to walk down to / and trod on any file in the filesystem. Any other things we should check for? Perhaps % in filenames?
Re: [vchkpw] test copy of vpopmaild.c
On Mon, 5 Apr 2004, Ken Jones wrote: I'd like any comments or votes on how this version is using a POP3 type protocol. Sounds good to me, this is getting exciting! One little question... What are you thinking of as far as encryption? I'm sure there's going to be some people running the client on a box seperate from the server. You looking at adding ssl support, or are you thinking of just letting something like stunnel handle that? Thanks! Charles I think it works pretty nicely. A single . on a line by itself represents End of File when sending or receiving multiple lines of infomation. From the client side, responses come back from vpopmail as either: +OK or +OK line of text line of text . or -ERR XXX error message So the mod_user function would take it's options on additional lines, like: moduser [EMAIL PROTECTED] no_smtp quota 1234 . And the server would reply back +OK or -ERR XXX error message Do you think the protocol is simple enough to make it easy to use? I'd like to complete the full list of commands and responses for a first version. Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command Ken
Re: [vchkpw] test copy of vpopmaild.c
Hi, Ken Jones wrote: So the mod_user function would take it's options on additional lines, like: moduser [EMAIL PROTECTED] no_smtp quota 1234 . And the server would reply back +OK or -ERR XXX error message I get this list_dir /home/vpopmail/domains/nougen.com/naomi/Maildir/cur +OK . On a user with nothing in their directory. Is that valid or should it be . +OK ie listing the contents, in this case nothing, and then listing the +OK I'm of the thought that it should be line of text line of text . +OK Or even skip the . and just finish with +OK #more text available here That way every single response ends in +OK or -ERR A little tired now (kids, 2 and 5), but I think the ending . and the +OK at the beginning is redundant. Regards, Rick
Re: [vchkpw] test copy of vpopmaild.c
On Monday 05 April 2004 8:08 pm, Charles Sprickman wrote: On Mon, 5 Apr 2004, Ken Jones wrote: I'd like any comments or votes on how this version is using a POP3 type protocol. Sounds good to me, this is getting exciting! One little question... What are you thinking of as far as encryption? I'm sure there's going to be some people running the client on a box seperate from the server. You looking at adding ssl support, or are you thinking of just letting something like stunnel handle that? My favorite is ucspi-tcp-ssl with a self signed certificate. It provides peer to peer encryption by just adding -s to the tcpserver options. Or use stunnel. It is similar to how email clients and mail servers encrypt pop3/smtp/imap communication. Ken
Re: [vchkpw] test copy of vpopmaild.c
Charles Sprickman wrote: On Mon, 5 Apr 2004, Ken Jones wrote: I'd like any comments or votes on how this version is using a POP3 type protocol. Sounds good to me, this is getting exciting! One little question... What are you thinking of as far as encryption? I'm sure there's going to be some people running the client on a box seperate from the server. You looking at adding ssl support, or are you thinking of just letting something like stunnel handle that? Tcpserver can run under openssl to provide a ssl tunnel. The daemon never even knows...
Re: [vchkpw] test copy of vpopmaild.c
Rick Macdougall wrote: I'm of the thought that it should be line of text line of text +OK Or even skip the . and just finish with +OK #more text available here That way every single response ends in +OK or -ERR +1. Note, I removed the . in the response list. It will be easier to just look for + or - as the end of every response.
Re: [vchkpw] test copy of vpopmaild.c
On Mon, 5 Apr 2004, Ken Jones wrote: One little question... What are you thinking of as far as encryption? I'm sure there's going to be some people running the client on a box seperate from the server. You looking at adding ssl support, or are you thinking of just letting something like stunnel handle that? My favorite is ucspi-tcp-ssl with a self signed certificate. It provides peer to peer encryption by just adding -s to the tcpserver options. Or use stunnel. It is similar to how email clients and mail servers encrypt pop3/smtp/imap communication. Ah. I didn't realize this was using tcpserver. Thanks, Charles Ken
Re: [vchkpw] test copy of vpopmaild.c
Ken Jones wrote: Any votes on which way of specifying directories would be easier from the client program's point of view? a) full paths b) relative based on user or command As long as you tell me where ~vpopmail is when I login, always using fully qualified paths will be easiest, I think. That way I don't have to change how I build commands depending on the access level of the user. On login I could send vpopmail_dir /base/path/to/~vpopmail It looks like you already are. When I logged in as SA, the first response is vpopmail_dir /mail which is ~vpopmail/ on my system. I want to make sure this is easy for people so we don't end up with a bunch of /home/vpopmail/'s hard coded in people's programs. Not everyone wants all their email in /home, and it should be easy to adapt. I think it should be an error if: SA asks for anything above ~vpopmail/domains QA asks for anything above ~vpopmail/domains/mydomain or a regular user above ~vpopmail/domains/mydomain/myhomedir I think I would prefer if you hid the ~vpopmail/domains part from me entirely, and prepended it to my requested paths. A person coding on the PHP end of the daemon doesn't need to know anything about the actual directory structure in the machine. Gotcha. There is code for validating directory input to restrict each level of user to their respective base directories. Also it is checking for .. in any part of the directory. In case input tries to walk down to / and trod on any file in the filesystem. Any other things we should check for? Perhaps % in filenames? If you wanted to create/update the Vacation file for [EMAIL PROTECTED], you would specify: write_file test.com/user/Vacation or write_file /test.com/user/Vacation I think it is best to allow either one... If first char is '/', remove it. For all users add ~vpopmail/domains/ before the specified path. If regular user verify specified path starts with test.com/user/ If Domain Admin verify specified path starts with test.com/ If System Admin verify specified path actually exists When adding files or directories chop of the last term, and verify the parent directory exists. Listing, reading or removing - verify the actual file or directory exists.
Re: [vchkpw] test copy of vpopmaild.c
Ken Jones wrote: Anyone want a test copy of vpopmaild before it gets posted? It could use another set of eyes. Ken Sure, shoot me a copy this way :) X-Istence
