Re: [vchkpw] Hashed domain directories - options
On 2012-08-08, at 2132, Eric Shubert wrote: #define MAX_USERS_PER_LEVEL 100 ... In an ext3 environment, it could be set (by the admin) to 3 (ext3 supports 32000 subdirectories), and with ext4 it could be set to 6 (ext4 supports 64000). These settings would for the most part disable hashed directories, while still allowing hashes should the filesystem limits be approached. Of course, a default value in dir_control could still be 100, which would maintain former behavior. If this were done, the --disable-users-big-dir option should probably be changed to --allow-single-digit-users as well. ;) Please let me know what the prospects of such changes are. If it doesn't look like anything that might ever happen in this area, I just may patch the vauth.h file to be 3 and call it done. The filesystem's limit on how many entries can exist in a directory is not the only issue... the other issue is performance. On most filesystems (including ext2/3/4), in order to find a particular file within a directory, the kernel has to do a linear search on the contents. It can take longer to do a linear search across 30K items than it does to search through 100 entries, open a new directory, and do a second search through 100 entries. This isn't an issue for filesystems which implement directories as binary trees instead of linear lists. Personally, I don't build servers without both hashing options enabled. The hashing doesn't affect small machines (or small domains) because it doesn't kick in until a certain number of domains or mailboxes exist. And if the server becomes busy after the fact, the hashing code kicks in when needed and keeps mailbox access from being slow. The scripts that I write which access the mailboxes all use vdominfo or vuserinfo (or the qmail virtualdomains and users/assign files, and the domain's vpasswd.cdb file) to locate the directories, rather than making assumptions about where a particular domain or mailbox might be on the disk. This way I'm using the same exact method that qmail uses to deliver mail, so I know I'm ending up in the right place. If I'm not mistaken, the limitation on single-character mailbox names has something to do with how the hashing is implemented. The hash directories all have single-digit or single-letter names, and if a mailbox exists with the same name, it causes problems (or at least confusion.) Personally, I always thought they should have given the hash directories names which aren't used in SMTP address, like ,0 or ,a, but that's not how it was originally written. | John M. Simpson -- KG4ZOW -- Programmer At Large | | http://www.jms1.net/ j...@jms1.net | signature.asc Description: Message signed with OpenPGP using GPGMail !DSPAM:5023ce3d34216837713534!
[vchkpw] [SPAM] Re: [vchkpw] [SPAM] Using onchange with jms1 mailhub (update-qmail service)
On 2012-03-06, at 1655, Tom Collins wrote: Anyone else using John Simpson's mailhub technique (http://qmail.jms1.net/mailhub.shtml) for filtering inbound email? I'm triggering a rebuild of the valid recipient list via vpopmail's onchange feature, with the following script (comments removed for brevity): #!/bin/sh PATH=/usr/bin:/bin logger -t onchange $* echo onchange $@ /tmp/update-qmail But I think I've run into an issue where vpopmail blocks until the completion of the write to pipe /tmp/update-qmail. This is problematic when someone is deleting a bunch of users, because they end up waiting for one deletion to complete before doing another, and the qmail-updater service rebuilds the list of valid recipients repeatedly. I added the trailing to the echo command, in an attempt to get it to run in the background, but it hasn't helped. Has anyone else seen this? I'd really like to modify the setup so that the update script flushes the pipe whenever it can; accepting multiple lines of onchange data each time. Sorry for the long reply time, it's been a while since I've had time to read mailing lists (including my own.) I'm trying to get caught up on things now. Did you ever figure anything out with this? Also, what OS are you using? I seem to remember discovering that different kernels handle blocking on named pipes differently. I've been using CentOS 5 (Linux kernel 2.6.18) for several years and haven't had any issues. | John M. Simpson -- KG4ZOW -- Programmer At Large | | http://www.jms1.net/ j...@jms1.net | signature.asc Description: Message signed with OpenPGP using GPGMail !DSPAM:501e7f5a34218012789813!
Re: [vchkpw] big picture
On 2009-04-06, at 0923, Ron Miller wrote: See: http://qmail.jms1.net/qmail-1-incoming.pdf and http://qmail.jms1.net/qmail-2-delivery.pdf ... which have just been updated. it's now a single file instead of separate files for each page. the first two pages are pretty much identical to the old files, and page 3 covers accessing the contents of the mailboxes, using qmail-pop3d and dovecot. http://qmail.jms1.net/qmail-system.pdf out of curiosity... am i the only one who wasn't able to make heads or tails of this guy's diagram? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49dada5032681120218602!
Re: [vchkpw] vpopmail make install should support DESTDIR
On 2009-04-01, at 1306, Matt Brookings wrote: John Simpson wrote: this should make it possible to not require root in order to configure or build the software... or is there some other reason root permissions are required? They are required because currently, the Makefiles want to mkdir and chown, etc. when you're doing a make install, i would expect that. are you saying that the process of compiling the software, even if you're not installing it yet, still creates system-level directories? if this is the case, then the Makefile is broken. and vpopmail has been around long enough that i have trouble believing it's broken that badly, which is why i'm asking the question. does the Makefile actually create system-level directories just to compile the software, even if you don't intend to actually install it on the machine where it's being built? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d68dd032684677597184!
Re: [vchkpw] vpopmail make install should support DESTDIR
On 2009-04-01, at 1356, Manvendra Bhangui wrote: On Wed, Apr 1, 2009 at 9:41 PM, John Simpson j...@jms1.net wrote: the only problem i see at the moment is how the FHS stuff is going to affect where the files are. i want the program to self-adjust to FHS layout or built from source layout automatically, which means i'll need to be able to tell either which layout was used and what the FHS locations are, or if there's an internal list of directories (i.e. parent directory of all mailboxes, location of binary files, location of config files, etc.) i can use, and if those directory locations will be stored in a .h file which can be used by external programs (which would seem to make sense.) all these would be passed as arguments to the configure script. They are stored in the file config.log. Else one can have a shell script which creates a .h file using the options passed to the configure script. Just my 2 cents. i know the mechanism for how configure works. the config.log file is a diagnostic tool, to document what the configure command actually did. it's not used in any further compilation or installation steps. normally the configure command builds a file like config.h, which all of the other source files include. my question was what information is, or will be, available in config.h to tell where the various pieces of the package (i.e. mailbox storage, binaries, configuration info, documentation, etc.) are found, rather than assuming (as we do now) that they will be in the domains, bin, etc, doc, and other fixed-name directories within the home directory of the vpopmail user. assuming this information is there, it would also be useful to the maintainers of other packages which add to vpopmail (such as qmailadmin, and possibly the collection of other web admin front-ends which seem to be springing up recently) if there were a command-line tool to return this information. for example, vsysinfo -d would print the directory where the domains are stored, -i for the include files, -l for the location of libvpopmail.a (or .so, eventually), and my personal favourite, -c would print the actual ./configure command line which was used to configure the software. i guess, more than anything else, i need to sit down and start looking at the new code, rather than pestering everybody with questions. all i need now is free time... | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d6926b32689042753631!
Re: [vchkpw] Further Information for Building RPM for vpopmail
On 2009-04-02, at 1036, Manvendra Bhangui wrote: 2009/4/2 John Simpson j...@jms1.net you DO NOT want these to be setuid root. in fact, you don't want ANY of the binaries to be setuid root, except possibly for vpopmaild, and that only if you want to allow it to create and remove domains- otherwise it can run as the vpopmail user with no ill effects. I have not explored that. Example could be making qmail-newu to be setuid root and making the assign file writeable by vpopmail. it's not just those files... vpopmail also modifies the rcpthosts, morercpthosts, virtualdomains, and users/assign files whenever it adds or deletes domains, and it also needs to be able to run qmail-newmrh if the morercpthosts file was changed. and if users have the ability to create their own custom .qmail files, or to specify lines which end up in those files, you DO NOT want the vpopmail user to have write access to any of qmail's control files. a better idea would be to run vpopmaild as root (if you want to allow it to create or delete domains at all) and use it to process any such requests. i know a few people on this list have mentioned web front- ends which duplicate most or all of qmailadmin's functionality, but do all of their work by sending commands to vpopmaild. But getting the root password or doing ssh root is out of question in my production environment. good idea... i take it one step further: the list of people who have root access (i.e. myself only) is exactly the same as the list of people who are allowed to add or delete domains (also myself only.) which means even vpopmaild doesn't NEED root access, since everything else it does can be done by the vpopmail user. as for compiling in extra password checks and so forth... have you read the documentation for sudo? you can allow certain users to execute certain commands with root permissions, but not give them unfettered root access. the syntax is a bit non-intuitive, but once you understand it, it can be quite powerful. it seems to me this would be a better solution than having to manually add in your own custom patches every time a new version of vpopmail is released. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d69f8f32685873613284!
Re: [vchkpw] vpopmail make install should support DESTDIR
On 2009-03-30, at 0844, Matt Brookings wrote: I think the build system needs is a way to stop the -o and -g statements when building a package, and to use them when not. Most everyone has been installing vpopmail from source, and I have a feeling many will continue to. We can't remove setting of permissions altogether because then people who used source would have to manually fix permissions. here's an idea... why not include a utility which sets the ownerships and permissions correctly? for RPM users, the program would be called called a post-install script to ensure that the newly created directory structure has the proper ownership and permissions. for users who install from source, they can either run it by hand, or have a make check step which runs it. and after it's installed, no matter HOW it was installed, the machine owner can run it at any time to ensure that the permissions of his vpopmail directory are correct. if there's interest in the idea, i'll write it. it amounts to a compiled C version of the vfixpermissions script from my web site. of course, i've never understood why the vpopmail user's numeric uid/ gid needs to be hard-coded into the executables to begin with. is it really that expensive to call getpwnam() when the program starts? or was that done simply because djb did it in qmail? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d3166332681258564993!
Re: [vchkpw] vpopmail make install should support DESTDIR
On 2009-04-01, at 0725, Manvendra Bhangui wrote: On Wed, Apr 1, 2009 at 12:52 PM, John Simpson j...@jms1.net wrote: here's an idea... why not include a utility which sets the ownerships and permissions correctly? Actually the program is not needed. sorry, the vfixpermissions script on my site gets too many downloads for me to agree with you. people have a tendency to tinker with their systems, and they need a reliable way to set things back to rights when/if they break something. think about how many questions show up on this list because somebody got the permissions or ownership of a file wrong somewhere... and right now, my script seems to be the preferred (only?) way to do this. i just think it makes sense to include it with vpopmail itself, rather than hoping people do the right kind of google search to find it on my site, usually at a point in time when they need it right this second and they're trying not to panic because some or all of the users can't get to their email... maybe it doesn't need to be part of the build/packaging process, but it *is* something people need after the system is installed and running, because people *do* tweak their files by hand sometimes, and they may forget (or not know how) to set the permissions correctly when they're done. i just figured that if i'm going to write it anyway, it may as well be used by the setup procedure. but if matt (i guess matt has taken the lead on vpopmail now?) doesn't want to change the existing code, that's fine with me. the only problem i see at the moment is how the FHS stuff is going to affect where the files are. i want the program to self-adjust to FHS layout or built from source layout automatically, which means i'll need to be able to tell either which layout was used and what the FHS locations are, or if there's an internal list of directories (i.e. parent directory of all mailboxes, location of binary files, location of config files, etc.) i can use, and if those directory locations will be stored in a .h file which can be used by external programs (which would seem to make sense.) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d3922632681309018144!
Re: [vchkpw] Deleting primary domain; keeping alias domains
On 2009-03-18, at 1151, Charlie Garrison wrote: On 18/03/09 at 9:31 AM -0500, Matt Brookings m...@inter7.com wrote: Charlie Garrison wrote: Is there a proper way to delete a domain which is currently configured as the primary domain for an account? And I want one of the current domain aliases to become the primary domain. I can't find any comprehensive documentation for vdeldomain. Maybe it will do what I want; I don't have a test system to try it on though. An alias is just that, an alias. It is not an actual domain. If you delete the primary, the alias will not function because there is no primary domain data for it to alias. I guessed that, which is why I was asking how to delete the primary domain. I want one of the domain aliases to become the primary domain. Is there any way to do that short of completely recreating the setup for that domain/directory? The primary domain is no longer in use (has expired) and I would like to completely remove all references to it. My thought was to 'mv' the domain directory to the name of the domain alias, and manually edit the qmail/users/assign file accordingly. But I don't know if there are other locations where the primary domain name is stored that would also need to be updated. (I'm ignoring rcpthosts, etc for now since they seem to be easy changes.) i had a case like this a few years back. when the client started hosting, they used one domain name. they then added two others as aliases, and printed all of their business cards with one of the alias domains. a year later they decided to give up the original domain name, and wanted the alias on their business cards to become the primary. from what i remember, the process looked like this: - shut down qmail-send and all POP3/IMAP services - delete the alias domain which is about to become primary (using vdeldomain) - create the new primary as a physical domain (using vadddomain) - use mv to move the contents of domains/olddomain.xyz into domains/ newdomain.xyz *** edit the vpasswd file so the directory names accurately reflect their new names (i used sed for this.) *** run vmkpasswd newdomain.xyz - delete the old domain (using vdeldomain) - start up qmail-send and the POP3/IMAP services so it looks like the only non-trivial thing which hasn't been covered already is updating the vpasswd file and running vmkpasswd to rebuild the vpasswd.cdb file. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d22c7732681224718157!
Re: [vchkpw] [OT] VPS recommendations to offload spam/virus scanning?
On 2007-10-25, at 15:44, Adam Cantwell wrote: If you're going to split things up, you should look at John Simpson's validrcptto patch instead of chkuser. Only one file needs to be synced across. http://qmail.jms1.net/mailhub.shtml you do also need to make sure the rcpthosts and/or morercpthosts.cdb files are built on the remote server (what i call a mailhub) as well... but that's only an issue when you add or remove domains. and in either case, there is no need to synchronize an entire directory structure. the web page does explain the mechanics and has a bunch of scripts, but it also relies on qmail being built with my validrcptto.cdb patch as well... and while i (obviously) think it's better, it can be a little bit of a learning curve for somebody who is already used to some other solution (such as chkuser.) tom, feel free to contact me off-list if you decide to try going the validrcptto.cdb route and want to ask questions. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Vpopmail mysql and aborted clients
On 2007-10-04, at 0336, [EMAIL PROTECTED] wrote: ... have noticed that each morning for example after all the night without poping or imaping... the next time someone pop or imap in the morning I get no errors on mail client and everything works fine... but have noticed that 10 aborted cliets appear... in show status in mysql... P.D. John (John Simpson) perhaps this could be a challenge for you :) i don't know a whole lot about how vpopmail uses mysql, the only thing i use mysql for is the back-end storage for my jabber server, and a few clients who need it for their web sites. my only guess would be the eight-hour timeout that tonix already mentioned. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Vpopmail mysql and aborted clients
On 2007-10-04, at 2255, Christopher Chan wrote: tonix (Antonio Nati) wrote: MysSQL has now an hardcoded timeout of eight hours. Courier uses it's authentication daemon with persistent attach to vpopmail/MySQL, it could be that during the night there are no requests, so MySQL connections are droppped (by MySQL). I thought this was addressed in a recent version of vpopmail? when vpopmail tries to do something on the sql server and gets a connection was closed error, it now opens a new connection and tries the operation again. it sounded like he was talking about seeing the stale client threads/ processes within the sql server itself, which for whatever reason hadn't been harvested by the sql server's reaper. if so, that question has more to do with the sql server's internals than it does with vpopmail. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail or qmail problem?
On 2007-10-02, at 1928, Christopher Chan wrote: Am I missing something obvious? I always thought -default was checked last and I can't see why its not using the exact match on .qmail-bob-clamav There was some discussion of enabling such support in vpopmail. i'm not sure, but i suspect the discussion you're thinking of had to do with .qmail files within the MAILBOX (i.e. siblings of the Maildir folder) rather than in the domain's directory (i.e. one level up from the mailbox.) those would have to be processed by vdelivermail, while the .qmail files in the domain directory itself are processed by qmail-local, before vdelivermail is ever executed. If you look in your assign file, you will find that your address will become domain-bob and qmail-local will be told to look for dot files in /home/vpopmail/domains/domain. You are missing the effect of the virtual domains in qmail and vpopmail's assign entries. for messages sent to bob-clamav@, qmail-local looks for the following files in the domain's directory: .qmail-bob-clamav .qmail-bob-default .qmail-default .qmail as for the original question, i'd have to look at things by hand to tell for sure, but it sounds like qmail is skipping the .qmail-bob- clamav file for some reason. and knowing qmail like i do, i suspect there's nothing wrong with qmail-local except maybe some error or warning condition that it's silently ignoring, where we might wish it would complain about, so we know what's happening and can fix it. maybe the filename is wrong, the .qmail-bob-clamav file isn't readable to the vpopmail user, or something... i would need to see the UN-EDITED contents, ownerships, and permissions of the users/ assign, .qmail-bob-clamav, .qmail-bob-default, and .qmail-default files, along with the actual headers (again not edited, hiding domain names doesn't serve any purpose) of a message which was incorrectly delivered. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail user/group
On 2007-09-30, at 1622, aledr wrote: I need to build vpopmail as non-root user and used --enable-non-root-build but I got this message: checking for valid vpopmail user and group... yes checking whether password file entry for the vpopmail user exists... No vpopmail user found. Please add the vchkpw group and vpopmail user. Then run configure again no configure: error: Could not compile and run even a trivial ANSI C program - check CC. So, is there a way to do not check the vpopmail user and group at build time? fix the Could not compile and run even a trivial ANSI C program - check CC issue. that will probably allow it to compile the test program which looks for the vpopmail user and vchkpw group. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18?
On 2007-09-27, at 2116, Tren Blackburn wrote: However as soon as I append another pipe like so: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox with a line like this, qmail-local will see the return value for the line as whatever came from vdelivermail... and vdelivermail WILL run, regardless of what qmail-pipe may or may not send to it. like tom said, if your qmail-pipe doesn't alter the message, then put the call to qmail-pipe on one line, and the call to vdelivermail on the next line. in that case, any non-zero exit from qmail-pipe will prevent qmail-local from running vdelivermail. and if qmail-pipe DOES alter the message, then qmail-pipe needs to execute vdelivermail as a child process, sending the altered message to vdelivermail's stdin, using the normal pipe(), fork(), and file handle shuffling routine (or if qmail-pipe is written in perl, 'open (O,|vdelivermail ...)' will fire up the child process and do the file handle shuffling for you, and you can just print the modified message to file handle O.) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Shared libvpopmail thoughts
On 2007-09-24, at 1120, Joshua Megerman wrote: First off, let me prefice this by saying that while I understand the concept of shared libraries, I don't understand the underlying mechanics of how the OS handles them, i'm not sure exactly how far underlying you don't understand, but here's a fairly simple overview of the seedy underside of program linking and the difference between static (i.e. compile-time) and dynamic (i.e. run-time) linking. the compiler generates .o files, containing the following: - one or more text segments, which contain byte sequences of executable code - a list of exports, symbols which are available in the module, usually functions which may be called from, or global variables (such as errno) which may be accessed by other modules. - a list of imports, symbols which this module needs in order to execute correctly, and the fixup locations where the final memory address of each symbol should be stored. there are other types of files called .a files, which are basically a collection of .o files joined together for easier management- a library, in other words. libvpopmail.a is one of these. you can see the various imports and exports in a .o or .a file using the program nm. for example, in vpopmail 5.4.22, the file md5.o contains the following symbols: $ nm md5.o 07e0 T MD5Final 0038 T MD5Init 006c T MD5Transform 06ec T MD5Update T byteReverse U memcpy U memset the symbols with T are exports, the functions in the module. these function names are available to be matched against other modules which may need them. the symbols with U are imports, names which need to be matched against other modules in order to build a final working program. in this case, the memcpy and memset functions are defined in the memcpy.o module within libc.a or libc.so. the compile-time linker gathers a bunch of these .o and .a files, matches up the imports with the exports from the various modules, and produces a final executable with any interior links resolved. for a statically linked program, ALL links must be resolved in order to have a working program- so if your main() called any or all of the MD5 functions listed above, your .o would have MD5Init and friends as imports, and the linker would match those against the md5.o module and add memcpy and memset to the list of imports, so the linker would then bring in the memcpy.o and memset.o modules from libc.a, as part of your program's final executable. there are two problems with this scenario: - some functions, like printf(), have a LOT of dependencies. a three- line program which might normally generate a 4K executable, can grow to over 800K because of these dependencies. - if the underlying library changes, you have to re-compile this program to gain the benefits (security fixes, new features, etc.) of the new library. if a program is being compiled to support dynamic linking, then instead of looking at libc.a, it looks at libc.so. and instead of copying the code from the .so into the final executable, it builds a list of run-time fixups, which is stored in the final executable. then, when the program is actually executed, the first thing it does is call a run-time linker, usually called ld.so. the run-time linker loads the necessary .so files into your program's memory space, performs the fixups (i.e. stores the final in-memory address of the library functions into the correct memory locations in your code), and then jumps to the starting point of your program. because modern CPUs support the concept of making a particular segment of memory read only, and because most memory management hardware makes it possible to map a particular physical segment of memory to appear in any logical address within the address space, it is possible for shared libraries to physically exist in memory only one time, while visible to multiple processes as different addresses. this is why, if you look at a process with ps or top, you'll see two memory-usage numbers- the virtual size, which is how much total memory space is used if this process were the only one on the machine, and resident set, which is how much memory is dedicated to just that one process. the difference in these two numbers is the amount used for shared memory, usually shared libraries like libc.so. and thus am not sure exactly how can be affected performance-wise. the vpopmail programs are already dynamically loaded- it's just the libvpopmail.a functions which are not loaded dynamically. the performance hit would be minimal- it already has to load libc.so at run-time, one more library won't take long enough to make any real difference. 1) A shared library with a stable API would make recompiling outside programs (e.g., QmailAdmin) unnecessary, which would be a Good Thing (tm). as long as it's the same API for all of
Re: [vchkpw] Shared libvpopmail thoughts
On 2007-09-25, at 0513, Rick Widmer wrote:
Joshua Megerman wrote:
1) A shared library with a stable API would make recompiling outside
programs (e.g., QmailAdmin) unnecessary, which would be a Good
Thing(tm).
It is that 'stable API' that is the killer. I know some ./
configure options change the interface to libvpopmail. I don't
know which ones they are. :( I do know if you change some of the
options you can get some spectacular failures if you forget to re-
compile everything that uses vpopmail.
maybe we need to change the API, standardize it... if there are
functions which either do or do not need an extra parameter, then
i would say to add that parameter anyway, and if the final program
doesn't use it, it can pass a 0 or NULL or whatever, and the function
would ignore it.
Once upon a time vpopmail was designed to be quick and tiny. All
options were compiled in. Since then at least 3 of the back ends
have adopted a configuration file. Maybe it is time to look at
moving most of the ./configure options to a configuration file
add a vpopmail_init() function which reads that file and sets a bunch
of use_* variables, which the other functions would then check.
make it a requirement that all client programs must call this
function first, or any functions whose operation depends on these
variables being properly set, could call this function instead... of
course it would have a flag variable so that calling it multiple
times doesn't result in the config files being read multiple times,
something like this...
int flag_init = 0 ;
int use_auth_mysql = 0 ;
int use_auth_pgsql = 0 ;
int use_auth_ldap = 0 ;
int use_auth_sybase = 0 ;
int use_onchange = 0 ;
void vpopmail_init(void)
{
if ( flag_init ) return ;
/* read the config file, set all use_* vars
if we encounter errors, exit(1) */
}
we also need a reinit() function, so that processes like vpopmaild
can force the config to be re-read without having to be stopped and
restarted.
void vpopmail_reinit(void)
{
flag_init = 0 ;
vpopmail_init() ;
}
and of course, the relevant functions need to check these variables
in order to work properly. for example, i know the call_onchange()
function is already written to early-exit if the ~vpopmail/etc/
onchange script doesn't exist or isn't executable, it would be
trivial to early-exit if the use_onchange variable contains a zero
instead of a one.
i think i'm probably being a bit too detailed for this list, this
should probably be moved to the developer list.
and have only one vpopmail library interface for the entire life of
a major (minor?) version.
Are we starting 5.5 or 6.0 if we change the library interface, and
table layouts?
my suggestion would be to use 5.5 as the testing ground as we
migrate closer to a single API and a shared library, with 6.0 being
the release with a shared library only.
the other suggestion i have is this- there are options which make
sense for larger systems, and don't hurt anything for smaller
systems, the ones involving splitting the domains and mailboxes into
numbered sub-directories in order to prevent having a single
directory with 15,000 entries in it. these options should just plain
be turned on for everybody, and the options should be removed.
the only argument i've ever heard for keeping them as options is that
some people have written scripts which make assumptions about the
directory structure. these scripts should run vdominfo -d and
vuserinfo -d to get the directories, rather than assuming they will
be in any particular location. i'm just not a fan of hanging on to
options which serve no purpose other than to accomodate improperly
written scripts- the idea of splitting the domains and mailboxes into
different directories has been around forever, there's no excuse for
somebody to not have made the adjustment by now.
| John M. Simpson--- KG4ZOW ---Programmer At Large |
| http://www.jms1.net/ [EMAIL PROTECTED] |
| http://video.google.com/videoplay?docid=-1656880303867390173 |
PGP.sig
Description: This is a digitally signed message part
Re: [vchkpw] Shared libvpopmail thoughts
On 2007-09-25, at 1331, Joshua Megerman wrote: i vote for a and c during a transition period, then c as the only option after that. in either case, i think d might be taking the idea too far. Yeah, I realized that after the fact. I'm great ad coming up with lots of ideas of what can be dine, and then I need to rein them in as to what _should_ be done :) oh i see, so you're an idea rat (pardon the dilbert reference)... surprising, most idea rats end up in marketing because they can't program their way out of a wet paper bag, but from what i've seen your code seems pretty solid. maybe you're a better patcher than a writer? i suffer from that myself- i find i do a better job of programming if i'm patching existing code, or writing against a previous design... problem is that when i start something from scratch, i tend to not do that separate design step ahead of time and end up slowing myself down. the other thing i seem to be good at is the sanity checking, poking holes in ideas (my own included.) at past jobs, windows developers always hated to have me sit in on their meetings, because i would always bring up security issues before they had even started writing code... they eventually got over it, after their web apps got hacked and they had to very quickly add the changes i had originally suggested, while i rebuilt the server and restored from a backup taken just before they installed their stuff... i just don't like it when other peoples' stupidity causes me to have extra work. 3) In all cases, even if the vpopmail binaries are linked against the shared library, the static library libvpopmail.a should be built since some programs expect it. maybe for interim versions, to give other programs' developers time to deal with the change... but i think that a vpopmail version 6 should be shared only. I don't see why there shouldn't be a static library that has exactly the same ABI as the shared one, in case someone wants (or needs) a static binary. But they should be interchangable at compile time. maybe we can always build the shared version, and have a configure option --with-static-library (which would not be active by default) which builds a static libvpopmail.a for people who may need it, even though the programs in the vpopmail package won't need it? either way, i think we need to move the thread over to the devel list. anybody who's interested should subscribe and look for it there. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Shared libvpopmail thoughts
On 2007-09-25, at 1348, Tom Collins wrote: I'm all for keeping it, but someone should fix it. On my server, with a cdb backend, I have the following structure: main directory: 65 domains 0: 25 domains 1: 2 domains 2: 2 domains 3: 0 domains 4: 3 domains 5: 44 domains to me this looks like a bunch of domains were deleted at some point... either that, or different versions of vpopmail have had or not had the store domains in numbered directories option at different times. I'd love to see vadddomain do a better job of back-filling domains. Maybe vadddomain and vdeldomain could work together to keep directories at a balanced level. i'm not sure that vdeldomain has, or should have, anything to do with it. Keep track of the next directory to fill in a file (which needs to be protected by a file lock). The .dir-control file is supposed to work that way. On vdeldomain, if the domain came out of a directory less than the next_directory, update next_directory. On vadddomain, if next_directory has 100 domains after the addition, scan forward until you find a directory with 100 domains and update next_directory. i think trying to track it in a file is overkill... unless you're adding several domains per minute, or you have multiple people adding domains, you should just be able to add the bucket-selection code to vadddomain(). It should be possible to make the code generalized enough to work for the domains directory and the individual domain directories (for managing users via vuseradd and vuserdel). not too difficult... i'll throw something up on the dev list in a few minutes. i would have figured that logic was built into vadddomain() and vadduser() already though? again... on the dev list. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Shared libvpopmail thoughts
On 2007-09-25, at 1836, Rick Widmer wrote: The difference between shared and static libraries isn't in the code. It is all compiler options and when the linking actually happens. The problem as I see it is ./configure options like -- enable-clear-password. This option changes the table definition in sql back ends, and the structure of the vpasswd and vpasswd.cdb files in the cdb back end. It may even change the struct that contains the password data. not an issue... make the SQL tables HAVE that field, as a varchar() which allows NULL, and leave the item in the struct, so that the only difference between with and without clear passwords is whether or not those fields in the SQL table or vpasswd file are used or not. basically if clear passwords are NOT supported, then we would always store NULL or an empty string in those fields. The solution as I see it is to compile with everything on, disable undesired options at runtime based on the configuration file, and always provide variables and fields, even for disabled items, when library functions are called. err... yeah, what he said. my suggestion would be to use 5.5 as the testing ground as we migrate closer to a single API and a shared library, with 6.0 being the release with a shared library only. OK, I won't start anything yet... I am partial to 6.0 being dev and 6.1 being stable. If we unify the library interface and change the database structure it is a major change. usually the stable versions have even sub-version numbers (i.e. for the linux kernel, 2.3 and 2.5 are experimental, while 2.4 and 2.6 are stable.) maybe start a 5.9 as the test-bed for what will eventually become 6.0? i also have an idea which has been suggested, in various forms, by several users... a field in the vpasswd file and/or whatever SQL table serves its function, for a timestamp when a particular password was set, and one which, if non-zero, will expire a password. this allows for aging schemes to be built- some companies have policies which require users to change passwords every 90 days or whatever, and right now vpopmail has no way to support this. i also wonder if it wouldn't make sense to change the format of the vpasswd file itself- instead of fields separated by : with each field having its meaning based on its ordinal number within the line, how hard would it be to support the userdb format- fields separated by |, and each field being of the format name=value... i would imagine the code to parse this format already exists somewhere, it would just be a case of moving it into vcdb.c. this would allow extra fields to be added in the future without any major code changes. i think if we're going to start designing a major new version, now is the time to make these kinds of major changes. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Info on upgrading vpopmail.
On 2007-09-24, at 1008, mlist wrote: I have a test machine that I upgraded to vpopmail 5.4.23. I recompiled/reinstalled qmailadmin and vqadmin. I didn't recompile courier-imap nor did I recompile qmail-smtpd. I was able to telnet and successfully login to ports 25, 110, 143. So, is it necessary to recompile qmail-smtpd and Courier? I didn't recompile qmail-smtp because I'm not using the chkuser patch - I am using john simpsons combined patch 1.7.01. Would I still need to recompile? the 1 is part of jms1. the patch is version 7.01. you do need to rebuild courier-authlib, since it links against vpopmail. you do not, however, need to rebuild qmail itself. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] segfault vdeluser 5.4.21
On 2007-09-20, at 1236, mlist wrote: Now when I try to delete a user I get a segfault: mail:/home/vpopmail/bin # vdeluser [EMAIL PROTECTED] Segmentation fault first, why would you want to delete a domain's postmaster mailbox? second, i would have thought the vdeluser command, or the vdeluser() function, would refuse to delete a postmaster mailbox... however looking at the code, i see that this is not the case. given that RFC 2821 section 4.5.1 seems to say that it's required, is there ever a valid reason to allow a postmaster mailbox to be deleted? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] wheri is it vpopmail-5.4.22
On 2007-09-19, at 1513, [EMAIL PROTECTED] wrote: i downloaded http://downloads.sourceforge.net/vpopmail/vpopmail-5.4.22.tar.gz ... and ./configure ... vpopmail 5.4.21 Current settings --- ... That is version 21 or 22? i could not understand? there's a typo in 5.4.22. if you're really worried about it... - expand the source - edit configure.in and edit the AC_INIT line to have the right version number - run autoconf then run your ./configure command line again. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Mysql table
On 2007-09-19, at 1532, mlist wrote: Please try creating a domain with a long name, up around 80-90 characters long. ... I did as you said and I recieved errors. Here is the command I used and the errors returned. ... vmysql: error creating table 'a _com': Incorrect table name 'a _com' Error. Failed while attempting to add domain to auth backend you missed the other error message. mysql has a limit of 64 bytes for a table name (at least mysql versions 5.1, 5.0, and 5.1 do, i'm assuming earlier versions had the same limit.) also see RFC 1035 section 2.3.4. each portion of a domain name (i.e. the abc in abc.com) can be no longer than 63 bytes, and no full hostname (i.e. www.abc.com) can be longer than 255 bytes. and since mysql has a limit of 64 bytes for a table name, you have a... maybe not a bug, but a design flaw. the name a(63 times).com IS a valid domain name, but a(63 times)_com is NOT a valid table name. perhaps you shouldn't store each domain's data in a separate table? i've never understood the reason for creating separate tables for each domain anyway- but since i don't normally use a SQL back-end for mailbox information, it's not something i really worry about. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Vpopmail and local users
On 2007-09-18, at 1513, shacky wrote: I'm using Qmail with Vpopmail to manage some e-mail virtual domains and users with no problem. I need to manage the local users too, with the Maildir support. How I configure Vpopmail to use the local users too? migrate the local users' mailboxes over to vpopmail. make sure you remove the domain name from the locals file- and if that leaves you with an empty locals file, make sure you still HAVE a locals file, even if it's zero bytes. otherwise, the code in qmail-send which reads the locals file will read the me file instead, and use that name as a local domain, and vpopmail won't work for that domain name. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail 5.4.22 breaks qmailadmin 1.2.X
On 2007-09-17, at 1751, Jeremy Kister wrote: On 9/17/2007 5:28 PM, John Simpson wrote: which reminds me... how about a patch to change the maximum password length to a more realistic limit? i've been doing this for several years, after applying patches but before running ./ configure... Also, since only the first eight characters of a password matter on Solaris 10 (or any DES vs MD5), perhaps there should be a maximum limit of 8 when using --disable-md5-passwords. This way, users who think [EMAIL PROTECTED]:: is a secure password are enlightened. good idea. i just wrote a patch to do both items. sourceforge has it as #1797464, or you can also download it from my web site. http://qmail.jms1.net/vpopmail/#passlen my one concern is this- i would rather see the decision of 128 or 8 happen within vpopmail.h. my first thought was to just add an #ifdef around the #define MAX_PW_CLEAR_PASSWD line in vpopmail.h, but the MD5_PASSWORDS flag that i would use as a test, is defined within config.h, and i don't know if it would break anything to include config.h within vpopmail.h. i doubt it would affect anything within vpopmail, but how many other packages out there (qmailadmin, courier- authlib, etc.) use vpopmail.h as part of their compile process, and also have a config.h file in their source code? so what i did is added the #ifdef block at the top of vpopmail.c, after both vpopmail.h and config.h have been included. this works, and for now it's safe because vpopmail.c is the only file which actually uses MAX_PW_CLEAR_PASSWD. however, if some future version of vpopmail uses this value in a different source file, that source file would need the same #ifdef block at the top. finding a way to safely add that #ifdef to vpopmail.h itself would solve this potential problem. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail 5.4.22 breaks qmailadmin 1.2.X
On 2007-09-16, at 2302, Rick Widmer wrote: I posted a patch on qmailadmin's SourceForge site. The tracker number is [ 1795973 ]. It should allow qmailadmin to work with 5.4.22. On the other hand, I think I am going to revert the part of the patch that caused this problem, and apply it later. I plan to review all the buffer size definitions in the next development effort, and that is probably a better time for things that change the library interface. Look for another release with this change reverted next weekend. which reminds me... how about a patch to change the maximum password length to a more realistic limit? i've been doing this for several years, after applying patches but before running ./configure... sed -ie '/^#define MAX_PW_PASS/s/40/128/' vpopmail.h sed -ie '/^#define MAX_PW_CLEAR_PASSWD/s/16/128/' vpopmail.h i don't know about you, but my mailbox password is 23 characters long, and i encourage my users to use long passwords. (i use the standard vpasswd.cdb files for authentication, no SQL, i suspect that SQL users will need schema changes needed to support this- basically make the password fields longer.) i'm not familiar enough with the SQL end of things to know if this is the only change you would need, but i'm guessing so. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] is there a patch that provides to add .qmail the user's directory as every user is addded with vadduser ?
On 2007-09-11, at 1844, Bulent Kolay wrote:
I use vpopmail5.4.17 and procmail.
I am looking for a patch for vpopmail that,
when I add an user with vadduser I want vpopmail to add the folder
called .procmailrc in the user's directory according to that user.
is there any patch for this ?
usually when this comes up, people want to know how to pre-create
Drafts, Sent, and Trash folders within each mailbox. this is
the same thing, but with a different directory name.
one option is to edit vpopmail.c in your source directory. lines
2110 and 2111 look like this:
2110 const char *dirnames[] = {Maildir, Maildir/new,
Maildir/cur,
2111 Maildir/tmp};
this array contains the names of the directories which are created
within each mailbox when it's created. if you need a .procmailrc
directory, add .procmailrc to this array, like so:
2110 const char *dirnames[] = {Maildir, Maildir/new,
Maildir/cur,
2111 Maildir/tmp, .procmailrc};
then do make distclean, and re-run your ./configure, make, and
make install commands.
another option... google for vpopmail skel patch. this is a patch
which causes vpopmail to copy the entire directory tree from a
skeleton to the new mailbox. this way you can change what gets
created without having to re-compile the code, by simply creating the
directories you want within the skeleton directory.
i have a copy of the patch, one of the items on my to-do list is to
clean it up, test it, fix any bugs, test it again, and then submit it
into the vpopmail source tree. unless somebody really objects, the
code will eventually be in vpopmail- it's just not there yet.
| John M. Simpson--- KG4ZOW ---Programmer At Large |
| http://www.jms1.net/ [EMAIL PROTECTED] |
| http://video.google.com/videoplay?docid=-1656880303867390173 |
PGP.sig
Description: This is a digitally signed message part
Re: [vchkpw] is there a patch that provides to add .qmail the user's directory as every user is addded with vadduser ?
On 2007-09-11, at 2251, marlowe wrote: Bulent Kolay wrote: I use vpopmail5.4.17 and procmail. I am looking for a patch for vpopmail that, when I add an user with vadduser I want vpopmail to add the folder called .procmailrc in the user's directory according to that user. is there any patch for this ? This type of functionality can be handle through the use of onchange. I believe onchange became part of the vpopmail with 5.4.18. You can read more about onchange at http://qmail.jms1.net/vpopmail/. oh yeah... you can also do it that way. write your onchange script so it checks for an add_user command, and if it sees it, creates the .procmailrc folder and any default files within the new mailbox (whose physical directory name can be gotten using a vuserinfo -d [EMAIL PROTECTED] command.) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] change Log_ service
On 2007-08-23, at 2043, Quey wrote: Is there an easy way to have logging go to another service like local1, local3 etc without having to massively edit all LOG_'s ? logging of what? pop3? smtp auth? vpopmaild? onchange? and how is the logging being done right now? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Permissions on vpopmail install suggestion
On 2007-08-22, at 1534, Bob wrote: Many of us use either qmail-scanner-queue or simscan via patched qmail ahead of vpopmail. If, as is good prcatice, we allow the scanner to run under its own user ID, vchkpw will fail because instead of running as user vchkpw it is running as the scanner user which doesn't have access to the password files. I would like to suggest that in the make install, the permission for vchkpw be set to 4711 so that it will always execute as the vchkpw user. Doing this will eliminate a bit of extra work when upgrading and will stop the large number of user questions when they do their qmail installs. i've been doing this for several years. and for those who run into this issue, at least with simscan, i refer you to this page which explains the problem and how to work around it: http://qmail.jms1.net/simscan/troubleshooting.shtml i also think the install procedure for simscan needs to be changed a bit, but that probably belongs on the simscan mailing list. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Permissions on vpopmail install suggestion
On 2007-08-22, at 1952, John Simpson wrote: On 2007-08-22, at 1534, Bob wrote: Many of us use either qmail-scanner-queue or simscan via patched qmail ahead of vpopmail. If, as is good prcatice, we allow the scanner to run under its own user ID, vchkpw will fail because instead of running as user vchkpw it is running as the scanner user which doesn't have access to the password files. I would like to suggest that in the make install, the permission for vchkpw be set to 4711 so that it will always execute as the vchkpw user. Doing this will eliminate a bit of extra work when upgrading and will stop the large number of user questions when they do their qmail installs. i've been doing this for several years. let me correct this statement... i DID this for years, but i don't do it any longer. the problem that bob is talking about is this- if somebody is using the normal AUTH patch for qmail, and wants to use vchkpw as a method of allowing qmail-smtpd to validate AUTH commands, the vchkpw command needs to have permission to read the vpasswd.cdb files. and if it runs as the qmaild user, it doesn't have that permission. one solution, and what i did myself for a few years, is to make vchkpw run setuid root. however, some people set up vpopmail domains using different system uid's (i.e. vadddomain with the -u option) for different domains, as a way to implement domain quotas by setting a filesystem quota on the uid which controls the domain. in this situation, you do NOT want vchkpw to be setuid to the vpopmail user. a better solution is to make qmail-smtpd use something other than a checkpassword program (which is what vchkpw actually is) to verify passwords. this was the reason that i wrote an addition to my combined qmail patch, which teaches qmail-smtpd to use an auth.cdb file, with email addresses as keys and encrypted passwords as values, to validate AUTH commands. since i've started using this, i haven't needed vchkpw to be setuid, and in fact it's not setuid on my server any more. one of these days i'll get around to writing an AUTH_CDB patch for djb's virgin qmail-1.03 code, and probably for netqmail-1.05 as well, but for now it's available in my combined patch (which has lots of other yummy features as well.) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] smtp-auth and rblsmtpd
On 2007-08-17, at 2113, Trey Nolen wrote: I would suggest starting another instance of qmail-smtpd on port 587 that does not use the rbls, and has its own tcp.submpt.cdb that allows anyone to connect, but does not ever set RELAYCLIENT. This allows all addresses, but will only allow relay for authenticated users. Port 587, is the default port for this kind of operation. Thanks. We will start that, too. But, we do have a number of clients that are ALREADY using port 25 for smtp-auth. Is there any way to keep them from being affected by the rblmtpd? For instance, is there a way to pass a variable to tcpserver if the connection is authenticated via smtp-auth? no, because there's no way for tcpserver to know whether or not a valid AUTH command will be sent. remember that qmail-smtpd would be accepting the AUTH command, and rblsmtpd runs before qmail-smtpd does. the correct answer is to create one or more AUTH-only SMTP services, preferably also encrypted only for security, and tell your users that they must use those instead. i'm not sure which patches you're using, but my combined patch has support for both of these features (i.e. it won't accept any MAIL commands until a valid AUTH command has been sent, and it won't accept any AUTH commands unless the connection is secured.) i *think* both of these features are available in other patches but i will admit that i'm not 100% familiar with them- i'm sure if you can tell us which patches you're using, somebody on the list will be able to give you some quick directions for how to set this up. if you're not married to any particular patch, here's the info regarding mine. do your research and make see if it will work for you, if so you're (obviously) welcome to use it. http://qmail.jms1.net/patches/combined.shtml http://qmail.jms1.net/smtp-service.shtml http://qmail.jms1.net/tls-auth.shtml | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Off Topic: Virtual FTP Server or web-based file manager?
On 2007-08-15, at 0208, Tom Collins wrote: OK, so it's off-topic, but can anyone recommend an FTP server or web-based file manager that I can deploy on my hosting server that either integrates with vpopmail (like maybe Pure-FTPd) and has a nice interface for managing accounts? I only have two IPs for my server, so multiple clients would share the same FTP server. I'm considering having usernames that include domain names for logging in, and thought that QmailAdmin might be a good interface for managing the FTP accounts. Web may be a better way to go, because FTP is already in use by clients for managing their web content. If I use Pure-FTPd or vsftpd, it will need to be configured for both system users and virtual users. A well-designed, web-based file manager would be a great replacement for FTP. A search on SourceForge didn't turn up many promising leads. Lots of stuff that hasn't been maintained since 2004, or has less than 1000 downloads. Any recommendations? no recommendations, but it's starting to give me ideas... and that's a scary thing when you've been up all night. somebody needs to write a qmail-ish FTP server, one which supports the same checkpassword mechanism that qmail's pop3 server uses. think of an ftp-popup program, which runs a checkpassword program (such as vchkpw), which then runs an ftp-server program. the ftp-server program would have support for the standard commands compiled into it, so it doesn't need to fork out and run ls to handle a dir command from the client, and therefore wouldn't need an elaborate jail directory to be created in order to chroot() a user into their $HOME directory. of course, because it would be able to use vchkpw as a checkpassword program, it would work with any authentication mechanism supported by vpopmail... and therefore be manage-able using any GUI which works with vpopmail. i think i'm going to start reading RFC 959... | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
[vchkpw] bug in vuserinfo, with fix
howdy-
a user on the qmailrocks list found a genuine bug in vuserinfo.
he's using 5.4.13 but it still happens in 5.4.19.
# vadduser [EMAIL PROTECTED] .
# vmoduser -xb [EMAIL PROTECTED]
# vuserinfo [EMAIL PROTECTED]
name: test
passwd: $1$29/asG/o$SVO9kBPkhr2ALEQtFod9r/
clear passwd:
comment/gecos: test
uid:1
gid:16
flags: 16
gecos: test
limits:
mail will be bounced back to sender
dir: /vpop/domains/domain.xyz/test
quota: NOQUOTA
usage: NOQUOTA
account created: Mon Aug 13 09:37:37 2007
last auth: Never logged in
# vuserinfo -D domain.xyz
{snip}
name: test
passwd: $1$29/asG/o$SVO9kBPkhr2ALEQtFod9r/
clear passwd: (null)
comment/gecos: test
uid:1
gid:16
flags: 0
gecos: test
limits: No user limits set.
dir: /vpop/domains/domain.xyz/test
quota: NOQUOTA
usage: NOQUOTA
account created: Mon Aug 13 09:37:37 2007
last auth: Never logged in
note the discrepancy in the flags: and limits: lines.
http://qmail.jms1.net/vpopmail/#vuserinfo has a patch.
| John M. Simpson--- KG4ZOW ---Programmer At Large |
| http://www.jms1.net/ [EMAIL PROTECTED] |
| http://video.google.com/videoplay?docid=-1656880303867390173 |
PGP.sig
Description: This is a digitally signed message part
[vchkpw] Converting mysql to vpasswd
On 2007-05-05, at 1840, Rick Widmer wrote: Jonathan Selander wrote: Hello there, I'm currently reinstalling my old e-mail server, and while at it, I find it a good idea to upgrade things and make use of a MySQL database instead of the passwd.cdb files. My question is what do I need to do in order to convert these files for insertion into a database? Does such a script exisst somewhere, or do i need to make my own? If i need to make my own, where can i find specifications on the file format? vi README.mysql look for ## CONVERSION FROM CDB TO MYSQL: ## i'm actually getting ready to write a web page which explains how to do just the opposite of this- how to convert from mysql back to using vpasswd.cdb files. this is because i end up dealing with a lot of people who use qmailrocks (not my choice- they adopted my qmail combined patch.) the qmailrocks directions blindly walk people through setting up vpopmail to use mysql, without even a token explanation of why you may or may not want to do so, or how to NOT configure it to use mysql... in fact it's biggest problem is that it doesn't explain much of anything, it just tells the user run this script, run this script, run this script with your domain name at the end, run this script... and next thing you know you have an 85% working server built on two-year-old software and no idea how to administer it. the first thing i noticed about vconvert is that, unless i'm missing something, the quota information is not even touched when reading from mysql, or when writing the vpasswd file. so am i missing something and it does handle quotas somehow, or do i need to write a patch for vconvert which does this? and if i do write a patch, how are the quota data stored in mysql and/or how is this information available through the vpopmail API? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] onauth API
On 2007-01-08, at 1509, Joshua Megerman wrote: OK, I think I can say that I've figured out what I think the onauth API should be, so I'd like to get some comments on it. I haven't done any implementation yet (other than copying John's onchange function and doing the search replace). Assuming I get positive feedback, I'll move forward with the implementation. The onauth script will be given 4 parameters. the first three of which will come from the parameters to the call_onauth function. $1 is the username. [1] $2 is the domain name or NULL if it's a system user. [1] i think the username and domain name should be kept together, since the checkpassword interface has them together. again, i can see the possibility for programs other than just vpopmail calling the onauth script, and i'd like to keep the interface as generic as possible. $3 is the numeric value associated with the service type. [2] again, stick with words... with a synthesized (type=nnn) string to represent unknown service types. $4 is the current timestamp as generated by time(NULL). [3] formatted as %lu. or maybe as something else- but if you're writing an API, you need to explicitly state these kinds of details. %lu gives you ten digits, just one big decimal number. if you'd rather do something like strftime(%Y-%m-%d.%X) i wouldn't complain... but then the only thing my onauth script might do is log something, and that will happen through multilog- which will be adding timestamps on its own, so for me this is probably useless. [1] The username and domain name are passed separately because they are already broken apart in order for vchkpw/vpopmaild to authenticate the user, and would have to be concatenated together before calling onauth, and then split back apart by the onauth script. That increases the workload on both ends, so why bother. because other programs which may make use of the onauth API might not hold the user's identification as two separate items. i can see patching djb's original checkpassword program to call the onauth script for systems which might have both system accounts and vpopmail accounts. [2] Except when being used to determine whether a particular service is authorized in vchkpw, this information is never used. I think it might be good to pass a long for logging purposes, but see no reason not to stick to numeric codes, and let the called script deal with the information as it sees fit. I'll add defines so that vpomaild and other have numeric code designations as well, and they remain static unless someone decides to renumber them. just go with words, and only deal with numbers if there is no label for the value. [3] While strictly not necessary (the script can calculate it on its own), if you are using a script that just hands off the parameters to a daemon which queue's up the updates, it's possible that any given onauth script won't be processed until after the timestamp has changed. Since we can't guarantee that the onauth script will be run atomically, it's better to send the timestamp as a parameter and let the script decide if it cares. good point. Other API notes: The call to call_onauth should probably return the exit status of the onauth script, which can be gotten after the wait(pid) call returns. And instead of returning 0 for a failed call, return -1. I'm not sure if we care about that, but it's information that might be useful later on. personally i would go with 1 for good and 0 for bad, but i can see the logic here as well- just return the exit status code from wait () or waitpid(). as long as it's clearly documented, i can go either way. Other code notes: There's a couple of minor issues I see in the onchange code, which I'll fix in my onauth code and you can port back to the onchange code. Mostly the handling of a failed exec call - you should call _exit rather than return, since it's in the vfork and you don't want the vfork'd process doing anything more... ack, why didn't i see that before... i keep telling myself not to write code at 2.30am. (errr... what time is it now? again?) good catch. thanks. also, the parameter to wait() is not the address of pid... it's the address of the integer where the exit status will be stored. it doesn't matter right now, but after your discussion about returning the exit code, that makes sense- so i've added that. i also fixed the error messages (so that they actually tell what the problem is- unable to fork is not the same as unable to exec) and fixed the braces and indentation so that they are the way i originally wrote the code. (yes, i'm picky about braces and indentation... clean code is much easier to debug.) (and please leave them this way... let one little piece of the vpopmail code be shiny and clean and easy to read... please?)
Re: [vchkpw] The future of valias other topics
On 2007-01-08, at 0602, [EMAIL PROTECTED] wrote: Attached is a patch for 5.4.18 to enable alias line removal from .qmail based aliases and the implementation of alias line removal using the valias command line program. Am I meant to be posting patches here (such as my previous double free problem in vpalias.c) or to another list ? vpopmail-5.4.18-valias.patch here is fine, but you should probably start a new thread instead of replying your message into the middle of an existing one. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] The future of valias
On 2007-01-08, at 1313, Rick Widmer wrote: John Simpson wrote: so you're going to design this new thing which is LIKE an alias, but it supports sequencing... and it can use the same code and probably the same database tables... but it's NOT an alias, simply because you give it some other name. Yes, but it is not a _new_ thing. I want to freeze the alias interface and provide a new interface for scripts. Both can end up in either a .qmail/.vpopmail file or a database. here's a thought: the current function names become macros which call functions with new names and new functionality. the old API is preserved, and the new functionality is available with reasonable defaults to programs whose source code calls the old function names. only two functions really need to be changed: valias_insert(alias,domain,line) valias_remove(alias,domain,line) the functions would be renamed and gain a new parameter... valias_insertseq(alias,domain,seq,line) valias_removeset(alias,domain,seq,line) and the existing function names become macros which call the new functions: #define valias_insert(a,d,l) valias_insertseq((a),(d),INT_MAX,(l)) #define valias_remove(a,d,l) valias_removeseq((a),(d),-1,(l)) valias_insertseq() would be written to treat a seq parameter beyond the end of the alias as insert after the end. the SQL versions would include logic to find the current highest sequence within the alias and replace the huge number with max plus one, so that the lines within a given alias are always maintained as 0,1,2,3,etc. with no gaps and no duplications. valias_removeseq() would treat a seq parameter lower than zero as ignore the sequence and search for the text instead. By having separate functions we can better optimize the update process for its storage method. I think most scripts will be the result of template expansion or copied out of a text area and there will be more than one line that needs to be added. For example when writing to a file the write-script function can copy an entire script with one open / close / rename. If I have to use alias calls each line added will require the file to be copied to a temp file then renamed. i see the value of the template processing stuff, it gives an administrator a way to pre-define templates for users who want spam filtered into a spam folder and things like that. it IS a good idea. however, i see this implemented as a new function call: int valias_replace ( const char *alias , const char *domain , const char **lines ) which would start by wiping the current contents of the alias (if any) and then just writing the new lines into the alias, with sequences 0,1,2,3,etc... all within a single BEGIN TRANSACTION ... COMMIT block (or simply by writing the new lines to a .new.qmail file, chmod()ing it as needed, then rename()ing it over any existing .qmail file. Aliases are an unordered collection of delivery commands that you add or remove a single entry at a time. NO. aliases are, and have always been, a layer of abstraction above .qmail files, and are therefore ORDERED collections of delivery targets. They stay what they are in 5.4.18 for a MySQL or pgsql user. if current users are not expecting a specific sequence, and are used to not having any specific sequence, then how does it hurt things if suddenly they ARE sequenced? if nothing else, it's still random... it's just that it's the same random every time. besides, if every line in an alias is an email address, then the sequence (or lack thereof) doesn't matter. The key to an alias is that you work with it one address (line) at a time. An email coming in to an alias when you have only written two of three destination addresses isn't as much of a disaster as a script that is not completely written. you're thinking of the race condition where a delivery might happen while a .qmail file is halfway through being written. there are two solutions to this: - djb's solution, which is to enable the sticky bit for the home directory, which suspends all deliveries to that directory (for vpopmail, the home directory is the domain directory.) this is less than optimal, because it suspends all deliveries for the entire domain, rather than just the one alias you're updating. it also doesn't work with vdelivermail, because vdelivermail doesn't look at the sticky bit (it should.) - update the files or entries in a manner which is guaranteed to be atomic, either by using BEGIN TRANSACTION ... COMMIT, or by writing your new collection of lines to some other filename, setting its permissions, and then using rename() to give it the .qmail name which makes it live. this is better. A mail script is an ordered collection of delivery commands that is created or updated as a group. The key to a script is that you update the whole thing at once. I know
Re: [vchkpw] vchkpw/onauth connection types
On 2007-01-08, at 1147, Joshua Megerman wrote: vpopmaild checks the username and password directly against the user database, so setting the type to vpopmaild shouldn't depend on what port you run it on. Is there any need for other, and should I add webmail to the list? Also, should I use the words listed above, or should I just use the numeric types defined in vchkpw (0-3) and increment them for vpopmaild (4) and other (5 - if used)? i would go with words. the one exception would be for other... if you get a type code which is unknown, build a string which looks like (type=19) and send that as the type code, instead of smtp or pop3. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] The future of valias other topics
On 2007-01-05, at 1334, Rick Widmer wrote: I think the best thing to do with the localrelay patch is to put it into the contrib directory where people who need it can find it easily. The main reason I think this is because smtp after pop is obsolete. All the email clients I know of have handled smtp auth for years now, and the best thing we can do for the average user is to let smtp after pop die off. Drastic improvements in the mainstream code will send the wrong message. I wrote the paragraph above before reading the 'Further thoughts...' thread on Jan. third. If you want to do massive changes they will get added, but is it really better than recommending smtp auth for everyone and letting smtp after pop die? i think the idea of an onauth hook, similar to how onchange works, will minimize the amount of code changes needed for vpopmail, while opening the door for somebody (like joshua) to write a relay- after-pop3/imap system as external scripts if he likes, and also opening the door for others to add their own custom functionality. and it also removes any specific relay-after-pop3 functionality from vpopmail itself, while not destroying that functionality for people who may not be able to stop using it for political reasons. and it also means that vpopmail itself will never have to worry about relay-after-pop3 issues again- they can be referred to whoever wrote the external scripts that they will be using. I did not see any objections on changing to .vpopmail* files in user but not domain directories. If anyone does object, now is the time. Files in ~vppopmail/domains/user_name/ are executed by vdelivermail and will be renamed. Files in ~vpopmail/domains/ will stay .qmail and are executed by qmail-local. i agree- any files which are currently processed by qmail-local should retain the .qmail-* names, and others (i.e. the per-mailbox files) should use the .vpopmail names EXCLUSIVELY, so as to make it obvious to anybody poking through the directory structure that those files are processed by vpopmail rather than by qmail itself. as for making .vpopmail* files fully compatible with .qmail* files, that could also be a good thing- however the interface (in terms of which environment variables will be passed to scripts run from the .vpopmail file, what values will be contained in those variables, and how the return values will be interpreted) should be not only documented, but made to be as compatible as possible with what qmail- local would pass to a script in the .qmail file of a system account mailbox. this way if somebody has to transition a domain from being system accounts to being managed by vpopmail, there should be no changes to the files or scripts (as long as they are using the environment variables properly, as opposed to hard-coding path names into the script- which we all know users do.) Adding an order field to aliases... I think we should just say no! to ordered aliases. With 5.4.18 all the basic operations on an alias are available. We just declare that you can not count on the order of delivery of an alias, and call alias handling complete. i disagree. very strongly. I realize that sometimes order is important. I propose to provide another interface similar to aliases that are always ordered, called scripts, or more formally mail scripts. Vdelivermail already supports alias handling from a database so scripts and aliases should be able to share the same code, if not the same table. so you're going to design this new thing which is LIKE an alias, but it supports sequencing... and it can use the same code and probably the same database tables... but it's NOT an alias, simply because you give it some other name. explain to me how your scripts are any different from aliases with a sequence field, or a .qmail file. either way, the functional result is the same: a set of delivery targets, guaranteed to be processed in a certain order. seriously- i don't see any difference between what you call scripts and what vpopmail currently calls an alias, but with a sequence field attached to each line. in fact, for the cdb back-end, these are called .qmail files. the only thing missing is a way to store the sequencing in the database back ends, and the code to use and maintain those sequence fields. for vdelivermail, the only change in the code involves a single ORDER BY clause added to the proper SELECT query. and for the maintenance programs, it's one extra parameter passed to (1) the command, (2) the vpopmail.c stub function, and (3) the various back-end functions... and the extra code added to each back- end function. the hard parts are going to be coordinating the changes to all of the back-end functions at once, and then testing all of it. if somebody has the time, it won't be difficult for one person (myself, if needed) to write the changes for all of
Re: [vchkpw] Local relay patch
On 2007-01-06, at 0648, Rick Widmer wrote: John Simpson wrote: and it also means that vpopmail itself will never have to worry about relay-after-pop3 issues again- they can be referred to whoever wrote the external scripts that they will be using. I don't agree about this. We already have the ability. Before I'd be willing to remove it we need to provide a replacement for those who can't give it up. Once we provide the replacement it becomes part of vpopmail even if it isn't in the core. I think the initial implementation should handle the same files the same way they are done now. As you replace existing code with script calls, replicate the code within the script. joshua? if we add an onauth hook, how long would it take you to duplicate what vpopmail already does, using external scripts? i'm thinking maybe a set of files in a subdirectory under contrib, and you would write a README.something file and maybe an external web site documenting the scripts and how to set them up... | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Local relay patch
On 2007-01-06, at 1310, Joshua Megerman wrote: On Saturday 06 January 2007 12:56, John Simpson wrote: joshua? if we add an onauth hook, how long would it take you to duplicate what vpopmail already does, using external scripts? i'm thinking maybe a set of files in a subdirectory under contrib, and you would write a README.something file and maybe an external web site documenting the scripts and how to set them up... I honestly don't know - I haven't had time to start looking at this (probably won't until sometime next week), but there's 2 separate pieces: 1) the onauth hook itself, which needs to be designed properly (though it's fairly simple, so it shouldn't be too hard), and 2) the actual update functionality, which depends on the different backends - of which I'm really only familiar with 1 (MySQL). I'll give you a better idea of timeline once I look at it... you're right, the onauth code itself is simple- i could probably write it in about fifteen minutes, and i'm sure several other people could as well. what we need is to decide exactly what the interface will be when the script when it gets run (i.e. what gets passed on the command line, and what environment variables are passed.) what i see is the following: command line arguments: timestamp i.e. sprintf(%lu,time()) service pop3, imap, smtp [EMAIL PROTECTED] and when the call_onauth() function builds the command line, it will explicitly put single quotes around each item, so that if (for example) the mailbox name somehow contains a space, the shell which runs the onauth script won't break the address into two or more pieces at the wrong place. environment variables: as received from parent. this will normally include the environment variables described on man tcp-environ, which are: PROTO TCPLOCALHOST TCPLOCALIP TCPLOCALPORT TCPREMOTEHOST TCPREMOTEINFO TCPREMOTEIP TCPREMOTEPORT thoughts? would there be cases where vchkpw or vpopmaild might be called when these variables are not present, which would make it necessary to put TCPREMOTEIP on the command line as well? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-02, at 1018, Joshua Megerman wrote: So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole roaming users functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT= functionality is deprecated, and schedule it for removal 6-12 months down the line. if i'm reading this right, you're proposing that the entire pop before smtp functionality go away? so that nothing other than POP3 happens when somebody logs into the POP3 service, and there would be no dynamic changes to the access control list of the SMTP service at all? and vpopmail's documentation would explicitly tell people thou shalt use SMTP AUTH from now on? awesome. i just became one of your biggest fans. and for the time being, i think having an access control file attached to the POP3/IMAP services, which uses variables to tell when a given IP should trigger the update process, makes a lot more sense than trying to build a bunch of logic into vchkpw.c... just have it check for the presence and/or absence of environment variables, and let the external scripting control what does and does not go into that file. for example, the script could read the static smtpd access control file and find any IP blocks with RELAYCLIENT defined on them- and then copy those blocks to the POP3/IMAP access control file... and then the logic in vchkpw.c would bypass any updating if it saw a RELAYCLIENT variable in the environment. 2) Hijack the --enable-roaming-users config line to allow a different default set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users=RELAYCLIENT=\\,RBLSMTPD=\\', but once #1 is finalized the RELAYCLIENT part would be removed. there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like read the first line of a ~vpopmail/etc/_ file and use that. also, you would want to add something other than just RELAYCLIENT to your dynamic lines, maybe something like VPOPMAIL_DYNAMIC=\1\, so that the script which reads the smtpd access control list would recognize that as an entry which was dynamically added, and ignore it. but the overall idea is to minimize the amount of code you're changing in vpopmail itself, and make the whole update the cdb file process an externally driven thing. (yes, i'm actually thinking of the same separation of functions idea that i used when wrote the onchange patch- when the time comes it checks for the existence of a script, and if so, it runs it. anything beyond that is up to the script, and therefore requires no further changes to vpopmail itself.) This will preserve the ability to run vpopmail in exactly the same manner as it currently is, but move in the direction of eliminating auth-before-smtp relaying as the default method AND improving the ability to use auth-before-smtp for other access control methods. Plus, it gives people options without requiring them to be set if they don't use them. Thoughts? actually, yes... i just had an even better idea, the ultimate in flexibility. just as my onchange patch calls a ~vpopmail/etc/onchange script whenever something changes about the accounts, what about calling a ~vpopmail/etc/onauth script whenever somebody authenticates, and just leaving vpopmail's direct involvement at that? look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. then the whole process of modifying the smtp server's access control, and the logic behind when you do and don't update the list, all becomes part of the external scripting. this onauth script could also be used to drive a situation where somebody wants to log authentications to some other storage media, like a database- or to update a last auth timer in a database or LDAP server, or for any number of other purposes. then, you would write some kind of external script to manage the whole process of building the smtp access control file. that scripting could do whatever checking of static entries you like, and you can play with different scenarios in terms of making it work, without having to do any further patches to vpopmail. the only thing to keep in mind is that the onauth script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own onchange script simply sends its command line
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-03, at 1436, Joshua Megerman wrote: look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. Will do (once it's out :)) it's out. i'm running it now. wait- rick, did you forget to announce it on this list, or is it not for general consumption yet? i downloaded it from sourceforge and it works fine, including the onchange stuff. - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the queue. Since the patch isn't going into 5.4.18 anyway, there's time. so you've got a qmail mega-patch as well? i'm starting to wonder who DOESN'T have one anymore... mine: http://qmail.jms1.net/patches/combined-details.shtml the only thing to keep in mind is that the onauth script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own onchange script simply sends its command line arguments to a named pipe, where an update-qmail service is waiting for the data... that service actually does all of the work while the script exits and vpopmail lets the user get back to what they were doing. Alternatively, vpopmail could just write to the pipe itself, but the onauth script is a cleaner method. Basically, I'd send 4 tokens to the service: user, domain, IP, timestamp. It can handle the rest. if you want to split user and domain apart like that, sure... my preference would be to keep them together, as one opaque item- that way if you have a hybrid mixed system of vpopmail and system accounts, the API doesn't need to change to support no such thing as a domain... and if you do need them separately, it's easy enough to split the one datum on the @ character. as for vpopmail writing the pipe directly... that was suggested for the onchange patch as well- and shot down very quickly, by myself and by tom. the argument is/was that most people understand how shell scripts work, but very few people understand named pipes- and while anybody can write a shell script, not everybody will be doing anything complex enough to need to involve pipes. some people may do things with unix sockets, TCP or UDP sockets, semaphores, mutices (plural of mutex), or any number of other things... running a shell script leaves people with the ability to choose their own IPC mechanism, rather than forcing them to run a named pipe watcher service. it's all about flexibility. and then you could write a dedicated service, to run under daemontools, which would track which IP's are authorized and their timeout values, and would rebuild the smtp access control file whenever it needs to be changed... it could even run as root if needed (which it probably would, if it's going to be updating the smtp service's access control file.) It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as vpopmail, and it handles it all now, so I don't see a need for root access here. not everybody runs their entire mail system as the vpopmail user (in fact i don't run ANY of it as the vpopmail user- for clients who use vchkpw to handle SMTP AUTH, i have the vchkpw binary setuid/setgid to the vpopmail user, but that's it.) and since other programs (qmailadmin, vpopmaild, or some as-yet- unknown program in the future) might also end up calling this function, i think it's safer to not assume anything about what userid will be running the onauth script itself. if the script is signalling a service, obviously run the service as the userid which makes the most sense for the situation- but the onauth script itself needs to be executable by any userid on the system. I'd appreciate the help on the daemon, although just giving me the sampe code of your daemon would probably be good enough. I have a very long history of looking at other peoples' code and taking just the parts I need for whatever I happen to be working on - it's how I learned C in the first place 15 years ago... :) it's actually written in perl, believe it or not... but it should translate to C easily enough, if you're so inclined. i can see keeping a hash in memory, the IP pointing to an expire time, and every time an IP authenticates, the expire time is replaced with now plus 30 minutes... it would periodically build a new list, leaving out any expired IPs, and if the new list of IPs (not their timeout values) is different from the old list, it would write out new files and call tcprules as needed. part of writing out new files would be writing a cache to the
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-03, at 1625, Joshua Megerman wrote: ... I've even used one of the small patches on your site (the date- localtime patch), although I'm not sure if you wrote it or not (there's no credit in the file itself, and I've seen it credited to 2 different people out there, neither of them you. i didn't write it. i found it floating around on the internet years ago. i wish i did know who wrote it, i owe them a beer for saving my job a little bit easier every time i've had to tear through headers over the years... But nevertheless qmail.org links the patch on your site, even if the link is stale these days...). i didn't realize qmail.org was linking to my site at all. every time i've asked russell about adding a link to one of my scripts or patches, i've basically been ignored- i figured i wasn't a member of their good old boys club, so it wasn't worth my time to worry about it. I believe vchkpw already splits them, but I'm not sure. It's easy enough to pass them in whatever form vchkpw has them natively. vchkpw splits them internally. the checkpassword standard calls for them to be together. either way, it's a minor issue- but there may come a point in the future where a program other than vchkpw may wish to use the onauth mechanism when certain services authenticate (courier-authlib comes to mind) and they may not support the concept of separate mailbox id and domain name the same way that vpopmail does. i know that vchkpw RECEIVES them as one single opaque item from qmail- smtpd, qmail-popup, or any other checkpassword-compliant program. either way it's a minor issue at this point... unless you're writing the API in your head already? now i'm really interested in seeing where you take this... again, feel free to bounce questions or ideas off of me. Thanks - it's a little overwhelming to get so many kudos from established players when I'm still so new here (even if I have been dabbling for a long time). i recognize smart when i see it. and the fact that you've understood everything i've thrown out there, and come back with intelligent answers and counter-ideas, tells me that you're smart. that's all it is. and for the record, i don't consider myself to be established. knowledgable, yes, but... i don't even have a real link on the qmail.org site, and i'm not in google's top ten results for qmail (at least i don't *think* i am... no, i'm #22.) the only reason i'm even listed as a developer for vpopmail is because i've sent in a fair number of good patches- tom invited me (yes, i'm honored) but i have yet to actually check anything into the CVS repository at all (rick has been doing that for me, since he knows how to write the configure script and i don't.) so don't feel overhwelmed by me... i'm just some guy who wrote a web site that a lot of people find useful, who knows how to write code, who's been building, running, and now consulting for ISPs for a long time, and who's getting tired of consulting and thinking seriously about jumping back into the full-time job market (and is willing to relocate for the right offer, hint hint anybody...) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] 5.4.18 release candidate
On 2006-12-29, at 1418, Sim wrote: I need this change for disable RBL check after Pop (using pop-before-smtp function): /* append the current ip address to the tmp file * using the format x.x.x.x:ALLOW,RELAYCLIENT=,RBLSMTPD=TABtimestamp */ - fprintf( fs_tmp_file, %s:allow,RELAYCLIENT=\\,RBLSMTPD=\\\t% d\n, + fprintf( fs_tmp_file, %s:allow,QMAILQUEUE=\/var/qmail/bin/simscan\,RBLSMTPD=\\\t%d\n, ipaddr, (int)mytime); fclose(fs_cur_file); fclose(fs_tmp_file); My users can now connect to smtp port and send email with AUTH. Can you create a ./configure options for this :allow values? here's a slightly better idea: have the code read a text file from ~vpopmail/etc/, or even better from an environment variable, which contains the string you wish to use for each dynamically added IP address... and if that file or variable doesn't exist, the entire write out the IP address and rebuild the cdb file process would be skipped. this way the whole add POP3 client IPs to the smtpd access control list process becomes something which can be configured at run time, rather than having to be explicitly configured into or out of the code. the contents of the file would look like this: :allow,RELAYCLIENT=,RBLSMTPD or if you use an environment variable, you would add these two lines to the run script for your POP3 and/or IMAP services (assuming you use DYNAMIC_SMTPD_ACL as the variable name)... DYNAMIC_SMTPD_ACL=:allow,RELAYCLIENT=\\,RBLSMTPD=\\ export DYNAMIC_SMTPD_ACL the code would just write out the IP address, the string from this file/variable, a TAB, a timestamp, and a newline. === but here's a much better idea: tell your users to use AUTH. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] 5.4.18 localrelay patch
On 2006-12-30, at 0537, Rick Widmer wrote: I've decided to take the easy way out and pull the localrelay patch from 5.4.18. 5.4.19 isn't too far away, and there are a number of bug fixes that need to get out. i didn't recognize what localrelay was, so i searched back in my inbox and found a message from may 10th which describes what it supposedly does. again with keeping statically defined IPs from getting dynamic entries. why don't people just use AUTH like the rest of us? i haven't used relay-after-pop3 in about four years now... anyway. here's a totally different approach: - the process which writes out the new smtpd access control file would have a second step- it would read the list of static tcp.smtp entries. if it finds any lines which match ':allow.*,RELAYCLIENT=', it would write that line's IP (or whatever is to the left of :allow) followed by ':allow,RELAYCLIENT=' to a new file... which is then piped through tcprules to provide- get this- an access control list for the POP3 and/or IMAP servers. you could even compare the timestamps on the two files and only rebuild the POP3/IMAP access control list if the smtpd static list has been changed. the idea is that if somebody connects from an IP which has static RELAYCLIENT permission on the smtpd server, the tcpserver which fires off the POP3/IMAP service would also add a RELAYCLIENT variable. - the code in (vchkpw.c?) which starts the whole add a dynamic IP to the access control list function would search for a RELAYCLIENT variable. if it exists, it would bypass the entire process of generating new cdb files. the variable which is used to flag static entries for the patch doesn't have to be RELAYCLIENT... it could be something as simple as STATIC=... but the idea is to give the tcpserver which fires the POP3/IMAP services an access control file, and teach THAT access control file about your static entries. it seems to me there would be a lot less patching, and what little there is would be based on environment variables, which are easy to check for, and which are easy to set using tcpserver's access control files. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-30, at 1938, Christopher Chan wrote: When a scripter manages to stuff your queues with over 500k messages of rubbish, the last thing you want to do is to let any of it out let alone wait for it to disappear. The queues need to be cleared right away before you get even more bogged down. i'm thinking of writing a patch for qmail-send, where if the timestamp on a mess file is older than DOUBLE the value of control/ queuelifetime, it would delete the message BEFORE attempting one last delivery... i think this would be a huge help in cleaning up cases like this without having to shut down qmail-send. i know, more patches... i didn't realize that postfix didn't have support for virtual domains. this would be a show-stopper for me installing it on my own server, or on a client's server. postfix has its own virtual mail backend...but you had to build the tables and management scripts/tools yourself. Its virtual mail backend provides the structure but you had to fill it in. ah... so it's basically like what qmail is without vpopmail. it all makes sense now... why not just write something similar to vpopmail, but which works using whatever low-level mechanism postfix provides to handle virtual mailboxes? or if there is no such support, add it in? :D. I am sure someone must have built something like that...it is only probably not as well known as vpopmail. it may not be as well known as vpopmail, but google knows about it and that's all that really counts. i did a search for postfix virtual domain management interface and came up with this site, which sounds like vpopmail and qmailadmin rolled into one: http://www.postfixvirtual.net/ and i think this thread has pretty much played itself out in terms of being relevant to vpopmail, so i'm going to end here (although if anybody else is interested in seeing how this turns out, speak up and let us know you care.) either way, i am interested in whether you try this or not, and if so, what kind of results you have with it. if the thread dies, please let me know via direct email. take care. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-25, at , Christopher Chan wrote: ... So it appears to me that your comment (whose connection pool might become overloaded) indicates you have no idea what I meant by 'connection pooling'. This is software on the mailhub side, not the mysql server side, that addresses mysql's poor connection handling performance. you are correct, i wasn't aware of any way to do this on the client side. this reminds me of the IMAP connection pooling program that some people use with courier-imap. ... You apparently do the way it was formerly done too at the outfit; generate cdb and then scp the cdb file across to relevant boxes. What did you do to ensure that it is an atomic operation on the push/copy out to mailhub? the mailbox server sends the file using a command line this: cat file | ssh -I id_dsa_blah [EMAIL PROTECTED] filename the SSH key is in the authorized_keys file on the mailhub, with a forced command which uses the original command as a filename... it makes sure the filename is one of a small number it recognizes, and then runs a specific handler for each file. for validrcptto.cdb it does this: case validrcptto.cdb ) cat validrcptto.new chmod 644 validrcptto.new mv validrcptto.new validrcptto.cdb ;; and /var/qmail/control/validrcptto.cdb is a symlink to the file in this non-root user's home directory. other files which need to be atomically updated work the same way. for my needs and my clients' needs, my patches are the best solution. they may not be for everybody, which is why i'll explain the differences between validrcptto.cdb and chkusr, but i don't claim either one to be better than the other. different people have different needs. Yes, so long as you do not need the 'instant' creation of accounts or what not, your system will do fine for those who have a controlled generation of the cdb files. i've never had anybody get upset over a ten-second delay (which is actually why i wrote the onchange patch, to kick off this whole distribution process... the delay was previously up to one minute, and even that i never heard any complaints about.) For your traffic patterns, cdb will probably do. The outfit I worked for handled on a daily average, 200 million SMTP connections or over 8 million connections hourly. It was not acceptable to spend minutes pushing the cdb file across for the mailhubs and probably still is. (Please don't give me the get proper hardware. If I could have gotten more servers or replacements that had better disk i/o...) actually, once the process started, the new cdb files were active on the mailhubs in under five seconds. i'm not running a system the size of gmail, and i doubt anybody else on this list is either. ROTFL. I have done sendmail, postfix and qmail. qmail is the best in that it is simple and elegant. I had colleagues who would not touch qmail with a ten foot pole. They did not care to delve into the internals of qmail and qmail is a pain if you have to go in the clear out spam. sendmail and postfix are much better in the queue management area. after i wrote the validrcptto.cdb patch and stopped accepting messages for non-existent mailboxes to start with, it's rare for my queue to have more than five messages in it. i saw the same results with my clients' servers, when i upgraded them to use the validrcptto.cdb feature. Stopping qmail-send to scrounge out spam and then making sure you delete the stuff properly and do not end up with a corrupt queue is not their cup of tea since it is something they have to do regularly (yes...partly free webmail provider). if they can identify the messages they don't want (using grep or whatever) then instead of DELETING them, they can simply touch the mess/*/___ files with an old timestamp (i use 1998-01-01 00:00:00 for this) and then kick the queue by sending an ALRM signal to qmail-send. what happens is that qmail-send will try each message exactly one more time, and then delete it through the normal timeout mechanism. which means that, for individual spam-deletion cases, qmail-queue never needs to be stopped at all. the only time i ever stop a queue is if the filesystem has filled up and caused real corruption. Don't give tell me about qmHandle. That script is broken and will leave you with corrupt bounce messages under certain conditions besides being awfully slow. i've never used qmhandle. i wrote my own qfixq script years ago, and tested the living daylights out of it. and since releasing it, whenever somebody reports a problem with it, i fix it and release a new version immediately. the version on my web site has been free of any reported bugs since 2005-08-30, and the only change since then was to add an empty option to just plain delete everything in the queue, and to add a check to
Re: [vchkpw] 5.4.18 release candidate
On 2006-12-28, at 0936, Joshua Megerman wrote:
OK, I did some more testing with a test cdb and tcprulescheck, and got
some interesting results:
I thought that the daemontools documentation stated that it takes the
first match it finds period, but I misunderstood it slightly. It
states
that it looks for a match of the exact IP first, and then shorter and
shorter prefixes, taking the first match. This is close to the
exhibited
behavior, but not quite. A rule that has all 4 octets listed,
either a
single IP (A.B.C.d) or an IP range within a single /24 block
(A.B.C.D-E),
will override any rule that is less specific (as documented).
Therefore,
even if a particular subnet is excluded (e.g., 127.0.0:deny), a
single IP
address updated by vpopmail (e.g., 127.0.0.1:allow,[...]) would be
allowed
to connect (at least until the cdb was scrubbed).
However, if you have multiple rules with all 4 octets, it does take
the
first rule it finds. So the rule (e.g.) 127.0.0.0-7:deny would
override
the rule (e.g.) 127.0.0.2:allow, assuming that the deny rule appeared
first. The same pattern holds true for shorter rules, where there are
multiple rules that could match with the same number of octets listed.
Thus, it may be possible that there are people denying entire
netblocks
and then using the pop-before-smtp (or maybe even imap-before-smtp,
though
I know there are problems with at least one major IMAP server out
there)
to poke holes in their tcpserver cdb and allow connections from
otherwise denied addresses, and that one case would break with this
patch.
However, I have a possible idea for that - see below.
this is because a rule like this:
192.168.43.32-39:allow
actually goes into the cdb file as eight rules, like so:
192.168.43.32 - allow
192.168.43.33 - allow
192.168.43.34 - allow
192.168.43.35 - allow
192.168.43.36 - allow
192.168.43.37 - allow
192.168.43.38 - allow
192.168.43.39 - allow
tcpserver actually checks four entries in the cdb file... for the IP
address a.b.c.d, it searches for the following keys, in this order:
a.b.c.d
a.b.c
a.b
a
it would be nice if the file format included the subnet mask as part
of the key, it would allow for more granular searching, like so:
a.b.c.d/32
a.b.c.?/31
a.b.c.?/30
a.b.c.?/29
a.b.c.?/28
a.b.c.?/27
a.b.c.?/26
a.b.c.?/25
a.b.c/24
a.b.?/23
...
a/8
of course ? represents the original octet, ANDed with the
appropriate value to make it match the base address in a network
(i.e. for a /28 entry, the last octet would be one of 0, 16, 32,
48, 64, etc.)
I just came up with an option 4, which may well resolve the issue: 4)
modify the patch so that it looks for a specific comment line
(#UPDATESTATIC perhaps - I'm open to suggestions) at the
beginning of
the static cdb file. Lines starting with '#' characters are
ignored by
tcprules, but I can easily modify my patch to check for them,
especially
on the first line, and short-circuit the search. Then all that is
needed
is to document the effects of the patch, and state that in order to
continue updating the CDB file with addresses that have static
matches you
have to insert that comment on the first line of the static CDB. This
changes it from a compile-time configureation variable to a runtime
one,
and has the benefit of not requiring additional configuration files.
Thoughts? (I'll go ahead and make a new patch anyway, just because
it's
simple and I like the idea :))
i don't know enough about how the patch works to comment directly on
this... from rick's one-line description at the beginning of the
thread i gather the patch keeps statically-entered /etc/tcp/smtp
entries from having dynamic lines created for them when they
authenticate via POP3 or IMAP. if this is not the problem you're
trying to solve, then ignore the rest of this message.
but here's another idea:
- when a user authenticates via POP3/IMAP, the code touches a file
in a specific directory, whose name is the client's IP address. the
directory would be set via a ./configure option, and if the option is
not there, the code would be disabled entirely.
- vpopmail's make procedure would also build a program called
check-relay, which can be called from the tcpserver ... qmail-
smtpd command line. it would work something like this (quick and
dirty pseudo-C)...
int main(int argc, char **argv, char **envp)
{
#ifdef RELAY_DIR
char *filename;
char *ip ;
ip = env_get(TCPREMOTEIP) ;
if ( ip )
{
filename = malloc ( sizeof(RELAY_DIR) + 17 ) ;
sprintf ( filename, %s/%s, RELAY_DIR, ip ) ;
if ( ! access (
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-22, at 1006, Christopher Chan wrote: John Simpson wrote: http://qmail.jms1.net/patches/validrcptto.cdb.shtml There is a better patch for vpopmail support in qmail. A mysql patch that goes straight the vpopmail mysql database but I am not sure of its location. The writer even rebuffed one of Inter7's developers when someone floated the idea of qmail supporting vpopmail's mysql tables and the developer said he would write it since he was not aware of the patch's existence. So I believe the Inter7 guy drop it right then and there or maybe not. I believe it is this one here and the writer was Italian: http:// www.interazioni.it/opensource/chkusr/ that's all well and good, IF your incoming mail always arrives on the same machine where vpopmail is running, IF you don't mind re- compiling qmail everytime vpopmail is upgraded, and IF you keep your user information in a mysql database. most ISPs handle a large enough volume of email that they have several internet-facing servers which handle the flood of incoming mail, and forward the legitimate messages to an internal machine which contains the mailboxes. the one mailbox machine will be running vpopmail, but the other internet-facing servers (i call them mailhubs) are generally not running vpopmail, which means they are not able to check recipients or process AUTH commands against the vpopmail information. i've seen people get around this using mysql, both by having the mailhubs connect across the network to a database server, and by setting up mysql servers on the mailhubs and replicating the data. but what if the company isn't using mysql in the first place? (i spent eight years building and running ISPs with this exact scenario- multiple mailhubs, no mysql. yes, we had a customer database- but that was for billing, and it wasn't directly involved with the mechanics of the systems themselves.) my validrcptto.cdb and auth.cdb patches get around these problems by storing the list of valid recipient addresses and the list of valid userid/password pairs in cdb files, and just copying those files from the mailbox server out to the mailhubs whenever they change. PLUS, the fact that they're cdb files means that the lookups happen without the added overhead of having to open a connection to a mysql server (whose connection pool might become overloaded in case of a spam flood.) the down side is that you have to write some scripts to generate the validrcptto.cdb and auth.cdb files in the first place, and copy them out to the mailhubs. however, my web site also has working mkvalidrcptto and mkauth scripts, along with a web page which explains how to use ssh to push the files out to your mailhubs... so while it may not be brain dead easy, it's certainly not as difficult as setting up and maintaining replication between mysql servers. for my needs and my clients' needs, my patches are the best solution. they may not be for everybody, which is why i'll explain the differences between validrcptto.cdb and chkusr, but i don't claim either one to be better than the other. different people have different needs. postfix trumps chkusr/chkuser just as chkusr/chkuser trumps the cdb check. everybody has their own opinions... mine happen to be the exact opposite of what you've written here. First, chkusr vs rcptto.cdb. tcpserver + qmail-smtpd means a fresh fork for each new connection. The cdb rcptto means a disk access for each rcpt to check and regular rebuilds of the cdb database. chkusr/chkuser helps by keeping I/O of disk (okay we can contest whether looking up cdbs is better than looking up mysql tables or not but I think it is fair game to say that mysql lookups are more likely to be disk I/O free) and by not needing regular rebuilds of a cdb file. In fact, it offers instant/real-time user existence checks. until you build in the overhead of mysql replication (or even worse, qmail-smtpd connecting to a mysql server across the network.) open() takes less CPU and less time than mysql_connect(), even if the mysql server is on the same machine (because open() only involves qmail-smtpd and the kernel, while mysql_connect() also involves mysqld, which may already be busy with other clients, witness the complains about this very issue on the courier-imap list.) and in the case of a file like validrcptto.cdb, which would be used constantly on a busy server, the file's data blocks would be in the kernel's disk cache 99% of the time, so there is almost never any wait for a disk to rotate- any disk reads are satisfied from the kernel's disk cache. if anything, i think the chances of a single file already being cached in the kernel's disk cache are higher than the chances of a mysql server having the right rows from the right table in memory, plus be idle at the right time and be able to answer qmail-smtpd's queries
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-18, at 0444, Christopher Chan wrote: Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues. funny, i've been doing the same thing using qmail (making sure recipient email addresses exist before accepting a RCPT command in the SMTP conversation) for over a year now. http://qmail.jms1.net/patches/validrcptto.cdb.shtml -- | 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
Re: [vchkpw] onchange
On 2006-12-21, at 0330, Rick Widmer wrote: I think I remember you saying that you had your onchange script write to a pipe, and a program running under daemontools c reads the pipe and does the work. If so wouldn't it be a lot faster if vpopmail just wrote to the pipe? faster, perhaps... but not a lot faster, and certainly not enough to make up for the additional overhead of having to set up a pipe- listening service, or having to learn how to deal with named pipes to begin with. i see much confusion about setting up and using named pipes, but just about anybody can write a shell script. for my own needs, the shell script is a stub which writes the command line arguments to the pipe, and then my pipe-listening service does the actual work. this works for me, because the pipe-listening service runs as root, while the pipe itself can be chown()ed, chgrp() ed, and chmod()ed to be writable by non-root processes. yes, i understand that there is the overhead of fork()ing, exec()ing the shell, and parsing and running the script... but i don't think the overhead is as major an issue as you seem to think, unless you're running an ISP with hundreds of thousands of users and several changes (accounts added, deleted, and passwords changed) per second. I think it would be worthwhile to have --enable-onchange-pipe=/path/ to/pipefile. --enable-onchange-file=/path/to/file should work too. Both should have a reasonable default. that would involve adding the pipe-writing code to the patch... and for safety the code would also have to verify the existence of the pipe, plus stat() it and make sure that it IS a named pipe (rather than a regular file, directory, symlink, device, or some other kind of filesystem entity) before writing to it... i think it's easier to just leave it as running a shell script- the concept is a lot easier for people to understand and administer. and again, unless you're running a huge ISP and have a steady stream of changes, the script isn't run so often that the overhead is worth worrying about. i'm not against the idea (it would make my own server run a wee bit more quickly when accounts are added, for example) but i don't think the issue is critical enough to hold up releasing version 5.4.18. if anybody else is interested in this feature, i'll write a post-5.4.18 patch which adds the functionality, and you can do the ./configure option for it... but don't hold up the 5.4.18 release for this. -- | 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
Re: [vchkpw] 5.4.17 patches
On 2006-12-13, at 0211, Rick Widmer wrote: For the SQL back end we should add a sequence field with a default value of 0. When retrieving the valias lines they should be ORDER BY Sequence, Address. exactly. Extra credit if the addresses are sorted like the /var/qmail/ congrol files so domains sort together. not unless every single line in the .qmail file is an address. there are cases where program deliveries need to be processed in a specific order- i have one alias, for example, which always delivers to two mailboxes, then runs a program which does a text search, and if certain words are found in the body of the message, delivers to three other mailboxes as well. The fun part is making a .qmail/.vpopmail file look like a table. I think it will be easier to efficiently make the file look like a database rather than treating the database like a file. i'm not sure what you mean here. the format of a .qmail file is defined by what qmail-local understands, because if a .qmail file exists in a domain's directory, qmail-local processes it directly and vpopmail's executables never have a chance to modify how it works (unless the .qmail file contains an explicit call to vdelivermail.) i've always thought the best way to do it was to just add a sequence field to the SQL table containing the aliases, and have vdelivermail just duplicate what qmail-local would do if presented with a .qmail file containing the same lines in the specified sequence. -- | 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
Re: [vchkpw] .vpopmail-* instead of .qmail-*
On 2006-12-13, at 0036, Rick Widmer wrote:
One of the biggest complaints against vpopmail heard on the qmail
mailing list is the fact that it uses files kind of like .qmail
files, that are not interpreted by qmail-local, yet it names
them .qmail*.
actually, if the file is located in the domain's home directory (as
listed in the users/assign file), the .qmail-* file IS processed by
qmail-local (at least it is on every vpopmail machine i've ever
built.) the vdelivermail program only comes into play when qmail-
local processes the domain's .qmail-default file.
as for files located within a specific mailbox... that's totally
vpopmail's territory, qmail-local never sees those (unless somebody
manually creates a users/assign entry which points to that directory,
and in that case vpopmail can't really be held responsible for the
results.)
I disagree with the author about one thing... I think if both
exist, vdelivermail should process .vpopmail files instead
of .qmail files.
i think the ones created within a mailbox's directory should be
called .vpopmail-*, while the ones in the domain's directory (which
ARE processed by qmail-local) should be left the way they are.
in general i think the idea of using .qmail-{user} files at the
domain level is better, simply because it makes for one less process
involved in getting the message to the maildir. basically, if qmail-
local CAN do the delivery properly, we should allow it to do so. i
think the vdelivermail program should only be used to handle cases
where qmail-local can't work (i.e. mailbox or alias information
stored in a database.)
and if vdelivermail finds both a .qmail file and a .vpopmail file
within the same mailbox directory, it should throw an error- because
the only way that situation would ever arise is if somebody is
manually playing with the files, without setting the sticky bit on
the directory first, and if somebody is manually playing with the
files, there is an assumption that they know what they're doing.
Qmailadmin should read .vpopmail files before .qmail files and
delete the .qmail file if it exists when the .vpopmail file is
written. Effectively the files will be renamed as they are edited.
there is a possible race condition- if process A is doing a delivery,
looks for a .vpopmail file, and doesn't find one, then process B
takes over and renames a .qmail file to .vpopmail, then process A
takes over and looks for a .qmail file, then process A will think
that no file with either name exists.
i think a safer way to do it would be to have a script which finds
and renames the files as needed, and tell the users to only run the
script while qmail-send is stopped. if they're upgrading the vpopmail
binaries anyway, they will probably be in some kind of maintenance
window to start with, and stopping qmail-send won't be a major deal.
Maybe there needs to be a ./configure option to disable the new
file name.
something like --old-dot-qmail-files maybe? sounds good to me.
--
| 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
Re: [vchkpw] 5.4.17 patches
On 2006-12-15, at 1144, Rick Widmer wrote: John Simpson wrote: On 2006-12-13, at 0211, Rick Widmer wrote: Extra credit if the addresses are sorted like the /var/qmail/ congrol files so domains sort together. not unless every single line in the .qmail file is an address. The way I see it without a sequence field and order by clause you can't depend on the order of entries in a database. Maybe some are, but all it takes is a few deletes and adds and they will find out why they should not be depending on the order of entries... Since you can't depend on the order now, I see no reason not to go ahead and sort the entries in a way that makes it easy to find the one you are looking for in a list. actually, i use vpasswd.cdb and .qmail-* files, no database involved... which means that i CAN, and (for this one alias) i DO, depend on the order right now. i don't use the vpopmail API to modify this particular .qmail-* file, i edit it by hand. i had one incident where the domain's admin didn't realize that this one alias was special- he accidentally added a new employee after the text searching program instead of before it. i ended up having to fix it by hand (after he realized that he couldn't fix it using qmailadmin and called me about it) and at the same time i made it owned by root and chmod 644, so it works but qmailadmin can't change it by accident any more. granted, it's the only such alias i have, and i know the people involved and their job functions well enough to be able to re-create the .qmail-help file from memory if needed, but not everybody knows (or wants to know) their clients' businesses that well. If you need the entries to stay in the order you specify you need to be using the new calls that we are designing. ... or continue to use the current calls, and just not use a database back-end (which i've been doing for years.) for this one alias, i would NEVER want this automatic sorting to happen, regardless of which back-end i happen to be using. the fact is that right now the file back-end is the only one that i *can* use, because it's the only one where any kind of sequencing is available, even if it's not explicitly controlled by vpopmail's API. besides, i'm not sure i understand the point of sorting the entries, either within a .(q|vpop)mail file, or within the qmail control files. there are certainly no performance reasons, and if you're trying to encourage people to use the API instead of manually editing the files (and potentially introducing errors) then i would think as long as the files work the way they are, why worry about sorting them at all? there are cases where program deliveries need to be processed in a specific order- i have one alias, for example, which always delivers to two mailboxes, then runs a program which does a text search, and if certain words are found in the body of the message, delivers to three other mailboxes as well. I would say that now you are depending on blind luck that these entries stay in order, unless you already have some kind of sequence field. This needs to be done using the new calls, once they exist. no, i'm depending on a .qmail-* file, and the fact that the lines are processed by qmail-local in the order in which they exist in the file. The fun part is making a .qmail/.vpopmail file look like a table. I think it will be easier to efficiently make the file look like a database rather than treating the database like a file. i'm not sure what you mean here. the format of a .qmail file is defined by what qmail-local understands, because if a .qmail file exists in a domain's directory, qmail-local processes it directly and vpopmail's executables never have a chance to modify how it works (unless the .qmail file contains an explicit call to vdelivermail.) Yes, that is one complication, we can't redefine the structure of the .qmail file. On the other hand I absolutely DO NOT want qmailadmin, vpopmaild or any other program built on top of this to have to know what back end is being used. I want to be able to swap out back ends without re-coding higher level programs. understood. the file-based back-end already has a working sequence for deliveries- it's implied by the order in which the lines appear in the .qmail file. the part which is lacking is the vpopmail API to do anything with this sequence. adding it to the API is not difficult at all- just pick a new function prototype and write a function within each back-end module that does that job. the hard part is going to be the fact that everybody who is currently using a SQL-based back-end is going to have to convert their valias table from the existing no sequence format to the new with sequence format, and for any aliases containing multiple lines with at least one program delivery, manually verifying that the new sequences are correct
Re: [vchkpw] 5.4.17 patches
On 2006-12-12, at 0926, Remo Mattei wrote: ALl those patches sound great what about the patch that will create a greeting when you create a user? I just want to check and see if there was included no, but my onchange patch (which is waiting to be included, hint, hint guys) will add a hook that you can use to send a welcome message whenever a mailbox is added. it's a much more generic mechanism, but it can be used with the appropriate scripting to do what you need. http://qmail.jms1.net/patches/vpopmail.shtml the only thing it's waiting on is for somebody (rick?) who knows how to edit the ./configure script to add an option to enable or disable it from the ./configure command line, and have that add lines to config.h... and then somebody (tom?) to add it to an official version of vpopmail. -- | 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
Re: [vchkpw] vchkpw works manually but not from vpopmail-authlib
On Friday 01 December 2006 12:34, Michael Richardson wrote: Incidentally, how would I discover what user the authdaemond is running as? usually by running a command like this: ps auxww | grep authdaemond -- -- | 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. | --
Re: [vchkpw] vchkpw works manually but not from vpopmail-authlib
On 2006-11-30, at 1639, Michael Richardson wrote: I thought I might drop in and bug you with a problem. I recently upgraded my linux packages (including mysql) and now my qmail/vpopmail/imap- courier setup has stopped working. When I check my mail, the email client reports Login Failed. The server reports: - Dec 2 14:13:56 mydomain pop3d-ssl: Connection, ip=[::: 71.92.162.12] Dec 2 14:13:59 mydomain pop3d-ssl: LOGIN FAILED, user= [EMAIL PROTECTED], ip=[:::71.92.162.12] Dec 2 14:13:59 mydomain authdaemond: received auth request, service=pop3, authtype=login Dec 2 14:13:59 mydomain authdaemond: authvchkpw: trying this module Dec 2 14:13:59 mydomain authdaemond: vchkpw: user does not exist Dec 2 14:13:59 mydomain authdaemond: authvchkpw: REJECT - try next module Dec 2 14:13:59 mydomain authdaemond: FAIL, all modules rejected - what userid is authdaemond running as? does this userid have read access to ~vpopmail/domains/*/vpasswd.cdb ? if it can't read the files, then EVERYTHING will However, if I run vchkpw manually, it works great: that's nice, but it has nothing to do with the problem at hand. authdaemond doesn't work by running vchkpw. when you compile courier- authlib, it uses the vpopmail headers and libraries, and in fact calls the same internal functions that vchkpw does (i.e. vauth_getpw () and friends) which means that those functions are running, and the files they read are accessed, as whatever userid that authdaemond itself is running as. and if authdaemond isn't running as either root or the vpopmail user, this is what happens. when i first ran into this, i wanted to fix authdaemond so that it has different error messages for unable to access the vpasswd.cdb file and userid does not exist. however, the vauth_getpw() function isn't written with a way for the caller to tell the difference. the way it was written, if the userid is found, it returns a pointer to their information in memory. otherwise (and this word otherwise is a very big term- it could mean user not found, it could mean file not found, it could mean can't read the file because the permissions are wrong, it could mean the file is corrupt, it could mean low-level disk I/O error...) it returns a NULL pointer (i.e. the number zero.) this isn't something which can be fixed with a quick patch- it's a fundamental error in how the vpopmail API was originally designed. it's something that people (myself included) have been dealing with for several years. if somebody seriously wanted to fix it, they would basically have to start over and write a new generation of vpopmail from scratch... certainly a bigger project than i want to tackle on my own. -- | 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
Re: [vchkpw] phpbb authenticating to vpopmail/mysql
On 2006-10-27, at 2226, Matt Cornell wrote: I just finished working up this phpbb installation that authenticates (and updates the password) from amy vpopmail-mysql backend. Although I have taken more then my fair share of knowledge from open sources it's only lately that I am getting ready to give back. I thought I would ask first before I cleaned and wrote it up for the general public - is anyone even remotely interested in something like this? i'm sure there are people who would be interested, but you're more apt to find them on a phpbb mailing list rather than the vpopmail mailing list. also, a suggestion- i don't know whether your stuff works by running vchkpw or by somehow calling the libvpopmail functions directly, but you may want to have it use vpopmaild. this saves the overhead of a fork() and two exec()s, and allows you to upgrade vpopmail without having to re-write (or re-compile) your stuff. Sorry if this is too off-topic or whatever - I figured this crowd would have better initial input then a phpbb crowd. from the technical end, yes. however, i'll be honest- i suspect most of the people here also read bugtraq and know how often new security holes are found in phpbb, and therefore aren't overly interested in running phpbb on our servers. -- | 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
Re: [vchkpw] Re: [toaster] filtering outgoing emails
On 2006-10-25, at 1756, Howard Jones wrote: I've just started using qpsmtpd to do SMTP AUTH against my vpopmail users with vchkpw, to avoid running a patched qmail-smtpd[1]... [1] actually, it's to avoid having to reconcile SMTP AUTH patches with chkuser, which I already use, and couldn't live without. I run qmail-smtpd with chkuser for the 'public' MX SMTP service, and qpsmtpd for my local user's relay SMTP server, with auth and SSL. you are aware that there are other patches out there which do the same thing that chkuser does, which do work with AUTH, TLS, and SSL, and which don't rely specifically on vpopmail (i.e. when you upgrade vpopmail you don't have to re-compile qmail)? i mention this because i wrote such a patch- instead of looking directly at vpopmail's files (or mysql database, or however you have vpopmail configured) it reads a single cdb file where the keys are email addresses, and the values (for now) are ignored. it also handles -default addresses in the expected manner (i.e. if the validrcptto.cdb file contains [EMAIL PROTECTED], qmail-smtpd will accept [EMAIL PROTECTED].) i also have a combined patch which includes this one, plus all of the other standard things people seem to look for when patching qmail- TLS (both inbound and outbound), AUTH (both inbound and outbound), SPF with logging, my AUTH_SET patch (which allows you to add, change, or delete environment variables when a successful AUTH command is sent, and have those changes take effect where appropriate), badmailfrom/badrcptto with regular expressions, the ext_todo patch (which breaks qmail-send into two programs so that classifications and deliveries don't hold each other up, the so-called silly qmail syndrome), a patch which i've written but not yet documented which handles the AUTH command using a cdb file rather than calling an external program, and more. my server has been very happily using this combined patch for several months, rejecting messages sent to non-existent mailboxes while still supporting STARTTLS and AUTH. i have an entire web site devoted to this stuff, here are two pages to start with: http://qmail.jms1.net/patches/validrcptto.cdb.shtml http://qmail.jms1.net/patches/combined.shtml you may have other reasons for wanting to stick with chkuser, but you should at least look at other options (if you haven't already done so.) -- | 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
Re: [vchkpw] vdelivermail patch in order to handle maildrop filtering capabilities
On 2006-10-26, at 0359, Jérôme MOLLIER-PIERRET wrote: John Simpson a écrit : also, what if a user (i.e. the owner of one specific mailbox) wants to create their own .mailfilter file, either directly or using some kind of web interface which gives them a set of options and writes a .mailfilter file based on their choices? i would search for /home/vpopmail/domains/.mailfilter-userid before the file names you're already checking for. This case is not implemented in the patch, and therefore because it is not simple to handle .qmail-* style for maildrop. But it should be very easy to do this in maildrop style in the main or referal .mailfilter file. For the web interface, i agree ... it would be very nice. But there is lot of job to do before :))) that's what i was thinking- at some point in the future, somebody (maybe myself, if i ever get some free time) (yeah, right) will want to write a web interface which gives individual mailbox owners the ability to either edit their own .mailfilter file, or choose from a list of options which will cause the web back-end to create or modify a per-mailbox .mailfilter file, maybe using some kind of templates to support each available option. i just don't like seeing patches which lock out future possibilities. flexibility is a good thing. other than that, your patch looks like a good idea. -- | 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
Re: [vchkpw] OT: tcpserver and rblsmtpd clones
On 2006-10-26, at 0441, tonix (Antonio Nati) wrote: Does anyone know about good clones/substitutes of tcpserver and rblsmtpd? I'ld like they to have a more open licensing, so developing and deployment of new integrated features could be more easy. (sorry for going even further off topic) i don't see anything in the ucspi-tcp source package, or on djb's web site, which indicates the kind of license under which the ucspi-tcp package is distributed. i know we've probably all seen http://cr.yp.to/qmail/dist.html but that only applies to qmail. i've heard it said that all of djb's other software is essentially public domain, but now i'm curious and would like know for sure. has anybody heard or seen any kind of statement from djb about this, and if so where can i find a copy of it? -- | 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
Re: [vchkpw] OT: tcpserver and rblsmtpd clones
On 2006-10-26, at 1454, David Chaplin-Loebell wrote: John Simpson wrote: i've heard it said that all of djb's other software is essentially public domain, but now i'm curious and would like know for sure. has anybody heard or seen any kind of statement from djb about this, and if so where can i find a copy of it? Most of his software is not public domain. (Several of his math and crypto libraries are, but to my knowledge none of the networking software is). First, there's a copyright statement in the README file of each package. Second: http://cr.yp.to/distributors.html Daemontools is explicitly mentioned here-- he licenses the current version to be distributed (in package form, with a specific MD5 checksum) until the beginning of 2007. ah. i had only seen the qmail-specific version of this page, http:// cr.yp.to/qmail/dist.html ... you have answered my question, thank you. next question, and this may be better directed to djb himself (hence the CC to him.) i build servers for my clients, and i carry around a USB memory stick which contains, among other things, the source code packages for daemontools and ucspi-tcp. does this mean that starting in january i'm going to have to manually download the packages from his server instead of copying them from my USB stick when i build a client's machine? i don't really mind either way, but i'd like to know what his policy is, just to be sure. before you pointed out this page this i was not aware of 2007-01-01 having any significance (other than new years day, obviously.) -- | 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
Re: [vchkpw] vdelivermail patch in order to handle maildrop filtering capabilities
On 2006-10-26, at 1251, Rick Romero wrote:
I don't know what everyone else is doing, but my .qmail-default looks
like this:
|maildrop /home/vpopmail/domains/havokmon.com/mailfilter
| /usr/home/vpopmail/bin/vdelivermail
'' /usr/home/vpopmail/domains/havokmon.com/rick
And my mailfiler is essentially:
...
# Delete messages with a score of 10 or higher, filter all other
# spam messages into a spam folder
/^X-Spam-Status: yes, (hits|score)=![:digit:]+\.[:digit:]+!.*/
if ( $MATCH2 = 10.0 )
{
exception {
EXITCODE = 99
to /dev/null
it's been my experience that this line is not necessary, just setting
EXITCODE=99 and then exit is enough to cause the message to NOT be
delivered anywhere.
I forget exactly what option does it - it's either the EXITCODE with
exit, and or the exception{} blocks, but my .qmail-default is
processeed
entirely.
setting EXITCODE to 99 tells qmail-local (which is what actually
reads the .qmail file) that the delivery is done, it was
successful, and it should stop processing the .qmail file (i.e. don't
go on to the next line.) the exit codes are documented in man qmail-
command.
--
| 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
Re: [vchkpw] OT: tcpserver and rblsmtpd clones
On 2006-10-26, at 1737, David Chaplin-Loebell wrote: John Simpson wrote: i don't really mind either way, but i'd like to know what his policy is, just to be sure. before you pointed out this page this i was not aware of 2007-01-01 having any significance (other than new years day, obviously.) He periodically updates those dates. I think the point is that he doesn't want prerelease versions of his software distributed forever-- but if you check out http://web.archive.org/web/*/http:// cr.yp.to/distributors.html you'll see that those dates have been pushed forward several times. okay. thanks again. -- | 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
Re: [vchkpw] vdelivermail patch in order to handle maildrop filtering capabilities
On 2006-10-25, at 1152, Jérôme MOLLIER-PIERRET wrote: It also has the granularity of a using a mailfilter configuration file for domains (ie /home/vpopmail/domains/onedomain/mailfilter), all domains (ie /home/vpopmail/domains/mailfilter) … and indeed a default one in /etc/mailfilter. what if there happens to be a mailbox with the name mailfilter? (yes, it's a rather contrived example, but you see some really weird stuff when you run an ISP... as an example, we had one user who ran one of the local post offices and wanted postmaster as his userid, the tech support guy who took the signup told him he could have it, and i was the one who got to call him back and explain why he couldn't have it... i ended up telling him it was already used, and that was that. of course for the next three weeks i got a series of who are you? emails to the postmaster mailbox from this guy...) instead of using mailfilter, you should probably use .mailfilter as the filename. names starting with a letter or number should really be reserved for mailbox names. also, what if a user (i.e. the owner of one specific mailbox) wants to create their own .mailfilter file, either directly or using some kind of web interface which gives them a set of options and writes a .mailfilter file based on their choices? i would search for /home/ vpopmail/domains/.mailfilter-userid before the file names you're already checking for. -- | 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
Re: [vchkpw] Re: [toaster] filtering outgoing emails
On 2006-10-25, at 1614, Ingo Claro wrote: Jeff Koch escribió: We are getting demands from large ISP's - Comcast, AOL, ATT - that we spam filter all outgoing email. We're using simscan to filter incoming email but I think that misses email generated by our customers and autoresponders. Can it be accomplished by modifying /home/vpopmail/etc/tcp.smtp ? How are other qmail users handling this? i'm also interested in this feature. Have you found how to filter outgoing messages? for incoming messages I use maildrop you can still use simscan. the trick is to make your customers send their mail through simscan. i always did this by blocking outbound traffic to port 25/tcp at the router, unless the source IP was one of my mail servers. this leaves the users no choice but to use your mail server- and if all of your servers' SMTP services run the messages through simscan, all of your users' outgoing mail will be scanned while coming into your server, and your server will only send the clean mail out to the internet. some users will grumble about it, but once they figure out how to change their settings, most of them will never have to mess with it again. you will find two types of people who need special handling: - some users may be required to use a specific mail server at their office for outbound mail. these users should talk to their company's IT department about how to use an SMTP service on a port number other than 25- preferably one which requires AUTH, and is encrypted. if this is not available, make an exception in your filter which allows outbound traffic to port 25 on that company's SMTP server so that these employees can do their jobs, but you are still blocking outbound traffic to port 25 everywhere else in the world. - spammers who can no longer send mail directly out... these users should die a slow painful death. forcing them to send their outbound mail through your server also allows you to easily track how much mail they're sending- and if your company charges a fee for cleaning up after a spammer (i always charged 10 cents per message) it makes it very easy to document how much spam they sent and know how much to charge them for your time dealing with other ISPs' complaints and getting your servers' IP addresses removed from the blacklists. and yes, the cleanup fee does work, especially if you have a credit card number on file for a customer. we had a user who actually sent almost 3,500 messages out before i locked him out- we charged his credit card $349 and change, and when he tried to challenge it with his bank, we sent the bank a copy of our agreement and a list of the messages he sent- the bank ended up confirming the charge and we did get the money. (this was in florida, usa, the laws may be different where you are.) -- | 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
Re: [vchkpw] Qmailrocks version qmail 1.03 with chkuser 2.0
On 2006-07-19, at 1836, Adriano Frare wrote: How I install path chkuser 2.0 with qmailrocks ? qmailrocks is built around a combined patch file that i wrote. however, it's using a really ancient version of that patch- eric (the qmailrocks maintainer) basically abandoned it for almost a year, and is just now starting to show some interest in bringing things up to date. i have written a patch, which is now part of the combined patch, which uses a validrcptto.cdb file to accomplish the same thing that the chkuser patch does. http://qmail.jms1.net/patches/validrcptto.cdb.shtm advantages: - does not require you to have vpopmail installed before installing qmail - does not require you to re-compile qmail whenever vpopmail is upgraded - does not require the SMTP service to be running on the same machine as the vpopmail mailboxes. you can copy the validrcptto.cdb file to other machines whose only job is to handle the RBL, virus, and spam scanning, and those machines can validate recipients without having to directly consult vpopmail at all. - works with systems which don't use vpopmail disadvantages: - requires you to build a new validrcptto.cdb file whenever a domain or mailbox is added or deleted. i have a patch (the onchange patch) for vpopmail which makes it possible to automate this process. http://qmail.jms1.net/patches/vpopmail.shtml my own server is using the onchange patch, and the validrcptto.cdb file is automatically rebuilt whenever anything changes. i've also written an AUTH_CDB patch for qmail, which allows you to send an auth.cdb file to the same filtering machine (which i have always called a mailhub, but i may be changing my terms before too long) and that machine will be able to also process AUTH commands without consulting vpopmail directly. this is also working well on my own server- my qmail-smtpd does not run any external programs when it receives an AUTH command. i haven't had time to write a full web page to document the AUTH_CDB patch, but i did add a few paragraphs on the page which describes the newest version of the combined patch. http://qmail.jms1.net/patches/combined-6c5.shtml do yourself a favour- read about the patches which are available, think about your situation and what you need your servers to do, and make an informed decision. if you decide to use my patch, i normally answer questions about it on the qmailrocks lists. in either case, good luck with whatever solution you choose. -- | 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
Re: [vchkpw] Real users inside a virtual domain
On 2006-07-27, at 0817, Charles Butcher wrote: A few power users within a virtual email domain have shell login access to the server. I want their mail to be delivered to their home directory, not to a vpopmail account. I also want the .qmail-ext mechanisms to work for them, under their control. i've never gotten this to work, at least not directly... the closest i was able to do was tell them to configure pine/elm/mutt as an IMAP client. i'm the only power user on my server who understands .qmail files well enough to mess with them, and i do my own custom .qmail file edits as root. you may want to try adding localhost to the /var/qmail/locals file (send a HUP to qmail-send) and create a ~vpopmail/domains/ domain.xyz/.qmail-userid file containing [EMAIL PROTECTED], so that their incoming mail is re-delivered to their system userid. -- | 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
Re: [vchkpw] Real users inside a virtual domain
On 2006-07-28, at 1721, Matt Kane wrote: ... why are you replying via private email? this conversation started on the vchkpw list, it should stay there. there's nothing in your message which would justify it leaving the list. I havn't tried this but would it not be possible to simply change where the user home directory is pointed in the vpopmail database? I believe there may be some permission issues but it seems like it could potentially work. may be some permission issues is a major understatement. the vpopmail domain directory and all of its contents are owned by the numeric uid/gid specified in the domain's users/assign entry, which is usually userid vpopmail and group vchkpw. the qmail- local process which handles the delivery process will be running as this uid/gid. this means that the user would have to make their Maildir writable to the vpopmail userid in order for deliveries to be possible. this also means that they could set up a .qmail file which runs an arbitrary command as the vpopmail user, and therefore makes it possible for them to do anything with any mailbox on the system. if i were one of these system users, it would be trivial for me to read anybody's mailbox, or add or delete mailboxes, or reset other peoples' passwords, or if the system admin were stupid enough to use plain-text passwords, i could get a list of the passwords for every mailbox on the system. ten years' of building and running ISP's and mail servers has taught me that there is no such thing as being too careful. i won't say i'm the best in the world at finding security holes, but if i can find something like this, it's a good bet that the black-hat hackers, script kiddies, and other kinds of ankle-biters out there will already have found out about it. the safe and simple way to do it is like i said, forward it to a local address so that the normal qmail mechanisms do the delivery, AS the user's uid/gid. no special permissions are needed, and any scripts that they might add to a .qmail file would run as their own uid/gid, giving them no more access to the system than they would otherwise have. Another trick would be to make a symbolic link in the users folder to link to the system .qmail file. what do you mean by the users folder? and what do you mean by the system .qmail file? -- | 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
Re: [vchkpw] dot-qmail ordering
On 2006-05-13, at 1344, Michael Krieger wrote: I've been browsing the qmailadmin/vpopmail code and see that there's no effort to enforce order in dot-qmail files. Adding lines to a dot-qmail file is just an append to the end of the file it seems with valias_insert and so on [at least in vpalias it is for the files/cdb backend]. I'm looking to add some additional features that depend on order. ... It's the ability to add in a proper order that I'm curious about. this has been a known shortcoming of vpopmail for several years- and in fact it's worse than you describe. if you're using .qmail-* files, the lines in the file are ordered in the same sequence in which they were added. however, if you're storing alias information in a sql database (which a lot of people seem to want to do) there is NO way to force any specific order, since there is no field in the alias table to hold a sequence. Anyone already tried it? Should I give the code a good hacking? See anything else I could affect in doing this? I think it's a really valuable feature, and should be easy enough to implement. this is actually on my list of things to do. it's a non-trivial change: - the mysql and pgsql table schemas will have to be changed to include the new field - the valias_insert() functions in vpalias.c, vmysql.c, and vpgsql.c will have to be changed to include a sequence parameter (i.e. 0 means insert at the beginning of the file, 1 means to copy one line of what's already there before adding the new line, etc... with any number greater than the number of lines currently in the file meaning to append to the file) and the appropriate code to handle that parameter - the valias_select*() functions in vpalias.c, vmysql.c, and vpgsql.c will have to be changed so that they return the alias lines in the proper order- probably no change for vpalias.c, but for the sql-based methods, it means adding an ORDER BY clause to the query. - the valias program will need a command line parameter to specify the sequence number when adding an alias. - we will need a reasonable process to convert people who are already using the sql valias table, so that it contains the sequence field. i can see is a script which looks through all alias lines which have NULL sequences, any aliases which have only one line, set that sequence to 0... otherwise (if it has more than one item) print the email address, which gives an administrator a list of which aliases need to be handled manually (since there is no guaranteed existing order.) - i'm probably forgetting something- anyone? if you have the time and expertise to write the code, that would be awesome... join the vpopmail-devel mailing list and let them know you are going to do this. this list (the normal vpopmail list) is geared more towards people USING vpopmail instead of people who are WORKING ON vpopmail itself, although if you need help testing your patches on different types of machines, this list does have a few people who are willing to help. (my own systems are centos 3 and centos 4, if that helps.) As a side note, in qmailadmin's autorespond.c, shouldn't these be in the opposite order to prevent any temporary failures after closing the .qmail file without the message file existing yet? * Make the autoresponder .qmail file * Make the autoresponder message file makes sense to me. i don't know if there's a dedicated list for qmailadmin developers, i *think* the vpopmail-devel list is used for that as well (since the list of developers on both products is almost identical.) -- | 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
Re: [vchkpw] NFS and vpopmail
On 2006-05-11, at 1800, Jeremy Kister wrote: On 5/11/2006 5:55 PM, MT wrote: sends hup signal to qmail-send to accept new domain So I have /home/vpopmail/domains, /var/qmail/control/, /var/qmail/ users on my NFS. [...] I have to delete / add the domain on 10.0.0.2 to get it to work - but then 10.0.0.1 will give me the same error. Do you have something on 10.0.0.2 that will hup qmail-send when the /var/qmail/users/assign file changes ? you don't need to HUP qmail-send when users/assign changes, you need to run qmail-newu. qmail-lspawn reads users/cdb, users/assign is just a text file which is used to build users/cdb. the only two programs which do anything with users/assign are qmail- newu and qmail-pw2u. -- | 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
Re: [vchkpw] NFS and vpopmail
On 2006-05-12, at 1347, Tom Collins wrote: On May 12, 2006, at 10:22 AM, MT wrote: The qmail-smtpd process doesn't have the correct permissions to read the vpasswd file for the domain (or the vpopmail.mysql file with the MySQL login info). So I'm still reinstalling - nice POS hardware I'm given to use (but that's another story). If anyone could tell me please, what should the permissions be? This is the setup I did: Just make sure qmail-smtpd runs as user vpopmail. are you the one who came up with this idea, or did you get the idea from somebody else? can you explain to me WHY this is supposedly necessary? even when i was using vchkpw to support AUTH, i just made vchkpw setuid so it always runs as the vpopmail user, and left qmail-smtpd running as qmaild, as djb intended. (i'm now using a cdb file to support AUTH- much faster, no fork/exec or userid headaches, and much easier to make it work across multiple servers- just copy the cdb file to the other servers and it's done. patch coming soon.) -- | 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
Re: [vchkpw] NFS and vpopmail
On 2006-05-12, at 1512, Jeremy Kister wrote: On 5/12/2006 3:01 PM, John Simpson wrote: you don't need to HUP qmail-send when users/assign changes, you need to run qmail-newu. qmail-lspawn reads users/cdb, users/ assign is just a text file which is used to build users/cdb. I simply infer that the control files have changed when the assign file has changed. ah... okay, i see. i do the same thing, but i use control/locals and control/ virtualdomains to tell when to send the HUP, since these are the two files which are actually re-read when a HUP is received. actually, i have one script which does it all- compares the timestamps on users/assign and users/cdb and runs qmail-newu when appropriate... the same for control/morercpthosts and control/ morercpthosts.cdb, and it also builds validrcptto.cdb and auth.cdb (both files relating to my patches) as well. i have a daemontools service which waits for input on a named pipe and then runs the updater script (so that any process, running as any userid, can touch /tmp/update-qmail and trigger the updater script), a cron job which does the touch every half hour, and a vpopmail onchange script which also does the same touch operation whenever a mailbox is added, password changed, or whatever. everything pretty much runs itself. -- | 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
Re: [vchkpw] How to bypass quota
On 2006-04-25, at 1245, Olivier JUDITH wrote: I completly agree with you , but imagine that you going on holidays and you receive lot of email during this period . you reach your quota and don't receive mail anymore ? I think it's better to block user for sending but continue to receive mail . what you think about this ? i think if the user knows ahead of time that they will be leaving, they can ask the mail administrators to raise their quota temporarily while they're gone. if they fail to do so and their mailbox overflows, it's their own fault. of course if you do this for a user, find out when they're coming back, and give them a date after they return when their quota will be returned to normal, so that they aren't surprised when their larger quota goes away. of course, don't forget to set their quota back to their normal limit- otherwise the users will get used to the larger quota and come to expect it all the time, which is a good way to fill up a hard drive. -- | 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
Re: [vchkpw] vpopmail Authentication Problem
On 2006-04-19, at 1231, [EMAIL PROTECTED] wrote: I am having trouble with user authentication. I am running Fedora Core 5 on a Dell PowerEdge blade server with the latest (as of a few days ago) versions of qmail, vpopmail, and qmailadmin. specific version numbers? any patches applied on top of the source? I can log into qmailadmin just fine through Apache and I have added a virtual domain and some virtual users. This is reflected in my /var/qmail/ rchphosts and virtualdomain files. It is also reflected in /home/vpopmail/. The passwords for various users work in vpopmail but no where else. I have tried telnetting to port 110 on the box and applying crudentials but it always reports: -ERR authorization failed even for the same [EMAIL PROTECTED] account that you used with qmailadmin? Here are my run scripts. Let me know what other information you require. It may be important to note that this box does not have a FQHN, instead, I have lied to it that it's name is stormtrooper.ucdavis.edu, when there is in actuality another box with that name (our old mail server). I cannot give it that proper name until this box works, because we support hundreds of users and cannot have an e-mail downage. The new blade's hostname is stormtrooper and if I ping that name according to the box it thinks it's 127.0.0.1, so I _think_ it's not a problem. that's an /etc/hosts issue. both of the run scripts are using 0 as the IP address, so the hostname shouldn't be an issue for starting the services. the one thing to note is that when you do throw the switch, i'm assuming that part of the process will be changing the machine's IP address to be the same as the old server... when you change the IP, you should restart any services which are listening for incoming connections. your pop3 service is running as root, so it shouldn't be a permissions issue... very strange. the smtp service is running as qmaild, which means that when qmail- smtpd runs vchkpw, it will try to run vchkpw as the qmaild user, which doesn't have permissions to read the vpasswd.cdb files (which contain the mailbox names and encrypted passwords.) there are two solutions for this problem: (1) run the qmail-smtpd service as the vpopmail user, which can cause issues with other qmail-smtpd add-ons (qmail-scanner, simscan, etc.) (2) make the ~vpopmail/bin/vchkpw binary setuid, so that no matter which userid starts it, it runs as the vpopmail user. # cd ~vpopmail/bin # chown vpopmail:vchkpw vchkpw # chmdo 6711 vchkpw neither solution is the best for everybody- the first one can cause issues with other programs, and the second one opens a hole which could potentially allow a local user to conduct a dictionary attack against mailbox passwords by running vchkpw directly. if you don't allow non-trusted people to run arbitrary commands on your machine (this includes CGI or PHP scripts as part of a web site) then the second option is a non-issue, and is in fact what i've been doing on my own server for several years. however, i have modified qmail-smtpd to check a cdb file when validating an AUTH command. i will be rolling a patch file for it, and writing a web page to document it, later this week. -- | 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
Re: [vchkpw] Re: ONCHANGE behavior
(re-arranging things so the sequence of my answers makes sense...) On 2006-04-15, at 2237, Rick Widmer wrote: John Simpson wrote: if the onchange script needs to know whether the user's request affected a real or alias domain, simply look to see if there IS another domain listed afterward- if so, the first one was an alias and the second one is the real domain that the alias pointed to. is this something that needs to be in there? if so, i'll write it in. I don't see any value in reporting a delete operation after the fact, other than to log it. On the other hand it might be a good idea to move the script before the delete. That would give you a chance to take a snapshot of the resource usage right before delete, or maybe make a backup. good point, i hadn't thought of that. coming soon to a web server near me, onchange.5... I do think it is a good idea to name the parent domain if you delete an alias domain, even if I don't know how someone would use it today. If nothing else it will make my log entries look nicer. If you've already got it worked out, go ahead and send me a patch. If not you've described it well enough, it will be easy enough to do. ewww... the message which makes up the onchange command line arguments (other than the first command name) is a fixed-size buffer. what do you see the output looking like if you delete a physical domain with 50 alias domain names pointing to it? this would cause a buffer overflow unless we write in some kind of dynamic memory allocation function... i can understand this. however, since the call_onchange() function waits for the script to complete, it is up to you as the author of an onchange script to make it run as quickly as possible. as i explained before, my onchange script sends its command line arguments to a named pipe and exits, and the service which is listening to the other end of that pipe does all of the work. I'd rather wait on the entire process to finish so I know there were no errors in the operation before I report the job done. Oh well, it works just fine both ways. Good job! not such a good job- you will notice that somebody reported a bug because my own testing procedure isn't as complete as it should be. there is now an onchange.4 patch, any earlier versions should not be used. thinking about this... one way to handle it would be to have a dynamically sized buffer where messages would be accumulated, a function add_onchange() which adds a line to this buffer, and call_onchange() would be called once to send the buffer contents and then clear the buffer when the operation is done- at the end of a vpopmail command line program, at the end of a vpopmaild command executing, at the end of a qmailadmin request, etc. in theory the buffer could be grown byte by byte as needed, but in practice i would have it allocate 16KB to start with, and if it grows bigger than that, add 16KB blocks as needed. the code would be a little messy (having to dynamically allocate memory when the message gets too big) but it would make it easier to report when alias domains are deleted. with that done, we could add a del_domain line for each alias domain involved, with the last del_domain line being the physical domain name. and then for add_domain, we would have the existing three messages all delivered at once. of course then we run the risk of bumping into the limit of how long a command line can be... i know in linux the limit is 128KB for (command line plus environment). if we're doing a del_domain on a physical domain which has hundreds of alias domain names, this could be an issue... here's another possibility, which makes the 128K command line limit a non-issue: instead of passing information on the command line (which is fairly easy), we can set up a pipe. the child process manipulates its handles so that its stdin is the output end of the pipe, and the parent process sends the contents of the buffer through the pipe. of course then the script becomes more complex, because it has to read and parse stdin to figure out what's going on, and it has to be able to deal with multiple messages in the same invocation. and while i'm in there re-writing things, i think i might move all of the calls which generate onchange messages into the back-end code, just so it's consistent. and i would probably move call_onchange() and add_onchange() to a new source file called onchange.c, with an onchange.h to provide the function prototypes to the other source files... any of these would be fairly major re-writes of the patch, although i can see where it probably needs to be done, and if i'm going to do it, now is certainly the time. thoughts? for me, the trick is dealing with the fact that input may arrive on the pipe at any time- including three notifications within the space of a second. i know
Re: [vchkpw] ONCHANGE in CVS
On 2006-04-16, at 0334, Rick Widmer wrote: John Simpson wrote: On 2006-04-16, at 0050, Rick Widmer wrote: I've just committed John Simpson's onchange patch. I've added the ability to enable it with --enable-onchange-script, and a file README.onchange. cool... except that i've updated the patch twice today, and i'm in the process of building another patch as i type this, and one of those patch updates was because of some very real bugs in my changes to vmysql.c and vpgsql.c. which version did you commit? Its based on 2. 3 doesn't matter to me because you never see add- user or mod-user in an add-domain, or mod-user in an add-user. anything lower than 4 won't compile if you're using mysql or pgsql... and 5 includes your suggestion of moving the del_domain and del_user notifications to BEFORE the damage is done, so that a final backup can be done. good idea, by the way. I've also suppressed a few calls to the script that I considered redundant. which calls, specifically, did you remove? or did you add some kind of mechanism to suppress them, and if so which ones? The ones marked with *. vadddomain example.com ONCHANGE - add-domain example.com ONCHANGE - mod-user [EMAIL PROTECTED] * ONCHANGE - add-user [EMAIL PROTECTED] * vadduser [EMAIL PROTECTED] ONCHANGE - mod-user [EMAIL PROTECTED] * ONCHANGE - add-user [EMAIL PROTECTED] vmoduser -a [EMAIL PROTECTED] ONCHANGE - mod-user [EMAIL PROTECTED] vdeluser [EMAIL PROTECTED] ONCHANGE - del-user [EMAIL PROTECTED] Note that when you mod the user, you still get a mod-user call. Its only suppressed when it is part of add-domian or add-user. how did you do the suppression? that sounds like something which needs to be part of the patch on my site. i know how i would have written it, but it might be handy to know how you did it, so that when people ask me about it (as they are already starting to, on the qmailrocks list) i have some idea of what's going on. and when you did this, did you lock out the possibility of creating a domain with an initial mailbox whose name is not postmaster by forcing the user to assume that every add_domain should be considered to have an add_user [EMAIL PROTECTED] associated with it? Its no worse now than it was before. Still I wouldn't hold your breath on vadddomain changing how it works. I don't support it, and I don't think any of the primary developers will either. If you can get Ken and Tom to ok it, maybe I'll change my mind, but I won't be surprised when they revoke it if I did dare to make that change. it's not about making any kind of change to the existing code- it's about NOT PREVENTING such a change from being made in the future. before the onchange patch, if they wanted to add the ability to create a domain with something other than postmaster as the first mailbox, they could. but with the onchange code modified to suppress these messages, they might not be able or willing to this so because somebody might already have an onchange script which assumes that a postmaster mailbox will be there, and adding such a feature would makes that assumption invalid. it doesn't affect anything right now, but it does prevent a potential feature from being added in the future. as i've said, i have two clients who have given domain admin rights to another mailbox and removed their postmaster mailbox altogether (replacing it with an alias pointing to their own mailbox) so that if somebody decides to try to break into the mailbox, they won't be able to because the mailbox doesn't exist. with microsoft preaching the benefits of renaming your administrator account to something else, i can see more domain administrators wanting to do this. this is exactly why i keep asking for other peoples' opinions about how this should be handled- i don't consider this issue to be decided one way or the other, and yet you have already committed a (buggy) version of it to the CVS server. you mentioned ken and tom, i would like to hear their opinion about this before it goes much further. obviously what's in the CVS right now needs to be updated to version 4 or later because of the bugs, but if ken and tom are in favour of suppressing the messages then i'll write a version 6 which includes the suppression code and we can commit that, so that the CVS version and the version on my web page will be the same (and i'll be able to properly answer questions about it, which is a major concern for me.) i would really rather leave the framework the way it is, instead of buffering a multi-line message while things are running and then dumping it all out at the end. it's do-able, and if the consensus is that it's a better way than what's out there right now, then i will write it... but i think that option is a lot more complicated than it really needs to be. i just had a thought- is there a vchkpw-devel
Re: [vchkpw] ONCHANGE in CVS
On 2006-04-16, at 0822, Rick Widmer wrote: John Simpson wrote: i just had a thought- is there a vchkpw-devel mailing list that this conversation should be moved to? i suspect that most people on the list aren't interested in these kinds of low-level details- or maybe i'm wrong and people are interested? if so, speak up and let us know what you think. we won't bite unless you ask nicely. http://lists.sourceforge.net/lists/listinfo/vpopmail-devel I'm already subscribed... anyone who is interested in following this discussion is welcome there too. joining as we speak... -- | 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
Re: [vchkpw] Re: ONCHANGE behavior
On 2006-04-16, at 0639, Robin Bowes wrote: If you look at qpsmtpd (which is where I believe the idea of onchange hooks came from) not really... it's something i've wished that vpopmail had for several years, but never had the time to write. It also calls different scripts for each hook rather than having one monolithic something's changed script. Would that be a better approach for vpopmail? i don't think so. if you want to use this kind of approach, you can create an onchange script which looks like this: #!/bin/sh if [ -e ~vpopmail/etc/$1 ] then exec ~vpopmail/etc/$* fi logger -t onchange ignoring command $* exit 0 and then create scripts in ~vpopmail/etc with names matching the cmd parameter sent to the onchange script. would it be better to use the vpopmail function names for all of the notifications, so that they are all consistent? if so, now is the time to make the decision, since nobody (as far as i know) has written any onchange scripts which would look for specific strings. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. I don't really care either, but they should be consistent - add_user or user_add, but not a mix. since nobody really cares, i'm just going to leave them the way they are. -- | 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
Re: [vchkpw] Re: ONCHANGE behavior
On 2006-04-16, at 1649, Robin Bowes wrote: John Simpson wrote: On 2006-04-16, at 0639, Robin Bowes wrote: It also calls different scripts for each hook rather than having one monolithic something's changed script. Would that be a better approach for vpopmail? i don't think so. if you want to use this kind of approach, you can create an onchange script which looks like this: #!/bin/sh if [ -e ~vpopmail/etc/$1 ] then exec ~vpopmail/etc/$* fi logger -t onchange ignoring command $* exit 0 and then create scripts in ~vpopmail/etc with names matching the cmd parameter sent to the onchange script. That will still exec the script for every OnChange event. exactly. the original concept was to modify vpopmail itself as little as possible, and any customizations would be done by the scripts, outside of vpopmail. besides, i don't really want to hard-code 15 different script names into the source code, and deal with the resulting confusion. would it be better to use the vpopmail function names for all of the notifications, so that they are all consistent? if so, now is the time to make the decision, since nobody (as far as i know) has written any onchange scripts which would look for specific strings. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. I don't really care either, but they should be consistent - add_user or user_add, but not a mix. since nobody really cares, i'm just going to leave them the way they are. Ahem, I said I didn't care as long as they were consistent! okay... you seem to be the only person with strong feelings about it. cool by me. i'm not doing anything with the messages yet (and for my needs i don't really need to), the onchange script on my server is very simple: #!/bin/sh PATH=/usr/bin:/bin logger -t onchange $* echo $* /tmp/update-qmail the list of messages and parameters is on the web. send your changes to me on the vpopmail-devel mailing list and i'll update the code. http://qmail.jms1.net/patches/vpopmail-onchange.txt -- | 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
Re: [vchkpw] How to bypass quota
On 2006-04-14, at 0426, Olivier JUDITH wrote: I use qmail + vpopmail + courrier-imap ... and i have activated quota for each users to 100M . It work fine fine but, some users would like to be prevent when their Maildir box size is greater than quota and continue to receive their mail. Can i do that ? so what you're saying is that some users want to have no quota at all. that's almost always more of a business decision than a technical decision. the technical end is easy- change or remove the quota as needed. however, somebody with authority has to decide that it's okay to do this. and if the powers that be decide that they don't want to allow this, or that they will if the client pays more money, but the client doesn't want to pay, then the client needs to learn to not leave so much of their mail on the server. if they don't move some of their stored messages off of the server, then the quota mechanism will continue to block incoming messages when their mailbox is full. somebody with the appropriate authority needs to make a decision... the options are to raise or remove the quota for that mailbox, or tell the user to do a better job of managing their quota. -- | 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
Re: [vchkpw] Force Auth from all but localhost
On 2006-04-14, at 0338, Sascha Ebach wrote: how can I enforce that everybody (except localhost) has to authenticate via smtp auth. my combined patch, version 6 or newer, includes this functionality. http://qmail.jms1.net/patches/combined.shtml you can export a REQUIRE_AUTH=1 environment variable in the /service/ ___/run script to enable this for all IP addresses, and then add ,REQUIRE_AUTH=0 to the end of the appropriate line(s) in the tcpserver access control file (which is usually /etc/tcp/smtp or /etc/ tcp.smtp.) be sure to read the entire page- there are a LOT of patches rolled into the combined patch. you may find other features that you would like to use, or you may find features that you don't need. for the most part, i tried to add the patches in such a way that if you don't activate them (by creating a certain file or a certain environment variable) qmail will act as closely as possible to the way djb's original qmail programs act. and if you have any questions about it, feel free to ask- either use this list, or use the qmailrocks.org mailing list (but not the qmailrocks.org install directions... there are easier ways to beat your head against the wall.) -- | 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
Re: [vchkpw] Force Auth from all but localhost
On 2006-04-15, at 1003, Remo Mattei wrote: John Simpson wrote: On 2006-04-14, at 0338, Sascha Ebach wrote: how can I enforce that everybody (except localhost) has to authenticate via smtp auth. my combined patch, version 6 or newer, includes this functionality. http://qmail.jms1.net/patches/combined.shtml I wonder if you have a similar patch like chkuser in your combined patch. i wonder why you haven't read the web page to see if it's in there or not. -- | 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
Re: [vchkpw] ONCHANGE behavior
On 2006-04-15, at 1756, Rick Widmer wrote: Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.) i noticed that in my testing... once is to add the domain itself, once to add the postmaster mailbox, and once to set the quota for the postmaster mailbox. (vauth_setquota calls vauth_setpw, and i wanted vauth_setpw to trigger the notify because i'm building an auth.cdb of mailbox names and passwords, and need to rebuild whenever a password changes.) maybe vauth_setpw() could be modified to only call call_onchange() if the PASSWORD field was changed... but there may be future uses of the onchange mechanism where people may want to track quota changes as well, so i'm not convinced that's a good idea either. i'm thinking it would limit the future flexibility of the onchange mechanism if we remove this notification, and i'm all about maximum flexibility. and if this means that adding a domain results in the onchange script being run three times, that tells me that the onchange script needs to do little more than send a signal somewhere, and some other process needs to do the real work so that whatever program called the vpopmail library functions can get back to doing its thing. At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. honestly, what i'm doing with the onchange script is simple: echo $* /tmp/update-qmail where /tmp/update-qmail is a named pipe. i have a daemontools service which waits for input on this pipe, and does its thing (checks the timestamps of various files and runs qmail-newu if needed, runs qmail- newmrh if needed, sends a HUP to qmail-send if needed, rebuilds validrcptto.cdb if needed, and now rebuilds auth.cdb if needed) after a five second delay. this means that unless something is really slow on the system, the first notification will cause the work to be done after the third notification has been sent. which means that whatever smarts are needed in order to prevent a certain piece of work from being done twice, would need to be done within the onchange script itself, or within whatever process the script sends its signal to. i'm currently doing this using the five- second delay before starting work, and then reading and ignoring any pending data on the pipe when that first work unit is done. however, i plan to teach the service to recognize the patterns, so that if it sees an add_domain xyz, it will ignore any add_user [EMAIL PROTECTED] and mod_user [EMAIL PROTECTED] messages which arrive less than ten seconds later. in any event, i think that the add_user notification for the postmaster mailbox itself needs to stay there. i have seen some really strange situations... many times i've seen people delete postmaster mailboxes after using vusermod to give some other mailbox domain-admin rights, under the theory that by using a different name for the postmaster account, they are preventing a dictionary attack on the postmaster password from succeeding (which is the same idea as renaming the Administrator account on a windoze machine, and done for the same reasons, usually by windoze administrators who are learning about security through a trial by fire.) and who knows, at some point in the future, the idea may catch on and we may want to allow a way to create domains with the first mailbox (which has domain-admin rights) having a name other than postmaster. writing onchange scripts which assume that every add_domain involves a mailbox named postmaster makes this kind of change harder to do. having two onchange calls, one for the domain and one for the mailbox, makes it possible to write this kind of change without having to worry about peoples' existing onchange scripts- just have the one for the domain ONLY do the activities needed to create a domain in whatever external system you are updating, and have the one for the mailbox ONLY do the activities needed for creating a new mailbox. i'm all about maintaining as much flexibility as possible. my recommendation is to leave it the way it is. Finally, is there anything I should add to the readme file? ... This is based on the onchange.2 patch by John Simpson. Rick Widmer changed ./configure.in so the onchange code is only compiled when specified at ./configure time. -- - Is there anything else I should do with 5.5 before I try
Re: [vchkpw] Re: ONCHANGE behavior
On 2006-04-15, at 1917, Rick Widmer wrote: Robin Bowes wrote: I must admit I've not actually looked at John's code. However, my thoughts (based on your comments) are as follows: add_user should be called as well as add_domain when a new domain is created - these are separate actions that happen to both occur when you first create a domain. I can see that, on the other hand you already know when you write your response to an add_domain that the postmaster user was created. Do you really need to exec the script a second time to handle the postmaster as a separate operation? There is quite a bit of overhead with PHP and Perl starting up the script. (I'll be using PHP.) for now, you know that a postmaster mailbox was created. this may change in the future, if the idea of using a name other than postmaster catches on (as it is starting to, especially among windoze admins who are just learning that it's a good idea to change their Administrator accounts to have some other name.) i think it makes sense for the add_user notification to be separate from the add_domain notification. I don't really have a problem with both mod_user and add_user triggering in an add_user operation. What happens to cause mod_user to trigger as well as add_user? I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database. i just walked the code- after vadduser() actually creates the mailbox, it sets a quota, which calls vauth_setquota(), which calls vauth_setpw() to re-write the vauth entry with the shell field (which contains the quota) changed. they're showing up out of order because i'm calling call_onchange() at the very end of vadduser(), when it should probably happen right after the call to vauth_adduser() and before the call to vauth_setquota(). rick, i've just updated the patch so that it happens in the correct order. there is now an onchange.3 patch, and for your use, there is an onchange.2-3 patch which just moves the code. the direct URL for the upgrade patch is... http://qmail.jms1.net/patches/vpopmail-5.4.15-onchange.2-3.patch Why do you want to change this? Because it seems wasteful to me to call the script three times just to add a domain, or twice to add a user. In the case of the user the mod_user comes before the add_user, so the user data is not completely updated when the script is called for mod_user. By the time the script is called for add_user the mod_user data is available so you can look it up and act accordingly. Specifically when the initial mod_user exec happens the quota, sqwebmail_pass file, and last_auth processing has not been done yet. (Possibly more, I did not trace out the vauth_adduser() call that actually does the work.) i can understand this. however, since the call_onchange() function waits for the script to complete, it is up to you as the author of an onchange script to make it run as quickly as possible. as i explained before, my onchange script sends its command line arguments to a named pipe and exits, and the service which is listening to the other end of that pipe does all of the work. for me, the trick is dealing with the fact that input may arrive on the pipe at any time- including three notifications within the space of a second. i know that (for my purposes) if an add_domain xyz message arrives, for example, that i can wait 10 seconds before doing anything (to give the vpopmail program time to finish and send any other messages), and that any add_mailbox [EMAIL PROTECTED] or mod_user [EMAIL PROTECTED] messages which arrive less than 5 seconds after i'm done can be safely ignored. What is the problem you are trying to solve? No real problem, just something I consider wasteful of resources. For example, if all you are doing is rebuilding a validrcptto database currently you are doing it three times every time you add a domain. Two of them are instantly thrown away as soon as they finish. actually, i'm not- but you do have a point. whoever writes an onchange script does need to worry about this issue- but i don't think it's right to give up the flexibility in order to not have to write proper onchange scripts. add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or mod_alias_domain (not sure if these two would be necessary)? Delete of an alias is done with del_domain, naming the alias. Mod_domain might be valuable. There may be a problem here since you can't tell from the script if it is an alias or a whole domain. Maybe it should name the parent domain if an alias was deleted, or name the aliases if the parent is deleted. or name both the alias and the real domains if an alias is deleted, as opposed to naming just the real domain if a real domain is deleted. basically, the first word after del_domain
Re: [vchkpw] ONCHANGE behavior
On 2006-04-15, at 2152, Rick Widmer wrote: Rick Widmer wrote: John Simpson wrote: (1) please include the URL http://qmail.jms1.net/patches/ vpopmail.shtml in the file, so that poeple can easily find the documentation i have written (and will be maintaining) for it. i'll be watching this mailing list for any problems which people may have with it, and if any problems seem to show up on a regular basis, i will write a FAQ for those problems, either on this page, or as a new page linked from this one. I will certainly add the URL to the README file, but I believe once it becomes part of vpopmail it needs to be fully documented within vpopmail. i agree, it certainly needs to be documented there- especially once it becomes part of a non-beta version. however, until then (and afterwards) i want to make sure that everybody using the patch is aware of where it started, and can avail themselves of whatever other documentation i may add to it in the future. i can see this not being necessary at some point in the future, but i would like my URL to stay in there because not everybody in the world is going to upgrade right away, and i plan to continue to offer the patches for the benefit of people who may not want to fully upgrade to a newer version of vpopmail. (i know, who would be that crazy, but remember- a very high percentage of my site's visitors find me because of qmailrocks...) -- | 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
[vchkpw] bug found in vdominfo
while trying to answer a question on the qmailrocks list about a problem with vchkpw, i noticed a problem with the vdominfo -n command... when listing domains, it doesn't list alias domains correctly. instead of aliasdomain (alias of realdomain) it's showing realdomain (alias of realdomain). i wrote a patch which fixes the problem, and added a section to my vpopmail patches web page which illustrates the problem and has the patch file for download. http://qmail.jms1.net/patches/vpopmail.shtml -- | 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
Re: [vchkpw] rblsmtpd with vchkpw
On 2006-04-05, at 0002, Fernando Milovich wrote: I mean bypass RBL is the client is authenticated. But it seems to be no possibly. This problem is because our customers use ISP connections like ADSL and Dial Up and these connections are blocked by CBL at spamhaus.org I think i´ll have to change the RBL checker. set up a second SMTP service for your users. it should not use port 25, it should not accept mail at all unless the client has sent a successful AUTH command, and it should not accept an AUTH command unless the connection is encrypted (via SSL or TLS.) depending on the qmail patches you are using, the second and third conditions may not be possible for you- but the first condition, running an SMTP service on some other port, anybody can do. usually the biggest mental hurdle is realizing that it is possible to run multiple SMTP services on the same machine. just take the run script from your existing service and copy it to a new service directory... change the port number from 25 (or smtp, if that's how it's listed in your file) to 587, and fire it up. or run it on port 465, substitute sslserver for tcpserver, make a key pair, and you're up and running with an SSL-secured SMTP server. http://qmail.jms1.net/smtp-service.shtml is a web page i wrote which explains how to set up SMTP services. it's slanted towards people who use my combined patch file (which you may want to take a look at- lots of tasty goodies in there) but the basic idea is the same for any qmail system- you can have as many SMTP services as you need, as long as each one has its own IP/PORT combination. it may contain some helpful information, and it certainly explains things in more detail than this message. enjoy. -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-03, at 1442, John Simpson wrote: On 2006-04-03, at 0727, Rick Widmer wrote: 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.) actually, README.vpopmaild DID have a mention of long_name, i had just never noticed it. the updated version of README.vpopmail on my web site now does not have this, and there is also a vpopmail-5.4.15-cslogin.2.patch where the add_user code no longer looks for a gecos name. when it calls adduser() to create the mailbox, it passes the mailbox name as the gecos name, so the new mailbox will have the same name as the mailbox itself. -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-02, at 0809, Rick Widmer wrote: Robin Bowes wrote: So, a system only needing to validate credentials would just need to login and quit. Which is what slogin will do. You may not even have to quit. It could just return OK or ERROR, and exit. I'm not sure what John did, but he already has a patch to do it this way. slogin is the same as the other two login commands- it logs into vpopmaild. the only difference is the amount of information returned. none of them will automatically quit after authenticating, that's why there is a quit command. ... What do you think? The changes might be a good idea if we were designing a new program, but vpopmaild is about two years old, and I believe Ken has been using it on at least one production site almost that long. I suspect there are others. good point. when writing patches, for vpopmail, qmail, or anything else, i try to minimize the impact of those changes to only what is absolutely necessary to support the new feature or bug-fix for which i am writing the patch. the last thing i want to do is break anybody else's existing code- although if there's a good reason (like passwords containing spaces) then i will do so, and i will make sure that the documentation i make available for my patches (in this case, the web page) clearly sets out the differences, so that people like rick will know what's going on and (hopefully) be able to make their existing code work with the new stuff without a major hassle. for what it's worth, i think if i were writing vpopmaild from scratch, login would do what slogin does, and the client would have to send user_info to get the information it needs. -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-02, at 0829, Rick Widmer wrote: John Simpson wrote: On 2006-04-01, at 0547, Rick Widmer wrote: I was planning if you would like a way to see if a user exists without returning anything else... that's certainly a possibility, easy enough to add... should that be available to any client without authenticating first? or if it requires an authenticated session, should it be available to any user, or just the domain-admin for that domain, or only for a system- admin? I think it should just take any user/password combination and return OK if the user exists or ERROR, then exit. If you need to login to find out if a user exists programs will have to have login credentials in the script. Not a good idea. 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? if it's a simple existence check, do you want that information available to any client who connects to the service? especially if you are running the service on a non-localhost interface (or on 0.0.0.0) and aren't using a tcpserver access control file? i'm not against it, i just think if we're going to add something like this, the documentation for creating a vpopmaild service should mention, 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. http://qmail.jms1.net/patches/vpopmail.html I haven't been able to access the SourceForge CVS server for the last two days. I think they may have changed the rules, and may have found what I need to do in the docs... which is what I was doing when I stopped to answer these messages. I'll try to have this in 5.5 within a few days. I still need to see just what is different between 5.4 and 5.5. it just occurred to me, i had never looked at the list of developers for the sourceforge page, i figured it was just inter7 people. i didn't realize you were able to commit code (when the CVS servers are working)... coolness. -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
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. i'm not against it, i just think if we're going to add something like this, the documentation for creating a vpopmaild service should mention, 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-03, at 0824, Robin Bowes wrote: Rick Widmer wrote: 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. Yes - having this functionality would obviate the need to maintain the validrcptto list. Any tool that wants to check the existence of a mailbox for a given email address on a given host would just need to telnet to port 89 and supply a command like exists [EMAIL PROTECTED]. the problem is that validrcptto.cdb doesn't check mailboxes- it checks recipient email addresses. mailboxes are recipients, yes, but other things can be valid recipients as well- aliases, certain flavours of anything (in case of a .qmail-[something-]default file or a domain with a non-bounce catch-all setting), and some people have custom requirements where they want to control which addresses can receive mail from outside. An OK responose would mean it does exist. It should not quite automatically to allow the checking of several addresses in sequence, e.g: connect exists [EMAIL PROTECTED] exists [EMAIL PROTECTED] exists [EMAIL PROTECTED] quit this is known as a dictionary attack (or a bad thing.) it allows the attacker to enumerate which email addresses do and don't work on your server. this used to be a major strategy of the wily spammer, but most mail servers now take steps to prevent it. however, i have seen a few people try it on my own server (and promptly blacklisted those IP addresses.) Does vpopmaild fork? i.e. Does it allow multiple connections? I guess it uses tcpserver to run it so tcpserver will do all the work. Cool. that's it exactly- tcpserver handles all of the networking stuff, vpopmaild is just talking to stdin/stdout, with log output going to stderr. makes it really easy to write server programs. -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-03, at 1159, Tom Collins wrote: On Apr 3, 2006, at 5:24 AM, Robin Bowes wrote: Rick Widmer wrote: 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. Yes - having this functionality would obviate the need to maintain the validrcptto list. I'm not following vpopmaild development, so ignore me if you've already considered this, but you should be sure to support quota checking through that interface as well. Doing so would allow a patch to qmail-smtpd to reject email for non- existent users and defer email for users over quota. good point, but it's a non-issue. the validrcptto.cdb functionality is not going to be bundled into vpopmaild, the two programs are not doing the same things. and besides, if a user's mailbox is over quota, i would rather keep the message in my local queue where it will be delivered rather quickly when the user finally brings their mailbox back below their quota (and where i can send an ALRM signal to qmail-send to force- deliver the message when they call me about it, because they don't want to wait a few hours for qmail-send to decide to deliver it on its own.) -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-03, at 1609, Robin Bowes wrote: This is how I've implemented a plugin for qpsmtpd that auths against vpopmaild. It's extremely easy: # create socket my $vpopmaild_socket = IO::Socket::INET-new(PeerAddr = vpopmaild_host, PeerPort = vpopmaild_port, Proto= tcp, Type = SOCK_STREAM) or return (DECLINED); right here, you should read a line of input from the server and make sure it matches /^\+OK/. otherwise... # send login details print $vpopmaild_socket login $user $passClear\n\r; # get response from server my $login_response = $vpopmaild_socket; this read, being the first read since the client connects, will return the +OK line that the server sends when you first connect to the service, rather than the +OK or -ERR response from your login command. you should also wait for the command to end (if the response was +OK +, read lines until you see one which matches /^\.$/), then send quit\n, then wait for the +OK response. otherwise you are writing sloppy code which doesn't follow the protocol, which only encourages others to do the same. Of course, qpsmtpd is written in perl so this sort of thing *is* pretty easy! i love perl. if i ever meet larry wall, i owe him a beer. 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.) You really should check out qpsmtpd. It can handle several auth types easily. if it were for my own server, sure... but i'm releasing patches for people using qmail-smtpd. if i were to suddenly switch to qpsmtpd it would be like abandoning everybody else who is using my qmail patches, including all of my clients. besides, qmail-smtpd is compiled, where qpsmtpd is interpreted and requires the perl runtime and a bunch of libraries. i tend to think in terms of mail servers which may be handling literally hundreds of SMTP requests per second. -- | 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
Re: [vchkpw] rblsmtpd with vchkpw
On 2006-04-03, at 1024, [EMAIL PROTECTED] wrote: Hi, there is any rule to put in ~vpopmail/etc/tcp.smtp for one user has been authenticated not be IP checked on rblsmtpd ? if by authenticated you mean that their IP address matches a certain line, yes. the example you include... 111.111.111.111:allow,RBLSMTPD= does exactly what you're asking about. the rblsmtpd program will bypass the RBL checks and just continue on to qmail-smtpd if it sees a RELAYCLIENT envrionment variable, or an RBLSMTPD variable whose value is empty. http://cr.yp.to/ucspi-tcp/rblsmtpd.html explains how this works. however, if by authenticated you mean that the client has sent a successful SMTP AUTH command, no. the AUTH command is processed by qmail-smtpd, while rblsmtpd runs before qmail-smtpd. this means that any RBL checking is done, and blocking (if appropriate) happens, before the client would have a chance to enter an AUTH command (or any command at all, for that matter.) -- | 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
Re: [vchkpw] Re: 5.4.15 onchange patch
On 2006-04-01, at 0547, Rick Widmer wrote: John Simpson wrote: let me suggest an alternative- instead of login user pass compact, how about login/compact user pass? this allows the password to be the last thing on the line, and therefore contain spaces, and still allows for a compact option. What do you think about login | clogin | slogin? sounds good to me, as long as it's consistent and documented somewhere- both in README.vpopmaild and in the vpopmaild wiki entry. I was planning if you would like a way to see if a user exists without returning anything else... that's certainly a possibility, easy enough to add... should that be available to any client without authenticating first? or if it requires an authenticated session, should it be available to any user, or just the domain-admin for that domain, or only for a system- admin? any thoughts? if needed, i will write the patch to make this happen- let me know. If you write it and send it to me I'll make sure it gets into 5.5. You can choose between login/compact | clogin | login password with spaces compact. I like clogin best because I'm lazy... :) i'll go with clogin and slogin. i'm also going to look at the code which parses the line and make sure that when it's looking for a password, it doesn't stop on spaces. i would also like to see the output from the help command trim itself to the set of commands which are actually available to the client- before login, for example, the list would have login, help, and quit, and would not disconnect the client (as it does now.) for a normal user it would only show the commands relating to their own mailbox without any admin-level commands, for a domain admin it would show the domain-level commands but not the system- admin level stuff, and so forth. this is also a patch i am willing to write, if there is any interest in it. That sounds like a good idea too. If you do it, please consider making it so help before login is allowed, and only lists the three login commands. Then once you are logged in expand the help list based on the user's rights. Right now help before login sends the help list and disconnects. i've written what i call the cslogin patch, which does the following: - adds the clogin and slogin commands - fixes the parsing so passwords in the login, add_user, add_domain, and mod_user commands include everything out to the end of the line - makes the help command adjust itself to the access level that the client currently has. 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 -- | 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
