On 2006-04-03, at 0727, Rick Widmer wrote:
John Simpson wrote:> and since i now have two different patches for vpopmail, it's time to > create a new web page to hold them. both patches are available from> this page, which includes basic documentation for the new features. > >http://qmail.jms1.net/patches/vpopmail.html Actually its .shtml not .html.
yeah, i'll learn how to type one of these days.
In the patch, how do you separate password and real_name in add_user? I know the help doesn't mention it, but I think it requires a real name value to put into GECOS. It is at least an option.
good point. i totally missed that, and i even changed one of the _TOKENS strings to be called GECOS_TOKENS after seeing that it was only used the one time. now we see why it's better to have several eyes looking at the code.
this is going to be another problem. since a password may contain spaces, and a gecos may also contain spaces, there is no reliable way to write such a parser unless there is a specific delimiter between them... and since a password, by definition, can contain any printable character (ASCII 0x21 - 0x7E) the delimiter cannot be one of these.
my honest answer is this: README.vpopmaild doesn't talk about there being a gecos field, neither does the vpopmaild wiki entry. in this one case, because the documentation doesn't mention it and because it causes a problem, i would say to pull the gecos functionality out of the add_user command, and add a "gecos" verb to "mod_user" (which needs one anyway.)
there will be a newer patch on my web site this evening (i would do it now but i need to run some errands first.)
so are you asking about "does this mailbox exist, yes or no", or are> you asking about "is this the correct password for this mailbox, yes > or no"?I was under the impression your interest is based on Robin Bowes suggestion about the validrcptto.cdb patch, so it is "does this mailbox exist." We may as well make it easy, it should be a popular function. Maybe we could provide a validrcptto command, allowed before login, but you have to add --enable-vpopmaild- validrcptto in ./configure to use it. That way they have to act to enable the ability, and they get a warning from ./configure about tightening security.
maybe... but validrcptto.cdb is different. it isn't concerned with mailboxes or passwords, as far as it's concerned an alias is just as valid, or if the file contains "@domain", any address in the domain is valid... or if there is a "-default" version of an alias, any suffix after that is valid. vpopmaild is not a good match for what validrcptto.cdb already does.
what it IS a good match for, however, is processing AUTH requests- since every vpopmail mailbox which doesn't have the "no_smtp" flag should also be valid for the AUTH command.
i've been thinking about ways to both speed up, and simplify, processing of the AUTH command. the two ideas which have come to mind are:
(1) have qmail-smtpd check an "auth.cdb" file, where the key is a mailbox and the value is the encrypted password.
(2) have qmail-smtpd open a socket to a vpopmaild service, or a courierauthd service (i wrote a simple widget which handles the "login", "help", and "quit" commands, but uses courier-authlib instead of libvpopmail) and uses that to verify the ID and password which were entered. http://qmail.jms1.net/courierauthd.shtml talks about it. the page is not really finished but the code is very simple and it works, if you can link it- there are issues with how BSD handles linking with the courier-authlib library and i don't have a BSD system to play with.
the "auth.cdb" idea is a lot easier to write, and to me it makes more sense. however, the idea of using vpopmaild for this purpose is also intriguing from a programming standpoint (i.e. CAN i write this code, how can i make a single version of qmail-smtpd which can handle all three AUTH schemes- fork/exec vchkpw, auth.cdb, and vpopmaild.)
i think what i'll end up doing is writing the auth.cdb patch first, and then worrying about "AUTH via vpopmaild" later.
> this, the documentation for creating a vpopmaild service should mention,i'm not against it, i just think if we're going to add something like> very prominently, that this information is exposed to anybody who> connects and that the user (system administrator setting up the service) > should either run the service on 127.0.0.1 (as i do), or should have a > tcpserver access control file which only allows authorized machines to> connect.I'm all for documentation. :) I wrote most of README.vpopmaild. Its not great but its better that what was there before......Speaking of documentation, can I add much of your page http:// qmail.jms1.net/vpopmaild.shtml to the README.vpopmaild file? I'll credit you and let you review it before I commit.
not a problem... all i ask is that you leave the URL for my page in there. there's actually a (slightly) updated README.vpopmaild on my web page, and i've been thinking of adding an HTML version of README.vpopmaild which details the commands to the page as well.
I'm pretty sure you can edit the wiki if you want, you just have to register first. If not, I'm considering making sure everything you need to know is in the wiki, and making the wiki page the README file.
that's an even better idea. i believe i am registered, i think i fixed a typo on one of the other pages once.
p.s. I got a kick out of this: "with a working vpopmaild service it becomes possible to write a program like vqadmin or qmailadmin which does all of its work using vpopmaild commands." That's _exactly_ what vpopmaild was written to allow. I couldn't have said it better.
sick minds think alike? hehehe -------------------------------------------------- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | -------------------------------------------------- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | --------------------------------------------------
PGP.sig
Description: This is a digitally signed message part
