Re: [vchkpw] Deleting primary domain; keeping alias domains
> 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've actually done this before (using the MySQL back-end), but it's not
pretty. First off, you pretty much have to turn off mail services while
you do this, or you're gonna lose mail. Have a secondary MX hold delivery
if you have one, but it's probably even better to just not accept any
inbound connections to the servers that are listed as MXs for the domains
in question.
The way I did it was as follows:
0) Take a backup of absolutely everything related to your mail server and
keep it handy (but also create an offline copy for safekeeping).
1) Delete the alias domain that you want to become primary - I know this
sounds counter intuitive, but you MUST remove it before you can change the
old primary to the new one.
2) Rename the domain directory in vpopmail/domains to match the new primary.
3) Change all references from the old primary to the new primary in the
vpopmail DB. IOW, it's a global search and replace.
4) Change all references from the old primary to the new primary anywhere
you find it in /var/qmail/{alias|control|users}
5) Triple-check that there are no more references to the old domain
ANYWHERE in the control structure for qmail, vpopmail, and any other
things you use. For example, a spamassassin or squirrelmail preferences
DB.
6) Once you have completely changed everything, restart local delivery and
inject a test message to the queue. If that works, start up SMTP locally
(set up an SMTP instance on localhost for testing if you can, otherwise
use a firewall or temporary tcprules file to deny access from the outside)
and test sending a message all the way through. If that works, test any
other services you provide (POP/IMAP/Webmail etc.) to make sure that they
all work. Assuming you don't have any problems, open things up to the
outside world.
7) KEEP A CLOSE EYE ON THINGS FOR AT LEAST 48 HOURS - sometimes you miss a
tiny thing and it won't show up right away, so be on the lookout for
weirdness.
One last thing - just to be clear. I did this for a small domain with
only a couple of users on a server that wasn't very busy and that I had
total control over. I also had the luxury of being able to lose a little
mail because we were in test mode at the time so that was acceptable. I
make NO GUARANTEES that this will work without problems in a production
environment. When in doubt, DON'T DO THIS.
Now, if you just want to stop receiving email for the primary domain and
not delete it completely, take your server out of the MX entry, point the
domain A record somewhere that doesn't accept mail, and/or add the domain
to qmail's badmailto file (assuming you have that patch installed).
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
j...@honorablemenschen.com
!DSPAM:49c110ff32682048076310!
Re: [vchkpw] Re: vpopmail FHS compliance
>> proftpd-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) >> proftpd-ldap-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) >> proftpd-mysql-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) >> proftpd-postgresql-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) > > Again, I'm not sure how this makes it much easier for people packaging. > Even if you went with the module system, you'd have to compile each > module seperately. The packages above, even at the very least, provide > a new module. The same could be done by ./configure > --enable-auth-module=x > && make. > Matt, The trick here is that by separating out the back-end authentication schemes into modules, you can provide a single source build for package maintainers, which will generate multiple component packages for the whole setup. Then they don't have to maintain separately configured source trees and builds for each authentication module, but can do a single build that can be configured at runtime to use any available (i.e., installed) module. The user then can install just the module(s) that they want and configure them at will without having to uninstall and then install the new package. > If you were to provide authentication packages for vpopmail, they'd > replace > libvpopmail and the binaries. For the 5.5 tree, you can link against the > shared object files if you choose to as well, meaning packages would only > need to replace libvpopmail.so, or even just a symlink to a different > library. > Again, the authentication modules would be removed from libvpopmail.so, and libvpopmail.so would load the appropriate library (e.g. libvpopmail_.so) based on the vpopmail configuration. > Modules are not out of the question, but I'm not shooting for them in the > near > future. vpopmail as a project just doesn't need them very badly right > now. > I think that depends on the direction that you want to take vpopmail in. If you're just aiming to update the code, fix bugs, and add needed functionality, then you're probably right. If you're looking to expand the scope of vpopmail usage and deployments (which binary packages will inevitably do as users who don't want to custom-compile things start making use of it), then modularizing the authentication systems is probably the second most important thing to do, after fixing any bugs that might be lurking in the code right now, especially in the back-ends. Also, by creating a modular vpopmail-backend API, you could even break the authentication components out of the vpopmail code tree so that other people could easily maintain and even add new back-end support. Again, I don't know what your goal is, so that will certainly influence how you want to prioritize things. > If someone wants to write a patch against the 5.5 tree, I'll look into it > and > if the code is done well, I will consider adding it, but it was not in my > plan > for 5.5. Fair enough. I can't remember if you've done it or not, but if you haven't you might want to consider posting a to-do/wish list/roadmap for vpopmail development so that people can assist with and/or comment on where things are going. Thanks for working to make vpopmail better! Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:49c1187a32689657416453!
Re: [vchkpw] Deleting primary domain; keeping alias domains
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Joshua Megerman wrote: >> environment. When in doubt, DON'T DO THIS. >> >> Now, if you just want to stop receiving email for the primary domain and >> not delete it completely, take your server out of the MX entry, point >> the >> domain A record somewhere that doesn't accept mail, and/or add the >> domain >> to qmail's badmailto file (assuming you have that patch installed). > > While there are several ways to rename a domain, which is essentially what > is > being done here, the best question to ask one's self before beginning this > very manual process, is if you NEED to, and if you have the experience > with > your backend database selection, and with qmail. > > The only time you really NEED to do this is if the domain is hosted on a > remote > site now, and the users of this system need to be able to email the remote > system. If your users of this domain own both domains, and simply want > the > new domain to 'be their primary', just tell them it's done, and to use the > new domain name and leave everything as it is. > I totally agree - in my case I was hosting a subdomain of a domain that the company wasn't renewing the registration on and I really didn't want to be hosting a domain we didn't own anymore. Plus like I said it was small and still in testing (the decision to not renew the domain (and migrate the process to the other one) was made after the initial setup was completed with the original domain) I figured the worst case scenario was to delete the whole thing and start from scratch :) > The instructions above look correct by the way :) Thanks! Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:49c1313232684641599795!
Re: [vchkpw] Re: vpopmail FHS compliance
> Josh > > thanks for explaining the things for me, my english is not good > You're welcome. > making vpopmail support loadable module support will bring vpopmail > into linux distros (fedora, opensuse, mandriva) and probably others > and make the vpopmail userbase grow. > Well, that's a rather simplified statement. After all, since vpopmail is currently tied to qmail, you also have to get qmail into the linux distros, and while much easier now that qmail is Public Domain, it's still not as simple as that given the current state of qmail and patches. But it is a step in that direction... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:49c131df32681438719974!
Re: [vchkpw] Re: vpopmail FHS compliance
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Joshua Megerman wrote: >> The trick here is that by separating out the back-end authentication >> schemes into modules, you can provide a single source build for package >> maintainers, which will generate multiple component packages for the >> whole >> setup. Then they don't have to maintain separately configured source >> trees and builds for each authentication module, but can do a single >> build >> that can be configured at runtime to use any available (i.e., installed) >> module. The user then can install just the module(s) that they want and >> configure them at will without having to uninstall and then install the >> new package. > > I see. That makes a bit more sense. I don't maintain any binary package > distributions, so I'm not really familiar with the process. My > assumptions > about it were incorrect I guess :) > No problem - I don't do any package maintenance myself either, but it's always frustrated me that vpopmail could only support one back-end at a time, and that it was allmost all configured at compile-time... >> Fair enough. I can't remember if you've done it or not, but if you >> haven't you might want to consider posting a to-do/wish list/roadmap for >> vpopmail development so that people can assist with and/or comment on >> where things are going. Thanks for working to make vpopmail better! > > I'll probably look into what it will take to move the authentication > backends into modules for the 5.5 branch. > > Thanks for your input. You're welcome - I don't have a lot of time for coding these days, but I've invested enough time in qmail/vpopmail that I want to see them succeed :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:49c132a332681600362347!
Re: [vchkpw] Re: vpopmail FHS compliance
> that's a great , but qmail is no more maintaned (no new features) > > will be a good ideia to make vpopmail more compatible with postfix and > maybe others MTA's > Ad that, my friend, is a horse of a totally different color. To the best of my knowledge there is no plan to make vpopmail work generically with MTAs other than qmail (Matt, please correct me if I'm wrong), as it currently is integrated rather tightly with how qmail does things. While I'm not disagreeing that expanding vpopmail's compatibility with other MTAs would expand it's acceptance, I also don't really see it happening without a complete internal rewrite to how vpopmail does things. Maybe something to roadmap for vpopmail 6? In any case, I wouldn't hold my breath :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:49c13c2332681437819685!
Re: [vchkpw] regarding qmail tap archiving
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Karpaha Vinayaham wrote: >> Hi >> >> If anyone know how to tap the bounce message please share it, i am >> interested in analysing my bounce messages. > > qtap does not distinguish between message types. It's just a patch to > qmail-queue, and so, it doesn't have a way to tell the difference between > a bounce message and any other message. > > What you need is a message classification program. > - -- Alternately, you can use the BOUNCEQUEUE patch from qmail.org on your main qmail instance, and then set up a secondary qmail instance that taps everything, and set the BOUNCEQUEUE environment variable to that second (tapped) instances qmail-queue. You'll need 2 different qmail-homes, as various pathings are hardcoded at compile time, but it will do what you want. I've got something similar going on where I have an 'in' and an 'out' instance of qmail on a gateway box, and the BOUNCEQUEUE for each is set to the opposite queue. I also have a homemade filter program in place that drops spam bounces that were rejected by the main server (M$ Exchange IMF) but have faked sender addresses and would bounce back in as a joe-job, but I don't recommend that piece as it's a direct RFC violation :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:4a8ac23132715398115266!
Re: [vchkpw] Failure to update tcp.smtp - No authorized relaying for roaming user!
> @James: I used 'find' to look for both tcp.smtp and tcp.smtp.cdb, and > found > only two: the one in /etc, and the one in /home/vpopmail/etc. None of > them > get updated when I authenticate. > tcp.smtp does NOT get updated by vpopmail, only the tcp.smtp.cdb file does. The tcp.smtp file contains the static list of relay addresses, and is combined with a dynamic list maintained by the back end to build the tcp.smtp.cdb file. The pop-before-smtp stuff is maintained separately depending on what backend you use (the open-smtp file for cdb, in the SQL db for others) - grep for the UP in the actual CDB file to see if it's being updated or not. But as others said, don't use pop-before-smtp, use SMTP AUTH. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics vpopm...@honorablemenschen.com !DSPAM:4af9c12032714672444735!
RE: [vchkpw] vdeliver perimission denied for vadddomain -u
> Of-course. Restarted several times just to make sure.I've even rebooted > the machine (just in case). > the process starts with uid/gid 0 (root): > 1349 ? S 0:00 /usr/local/bin/tcpserver -v -R -l localhost -x > /usr/local/hcp/vpopmail/etc/tcp.smtp.cdb -c 30 -u 0 -g 0 0 smtp > /usr/local/hcp/var/qmail/bin/qmail-smtpd localhost > /usr/local/hcp/vpopmail/bin/vchkpw /usr/bin/true > Still no go. > Any other things to look at? > Cheers,Michael. > qmail-smtpd doesn't run vdelivermail - qmail-local does (which is started via qmail-lspawn, which is started by qmail-send). Running qmail-smtpd as root won't fix this. Unfortunately, I believe you need to make vdelivermail run as root to make this work, possibly via suid, but I can't be certain of that. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics vpopm...@honorablemenschen.com !DSPAM:4b140e7732718365620435!
Re: [vchkpw] vpopmail + Dovecot + CRAM-MD5 problem
>> Did you perhaps mean to have vpopmail store the user passwords in >> plain text? I'm just checking, because to me it seems to lower >> security and it seems to defeat the purpose of working with hashed >> passwords. Could you please confirm this? > > Yes, thats what I meant by my comment. You need the plain text passwords > in the vpopmail database. Having plain text passwords in the database > doesn't necessarily lower the security as your database can be on a host > which is not accessable to anything by the authenticating machine. > Just to elaborate on the point, CRAM-MD5 authentication REQUIRES that the passwords be stored as plaintext, as that's the only way to verify the MD5 hash provided by the client. Server send the seed string, client concatenates the seed and password (and maybe username, don't remember), and sends the MD5 hash of that. Server then concats the seed it sent with the known plaintext password and compares the MD5 hash it comes up with to that which the client sends. It's a tradeoff - keeping plaintext passwords on a (hopefully) secure server vs allowing the client to send the password in plaintext over the network (though possibly over an encrypted channel). I like it, but YMMV. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics vpopm...@honorablemenschen.com !DSPAM:4b22669432713716511896!
Re: [vchkpw] Block all .html attachments?
> I've seen a huge increase in spam making use of .html attachments, and I'm > considering outright blocking of all .html attachments. > > Has anyone else done this? Any thoughts on the number of legitimate .html > attachments I'd be blocking? > HTML Email is an abomination in the eyes of this (and many other) email administrator. There's no reason for HTML encoded email on this list, let alone .html attachments IMHO. I say kill it. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics vpopm...@honorablemenschen.com !DSPAM:4c4081f032717009110895!
Re: [vchkpw] security issue
> Hi, > > Mailsetup: qmail + vpopmail 5.5.27 + dovecot > > Over the years, we didn't store cleatext versions of passwords. Some time > ago, > we wanted to change that setup and since that time, we used vpopmail > compiled > without option --disable-clear-passwd, but know with > option --enable-learn-passwords . step by step, we wanted to get user's > passwords (we discussed that issue here on the list about 2 years ago). > The > reason was, we wanted to change our mailsetup (postfix+dovecot). But that > did > not work, means, cleartext version of password wasn't stored. > > All other was working fine and so i didn't change anything. This was a big > mistake, because since that time, all vpopmail mailboxes could be accessed > with an empty passwordstring, at least, if the clients were using cram or > digest authentication. > > I know about the misconfigured vpopmail, but i think this behavor isn't as > expected. In the documentation of the option --disable-clear-passwd is > explaned, that this option causes vpopmail to store cleartext version of > passwords in _addition_ to their encrypted versions, and so i think, the > described behavior is at least a security leak. > Your words are confusing, as either you have typos or logical opposites of what you mean. I think you're saying that you enabled the storage of cleartext passwords after the fact, but forgot to turn on learing of passwords, and as a result everyone had an empty cleartext password stored, allowing access to the mailboxes with an empty password using cram or digest authentication. While this may look like a security "leak", I would argue that this is simply the expected result of misconfiguring your system in a manner that causes security holes. The same can be said for just about any software that uses logins - if you don't configure it correctly (and monitor it to make sure it's still working properly), you're going to open yourself up to unnecessary risks. I've worked with someone who had to do the whole "we want to capture plaintext passwords after the fact" thing, and they set up a very specific plan in advance and followed it to the letter in order to minimize the risk - specifically: 1) Recompile vpopmail w/ clear-text passwords and learning enabled. 2) Put it in place and test to make sure that passwords were being captured. 3) Keep it in place only as long as absolutely necessary - in this case, I think they did it for a month, but it might have been less than that - and monitor that passwords are being captured so it can be cut short if everyone has one. 4) Recompile vpopmail WITHOUT learning enabled, put it in place, and force everyone whose password was not learned to change their password - in this case by changing it for them and having them call in when they can't connect (since they hand't connected within the alloted time, it wasn't likely a big deal). It sounds like you did step 1, half of step 2, and didn't look at it again until 2 years later. You can't fault the software for working the way you told it to and you assuming it was doing something different. Perhaps the documentation needs to be revised to spell out what not to do if you want to keep your system secure, but I don't think that's the same as "the software is insecure." And as to storing both encrypted and plaintext versions of the password, I can see that there's no NEED to keep the encrypted version if you have the plaintext one, but then you'd have to have 2 totally separate password checking routines for non-cram/digest authentication, depending on which version of the password is stored, and that seems unnecessary to me. Besides, there's actually a little bit of extra security in the fact that you're never comparing just a plain text password to a plain text password - there's always some sort of encryption algorithm involved before the comparison... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics vpopm...@honorablemenschen.com !DSPAM:4d12170f32711772715885!
[vchkpw] Patches to Vpopmail
I actually wrote these patches about a year and a half ago, but never got
around to joining the list and submitting them. They've been working in
production on 5.4.3 at a previous employer of mine since ~10/04, and I
just updated them to patch against 5.4.13. They were written one on top
of the other in the order presented, but #1 is independant of #2-3. I
believe that at least the first one should be integrated into the mainline
of vpopmail, and the latter two may be relevant for that but need some
work (see below).
Patch #1: Local Relay Patch
This patch came about from a problem we had with a high-volume vpopmail
environment where it was attempting to rebuild the tcp.smtp.cdb file so
often that it was causing performance problems. This path was intended to
eliminate the overhead of updating the CDB when the IP address was already
listed permanently in the tcp.smtp file. Since the IP address is already
listed, updating the CDB file is irrlelevant - if they're allowed they're
already in there, and if they're denied they'll never make it to the auth
stage. This checks for static relay matches on the remote IP address and
returns true on a match, then exits the update function cleanly.
Patch #2: Bigdir Backfill Patch - MYSQL Only
This patch came from another problem we had on the same environment -
every year we would add and delete ~800 accounts, but the new ones were
always added to the end. This resulted in a fragmented number of users in
different hash directories, as there was never any way to fill-in the
spaces that were left by deleted accounts. To make things worse, because
the increment check was based on the total number of accounts % 100, it
was very possible (and likely!) to get more than 100 users in a single
directory. For example:
Directory a has 100 users, and directory b has 98 users. When you add
another user, it sees that 198%100 = 98, so it adds a user to b, which now
has 99 users. Now delete 10 users from a, and then add 10 users; where do
they go? Logically, the first one should go in b, which
would then have 100 users and cause the next 9 to go in c. However, since
(90+99=189)%100 = 89, it will put them all into b, incrementing b to 109.
And there would still be room for 1 more in b before it moved on to c,
assuming no accounts were deleted from a.
This patch changes the way a directory's contents are counted, by checking
the vpopmail database and counting the number of users in that directory.
It also excludes has directories from its count, so it just lists the
users. We were using a MySQL backend so that's what I coded the patch for
- I haven't looked into other backends, but I'd guess that it shouldn't be
too hard to port to another backend for someone who's familiar with that
method. I call it the backfill patch because you can reset the
level_index information and it will walk the hash dirs filling in where
there are available spots as you add more users.
Patch #3: Dir Limits Patch - MYSQL ONLY
This patch builds on the previous patch and as such requires it. It
changes the vdir_type struct definition to include and int field named
the_dir, as well as adding a field to the dir_control table. The default
value is 100, to correspond to the original MAX_USERS_PER_DIR, but it
allows you to in/decrease that number on a per-domain basis to fit your
needs. Newly created vpopmail DBs will automatically be crated properly,
but existng DBs will need to be altered to work - see the file
README.dirlimits included in the patch. Again, this one is for mysql
only, but should be convertable to most any auth scheme with ease.
Please let me know if you {like|dislike|don't understand|other} these
patches, and if you have any questions/suggestions for them.
Thanks,
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
diff -urN ../clean/vpopmail-5.4.13/vpopmail.c vpopmail-5.4.13/vpopmail.c
--- ../clean/vpopmail-5.4.13/vpopmail.c 2005-07-19 20:10:22.0 -0400
+++ vpopmail-5.4.13/vpopmail.c 2006-01-05 09:39:46.0 -0500
@@ -2465,6 +2465,9 @@
*/
int open_smtp_relay()
{
+ if (check_static_relay()) {
+return(0);
+ }
#ifdef USE_SQL
/* store the user's ip address into the sql relay table */
if (vopen_smtp_relay()) {
@@ -2643,6 +2646,44 @@
//
+#ifdef POP_AUTH_OPEN_RELAY
+/* check_static_relay() looks to see if the remote IP address is in the
+ * TCP_RULES file, and if so returns true. Used to not update the relay
+ * table with IP addresses that are already covered by another rule.
+ */
+
+int check_static_relay()
+{
+ FILE *fs;
+ char tmpbuf1[MAX_BUFF];
+ int found = 0;
+ char *ipaddr, *p;
+
+ /* get the remote IP address a
Re: [vchkpw] Patches to Vpopmail
> On Jan 5, 2006, at 12:38 PM, Joshua Megerman wrote:
>> Please let me know if you {like|dislike|don't understand|other} these
>> patches, and if you have any questions/suggestions for them.
>
> Those patches sound good. When I get back from my vacation this week,
> and have caught up on other work, I'll be sure to incorporate them into
> the upcoming 5.4.14 release.
>
Wow - I wasn't expecting to just have them accepted without debate :)
I do think that the bigdir-backfill patch (and the dirlimits patch if you
like it) should be ported to other auth backends, but I really don't have
the experience (or time) to do those myself. Let me know if you find any
issues with them.
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
Re: [vchkpw] Re: Vpopmaild backport to 5.4.13
> Joshua Megerman said the following on 12/01/2006 15:20: >> However, this morning I took another gander at it and started by >> commenting out everything that cause compile errors of vpopmaild.c >> against >> 5.4.13, and then worked (almost) everything back in. So here's my patch >> to bring vpopmaild into the main vpopmail branch. The changes in the >> patch are as follows: > > http://thread.gmane.org/gmane.mail.qmail.vpopmail.devel/41 > > Come on, keep up. :) > 1) I only just got into doing vpopmail development, so I didn't know about that. 2) My only attempts to extract the current CVS version have met with "connection refused", so I haven't even looked at the CVS code. 3) I needed to figure out if I could use vpopmaild or if I had to roll my own, and I needed to figure it out _NOW_ :) Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] Vpopmaild HeisenBug
I have found a literal HeisenBug in vpopmaild - when using recordio to watch the conversation for debugging purposes, wait_read() times out without actually seeing what is passed to it. Removing recordio solves the problem - the act of watching vpopmaild actually changes its behavior. I don't know enough about recordio and how vpopmaild is doing its interactive reads, but it must have something to do with the file descriptors. Perhaps someone with more of a clue than I can look into it at some point... Thanks, Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Vpopmail 5.4.14 released (finally)
> On Jan 17, 2006, at 12:40 PM, Steve Cole wrote: >>> This release brings in the vpopmail daemon (vpopmaild) from the 5.5 >>> development series, and fixes a few bugs from 5.4.13. >> >> Bad news... > > Can you email me your configuration options? In particular, I need to > know which backend (cdb, mysql, postgres) and whether you have > --enable-valias selected. > I have the same problem - my configure is as follows: ./configure --enable-vpopuser=vpopmail --enable-vpopgroup=vchkpw --enable-auth-module=mysql --enable-qmail-ext --enable-valias --enable-mysql-limits --enable-sql-logging --disable-many-domains --enable-qmaildir=/var/qmail It appears that you are linking both the vmysql valias_select* and the vpalias valias_select* object code into libvpopmail.a, resulting in the compile error. I'm not sure what changed, but obviously it's Not Good(tm) :( Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] MySQL going down results in 5xx error
> If you are using chkuser, there is a small change you can do (I'm going to > publish nextly this change with next version of chkuser). > > If you are interested I'll anticipate this small change so it may help > people to handle this error. > Can you post the change here so that those of us who want to look at it and test it can? Thanks, Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] Bigdir Backfill patch fix for first user
In working with a clean install of vpopmail using my bigdir-backfill patch
posted a few weeks ago, I found a problem - if there's no vpopmail table
to do lookups in vadddomain fails with an SQL error. The attached patch
fixes that - it checks to see if vdir->cur_users == 1, and if so just sets
user_count = 1 rather than doing the lookup. I guess you could do this
for if cur_users < dir_limit, but you really only want to do this if
there's no table to avoid the SQL error...
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
diff -urN ../04-TCD/vpopmail-5.4.13/bigdir.c vpopmail-5.4.13/bigdir.c
--- ../04-TCD/vpopmail-5.4.13/bigdir.c 2006-01-05 14:08:19.0 -0500
+++ vpopmail-5.4.13/bigdir.c 2006-01-25 15:02:36.0 -0500
@@ -111,7 +111,11 @@
for(i=vdir->level_cur+1;ilevel_max;i++)
vdir->level_index[i] = 0;
}
- rc = vcount_dir_users(&user_count, domain, vdir->the_dir);
+ if (vdir->cur_users == 1) {
+ user_count = 1;
+ } else {
+ rc = vcount_dir_users(&user_count, domain, vdir->the_dir);
+ }
while ( user_count >= vdir->dir_limit ) {
if ( vdir->level_index[vdir->level_cur] ==
vdir->level_end[vdir->level_cur] ) {
Re: [vchkpw] MySQL going down results in 5xx error
> Yes, here are changes. I've already tried them and it works. Just studying the name of calls it may be adapted to Postgres also (it should be enough to use vauth_open() ). > > In chkuser_settings.h enable > #define CHKUSER_ENABLE_VAUTH_OPEN > and add one of the following lines: > /* use this if you are using replicated MySQL, with read access */ #define CHKUSER_VAUTH_OPEN_CALL vauth_open > or > /* use this if you are using standalone MySQL, with readwrite access */ #define CHKUSER_VAUTH_OPEN_CALL vauth_open_update > FYI - with MySQL it's vauth_open_read not vauth_open. I'm thinking of submitting a patch to vpopmail to unify the call, so that it can be published globally. It would be nice if vauth_open would work no matter what the backend auth mechanism... > Another comment on side effects of restarting MySQL. > Courier auth daemon must be restarted, because it does not try to reopen any MySQL connection. > > It would be nice to have a simple perl script monitoring MySQL (an attach every x minutes), and in case of problem: > - running a script for shutting down Courier and other mail > services > - stopping/restarting MySQL > - running a script for restarting all mail services > Does authdaemon die if it loses its connection to MySQL? If so why not just run it under daemontools. If not, perhaps it should... I haven't looked at authdaemon/courier-imap v4 lately, but I dislike the mechanism somewhat because there's no way to get the TCPREMOTEIP info from the imap daemon to vpopmail, which I use to determine if I even need to update the relay table (I don't if it's in my permanently allowed subnet, or from my local webmail server...) which saves time on heavily loaded servers... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] MySQL going down results in 5xx error
> #if defined CHKUSER_ENABLE_VAUTH_OPEN
> if (db_already_open != 1) {
> if (CHKUSER_VAUTH_OPEN_CALL () == 0) {
> db_already_open == 1;
> } else {
> retstat = CHKUSER_ERR_AUTH_RESOURCE;
> }
> };
> #endif
Minor Bug: you nead a "break;" on the line after "retstat = ...",
otherwise you keep testing on a failed resource...
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
[vchkpw] Requeueing question
This probably is better posted to the qmail mailing list, but I can't seem to get to cr.yp.to right now and I'm not on the list at this time... Is there any (known) way to force qmail to immediately requeue a message upon delivery deferral rather than having it wait until the next send time? I just finished a qmail patch that allows a limit on the number of concurrent attempts made to any given IP address (well, any given hash - there's only so many semaphores I'm willing to create :)). This allows mail to continue processing on high-volume servers without bogging down because a remote server (e.g., AOL or YAHOO) is throttling or just too busy to accept more than 8-10 connections from a single server at once. The patch will cause that MX IP to be skipped and the next one in line to be tried - if no MX is reachable it defers the mesage. However, in that case I would like to force qmail to immediately retry the message as the deferral was on the local system rather than cause by the remote system. After looking at how qmail runs its queue, I don't think there's a way to do it, but I figured I'd throw the question out anyway. I'll be making the patch available at some point in the future once I've tested it some more... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Vpopmail 5.4.15 released (finally)
OK, here's another one. I've got a couple of patches (previously posted here) that I use and in the process of applying them I noticed a couple things that concern me: 1) The MAX_PW_DOMAIN has increased from 64 to 96, but there's no corresponding increase in the field size in vmysql.h (and presumably the other backends where size matters). Isn't this going to cause problems when 96 character domain names are shoved into 64 character database fields? 2) Similarly, the vlimits structure now has disable_spamassassin and delete_spam fields, but no corresponding field was added to the limits table in vmysql.h. In fact, these fields appear to be completely unaddressed in the mysql backend, so that at best they will be ignored if used, and at worst they may actually break something. Is this intentional, or just an oversight? I'm willing to try and contribute to the solution, just let me know what (if anything) you need. I will, however, be offline almost all weekend, so it'll probably be Monday before I produce anything unless I can hack it out quickly this afternoon... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] 5.4.15 SQL Fixes [WAS: Re: [vchkpw] Vpopmail 5.4.15 released (finally)]
OK, I went through and updated the MySQL, PgSQL and Oracle header files to
provide 96-char field sizes for domain, and I updated the mysql limits
pieces to account for the new fields. I haven't created anything yet as
far as actually updating the SQL database structure of an existing setup,
but that should be easy (change field size, add a couple columns to 1
table). Here's the patch.
Josh
> OK, here's another one. I've got a couple of patches (previously posted
> here) that I use and in the process of applying them I noticed a couple
> things that concern me:
>
> 1) The MAX_PW_DOMAIN has increased from 64 to 96, but there's no
> corresponding increase in the field size in vmysql.h (and presumably the
> other backends where size matters). Isn't this going to cause problems
> when 96 character domain names are shoved into 64 character database
> fields?
> 2) Similarly, the vlimits structure now has disable_spamassassin and
> delete_spam fields, but no corresponding field was added to the limits
> table in vmysql.h. In fact, these fields appear to be completely
> unaddressed in the mysql backend, so that at best they will be ignored if
> used, and at worst they may actually break something. Is this
> intentional, or just an oversight?
>
> I'm willing to try and contribute to the solution, just let me know what
> (if anything) you need. I will, however, be offline almost all weekend,
> so it'll probably be Monday before I produce anything unless I can hack it
> out quickly this afternoon...
>
> Josh
> --
> Joshua Megerman
> SJGames MIB #5273 - OGRE AI Testing Division
> You can't win; You can't break even; You can't even quit the game.
> - Layman's translation of the Laws of Thermodynamics
> [EMAIL PROTECTED]
>
>
>
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
diff -urN ../clean/vpopmail-5.4.15/vmysql.c vpopmail-5.4.15/vmysql.c
--- ../clean/vpopmail-5.4.15/vmysql.c 2006-02-24 02:27:31.0 -0500
+++ vpopmail-5.4.15/vmysql.c 2006-02-24 14:18:42.0 -0500
@@ -1537,8 +1537,9 @@
"maxmsgcount, defaultquota, defaultmaxmsgcount, "
"disable_pop, disable_imap, disable_dialup, "
"disable_passwordchanging, disable_webmail, disable_relay, "
-"disable_smtp, perm_account, perm_alias, perm_forward, "
-"perm_autoresponder, perm_maillist, perm_quota, perm_defaultquota \n"
+"disable_smtp, disable_spamassassin, delete_spam, perm_account, "
+"perm_alias, perm_forward, perm_autoresponder, perm_maillist, "
+"perm_quota, perm_defaultquota \n"
"FROM limits \n"
"WHERE domain = '%s'", domain);
@@ -1563,7 +1564,7 @@
return vlimits_read_limits_file (VLIMITS_DEFAULT_FILE, limits);
} else if ((row = mysql_fetch_row(res_read)) != NULL) {
-int perm = atol(row[20]);
+int perm = atol(row[22]);
limits->maxpopaccounts = atoi(row[0]);
limits->maxaliases = atoi(row[1]);
@@ -1581,17 +1582,19 @@
limits->disable_webmail = atoi(row[13]);
limits->disable_relay = atoi(row[14]);
limits->disable_smtp = atoi(row[15]);
-limits->perm_account = atoi(row[16]);
-limits->perm_alias = atoi(row[17]);
-limits->perm_forward = atoi(row[18]);
-limits->perm_autoresponder = atoi(row[19]);
+limits->disable_spamassassin = atoi(row[16]);
+limits->delete_spam = atoi(row[17]);
+limits->perm_account = atoi(row[18]);
+limits->perm_alias = atoi(row[19]);
+limits->perm_forward = atoi(row[20]);
+limits->perm_autoresponder = atoi(row[21]);
limits->perm_maillist = perm & VLIMIT_DISABLE_ALL;
perm >>= VLIMIT_DISABLE_BITS;
limits->perm_maillist_users = perm & VLIMIT_DISABLE_ALL;
perm >>= VLIMIT_DISABLE_BITS;
limits->perm_maillist_moderators = perm & VLIMIT_DISABLE_ALL;
-limits->perm_quota = atoi(row[21]);
-limits->perm_defaultquota = atoi(row[22]);
+limits->perm_quota = atoi(row[23]);
+limits->perm_defaultquota = atoi(row[24]);
}
mysql_free_result(res_read);
@@ -1609,10 +1612,11 @@
"diskquota, maxmsgcount, defaultquota, defaultmaxmsgcount, "
"disable_pop, disable_imap, disable_dialup, "
"disable_passwordchanging, disable_webmail, disable_relay, "
-"disable_smtp, perm_account, perm_alias, perm_forward, "
-"perm_autoresponder, perm_maillis
[vchkpw] Vpopmaild issue
Using the Patch that Bill Shupp used to integrate vpopmaild into 5.4.13, I was able to develop a PHP-based interface for editing .qmail and other files in vpopmail users' home dirs for controlling various delivery processing options. It's not working now, and I've figured out why not. The original version of vpopmaild that I was using only uses "\n" for CRLF, while the new one in 5.4.15 uses "\r\n". While not an issue for raw telnet, it fails for PHP since PHP_NORMAL_READ stops reading at '\r' OR '\n'. I may be able to resolve it by simply calling an additional read, but I'm wondering why was chosen as the delimiter rather than just . Thanks for the info, Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Corrupt return-path help? [OT]
> On May 9, 2006, at 12:57 PM, Jeremy Kitchen wrote: >> the problem is that vpopmail is using qmail-inject to forward messages. >> qmail-inject does not tolerate malformed messages. >> >> it's that simple. > > Any volunteers to review the code in vdelivermail.c and modify it to > use qmail-queue instead of qmail-inject? > Well, I just took a quick look at vdelivermail.c, and it may be simple to do. Unfortunately I don't have a system where I can really test it, but I'm willing to look at the code changes. It will also require a change to the configure system, which I have no real experience with, but short term you can specify qmail-queue for the qmail-inject path to take care of it. I'll see if I can whip up some code as a starting point and post it here shortly. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] vdelivermail qmail-queue ALPHA patch
> On May 9, 2006, at 12:57 PM, Jeremy Kitchen wrote:
>> the problem is that vpopmail is using qmail-inject to forward messages.
>> qmail-inject does not tolerate malformed messages.
>>
>> it's that simple.
>
> Any volunteers to review the code in vdelivermail.c and modify it to
> use qmail-queue instead of qmail-inject?
>
OK, here's a quick stab at a basic patch - I modified qmail_inject_open to
open qmail-queue appropriately (no args), and changed deliver_mail to talk
to it. I THINK :)
There's no bounds checking and so forth in here, there are a few places
where there really needs to be some extra code to make sure that the data
acquired is valid, but it's designed to be proof-of-concept. It compiles,
but that's all I can guarantee.
Use at your own risk, yada yada... Feel free to modify it as needed, I
have no ego attached to this code :)
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
--- vdelivermail.c.orig 2006-05-09 17:35:00.0 -0400
+++ vdelivermail.c 2006-05-09 18:02:34.0 -0400
@@ -72,6 +72,7 @@
#define BUFF_SIZE 300
int fdm;
+int fde;
#define EXIT_BOUNCE 100
#define EXIT_DEFER 111
@@ -304,33 +305,41 @@
}
#endif
-/* Forks off qmail-inject. Returns PID of child, or 0 for failure. */
-pid_t qmail_inject_open(char *address)
+/* Forks off qmail-queue. Returns PID of child, or 0 for failure. */
+pid_t qmail_queue_open(char *address)
{
int pim[2];
+ int pie[2];
+
pid_t pid;
- static char *binqqargs[4];
+ static char *binqqargs[2];
if ( pipe(pim) == -1) return 0;
+if ( pipe(pie) == -1) return 0;
switch(pid=vfork()){
case -1:
close(pim[0]);
close(pim[1]);
+close(pie[0]);
+close(pie[1]);
printf ("Unable to fork: %d.", errno);
return 0;
case 0:
close(pim[1]);
+close(pie[1]);
if (vfd_move(0,pim[0]) == -1 ) _exit(-1);
+if (vfd_move(1,pie[0]) == -1 ) _exit(-1);
binqqargs[0] = QMAILINJECT;
-binqqargs[1] = "--";
-binqqargs[2] = (*address == '&' ? &address[1] : &address[0]);
+ binqqargs[1] = 0;
execv(*binqqargs, binqqargs);
-printf ("Unable to launch qmail-inject.");
+printf ("Unable to launch qmail-queue.");
exit (EXIT_DEFER);/* child's exit caught later */
}
fdm = pim[1];
+fde = pie[1];
close(pim[0]);
+close(pie[0]);
return(pid);
}
@@ -628,10 +637,12 @@
char *dtline;
char *atpos;
int dtlen;
+ char qenv[BUFF_SIZE];
+ int qenvsz;
if (*address=='&') ++address; /* will this case ever happen? */
- inject_pid = qmail_inject_open(address);
- if (inject_pid == 0) vexiterr (EXIT_DEFER, "system error, can't open qmail-inject");
+ inject_pid = qmail_queue_open(address);
+ if (inject_pid == 0) vexiterr (EXIT_DEFER, "system error, can't open qmail-queue");
/* use the DTLINE variable, but skip past the dash in
* [EMAIL PROTECTED]
@@ -665,13 +676,24 @@
}
if (fdcopy (fdm, 0, DeliveredTo, strlen(DeliveredTo)) != 0) {
- printf ("write to qmail-inject failed: %d\n", errno);
+ printf ("write to qmail-queue failed: %d\n", errno);
close(fdm);
+ close(fde);
waitpid(inject_pid,&child,0);
vexiterr (EXIT_DEFER, "system error");
}
+ qenvsz = snprintf("F%s\0T%s", BUFF_SIZE, getenv("SENDER"), address);
+ qenvsz++;
+ if ((write(fde, (void *)qenv, qenvsz)) != qenvsz) {
+ printf ("write to qmail-queue failed: %d\n", errno);
+ close(fdm);
+ close(fde);
+ vexiterr (EXIT_DEFER, "system error");
+ }
+
close(fdm);
+ close(fde);
waitpid(inject_pid,&child,0);
if (wait_exitcode(child) == 0) return;
vexiterr (EXIT_DEFER, "system error");
Re: [vchkpw] vdelivermail qmail-queue ALPHA patch
>> On May 9, 2006, at 12:57 PM, Jeremy Kitchen wrote:
>>> the problem is that vpopmail is using qmail-inject to forward messages.
>>> qmail-inject does not tolerate malformed messages.
>>>
>>> it's that simple.
>>
>> Any volunteers to review the code in vdelivermail.c and modify it to
>> use qmail-queue instead of qmail-inject?
>>
> OK, here's a quick stab at a basic patch - I modified qmail_inject_open to
> open qmail-queue appropriately (no args), and changed deliver_mail to talk
> to it. I THINK :)
>
> There's no bounds checking and so forth in here, there are a few places
> where there really needs to be some extra code to make sure that the data
> acquired is valid, but it's designed to be proof-of-concept. It compiles,
> but that's all I can guarantee.
>
> Use at your own risk, yada yada... Feel free to modify it as needed, I
> have no ego attached to this code :)
>
OK, so I can't stand writing sloppy code :) Here's an updated version of
the patch that handles things a little better (albeit in a slightly more
complicated manner), and cleans up a couple remaining stragglers of the
changeover.
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]--- vdelivermail.c.orig 2006-05-09 17:35:00.0 -0400
+++ vdelivermail.c 2006-05-09 18:33:26.0 -0400
@@ -72,6 +72,7 @@
#define BUFF_SIZE 300
int fdm;
+int fde;
#define EXIT_BOUNCE 100
#define EXIT_DEFER 111
@@ -304,33 +305,41 @@
}
#endif
-/* Forks off qmail-inject. Returns PID of child, or 0 for failure. */
-pid_t qmail_inject_open(char *address)
+/* Forks off qmail-queue. Returns PID of child, or 0 for failure. */
+pid_t qmail_queue_open()
{
int pim[2];
+ int pie[2];
+
pid_t pid;
- static char *binqqargs[4];
+ static char *binqqargs[2];
if ( pipe(pim) == -1) return 0;
+if ( pipe(pie) == -1) return 0;
switch(pid=vfork()){
case -1:
close(pim[0]);
close(pim[1]);
+close(pie[0]);
+close(pie[1]);
printf ("Unable to fork: %d.", errno);
return 0;
case 0:
close(pim[1]);
+close(pie[1]);
if (vfd_move(0,pim[0]) == -1 ) _exit(-1);
+if (vfd_move(1,pie[0]) == -1 ) _exit(-1);
binqqargs[0] = QMAILINJECT;
-binqqargs[1] = "--";
-binqqargs[2] = (*address == '&' ? &address[1] : &address[0]);
+binqqargs[1] = 0;
execv(*binqqargs, binqqargs);
-printf ("Unable to launch qmail-inject.");
+printf ("Unable to launch qmail-queue.");
exit (EXIT_DEFER);/* child's exit caught later */
}
fdm = pim[1];
+fde = pie[1];
close(pim[0]);
+close(pie[0]);
return(pid);
}
@@ -628,10 +637,18 @@
char *dtline;
char *atpos;
int dtlen;
+ char *sender = 0;
+ char keychar[3] = "FT";
+ char *envptrs[6] = { keychar, sender, keychar+2, keychar+1, address, keychar+2 };
+ int envlens[6] = { 1, 0, 1, 1, 0, 1 }; // sender and address get initialized later
+ int writestr;
if (*address=='&') ++address; /* will this case ever happen? */
- inject_pid = qmail_inject_open(address);
- if (inject_pid == 0) vexiterr (EXIT_DEFER, "system error, can't open qmail-inject");
+ envptrs[4] = address;
+ envlens[4] = strlen(address) + 1;
+
+ inject_pid = qmail_queue_open();
+ if (inject_pid == 0) vexiterr (EXIT_DEFER, "system error, can't open qmail-queue");
/* use the DTLINE variable, but skip past the dash in
* [EMAIL PROTECTED]
@@ -665,13 +682,33 @@
}
if (fdcopy (fdm, 0, DeliveredTo, strlen(DeliveredTo)) != 0) {
- printf ("write to qmail-inject failed: %d\n", errno);
+ printf ("write to qmail-queue failed: %d\n", errno);
close(fdm);
+ close(fde);
waitpid(inject_pid,&child,0);
vexiterr (EXIT_DEFER, "system error");
}
+ if (!(sender = getenv("SENDER"))) {
+ printf ("unable to acquire SENDER from environment\n");
+ close(fdm);
+ close(fde);
+ vexiterr (EXIT_DEFER, "system error");
+ }
+ envptrs[1] = sender;
+ envlens[1] = strlen(sender) + 1;
+
+ for (writestr = 0; writestr < 6; writestr++) {
+if ((write(fde, (void *)envptrs[writestr], envlens[writestr])) != envlens[writestr]) {
+printf ("write to qmail-queue failed: %d\n", errno);
+close(fdm);
+close(fde);
+vexiterr (EXIT_DEFER, "system error");
+}
+ }
+
close(fdm);
+ close(fde);
waitpid(inject_pid,&child,0);
if (wait_exitcode(child) == 0) return;
vexiterr (EXIT_DEFER, "system error");
Re: [vchkpw] vdelivermail qmail-queue ALPHA patch - take 3
>>> On May 9, 2006, at 12:57 PM, Jeremy Kitchen wrote:
>>>> the problem is that vpopmail is using qmail-inject to forward
>>>> messages.
>>>> qmail-inject does not tolerate malformed messages.
>>>>
>>>> it's that simple.
>>>
>>> Any volunteers to review the code in vdelivermail.c and modify it to
>>> use qmail-queue instead of qmail-inject?
>>>
>> OK, here's a quick stab at a basic patch - I modified qmail_inject_open
>> to
>> open qmail-queue appropriately (no args), and changed deliver_mail to
>> talk
>> to it. I THINK :)
>>
>> There's no bounds checking and so forth in here, there are a few places
>> where there really needs to be some extra code to make sure that the
>> data
>> acquired is valid, but it's designed to be proof-of-concept. It
>> compiles,
>> but that's all I can guarantee.
>>
>> Use at your own risk, yada yada... Feel free to modify it as needed, I
>> have no ego attached to this code :)
>>
> OK, so I can't stand writing sloppy code :) Here's an updated version of
> the patch that handles things a little better (albeit in a slightly more
> complicated manner), and cleans up a couple remaining stragglers of the
> changeover.
>
And here's another update. I realized as I was driving home last night
that I'd made a mistake (that's what I get for coding while tired :)) and
was printing double NULLs in the envelope. This fixes it (and simplifies
the code a little too).
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
--- vdelivermail.c.orig 2006-05-09 17:35:00.0 -0400
+++ vdelivermail.c 2006-05-10 09:09:19.0 -0400
@@ -72,6 +72,7 @@
#define BUFF_SIZE 300
int fdm;
+int fde;
#define EXIT_BOUNCE 100
#define EXIT_DEFER 111
@@ -304,33 +305,41 @@
}
#endif
-/* Forks off qmail-inject. Returns PID of child, or 0 for failure. */
-pid_t qmail_inject_open(char *address)
+/* Forks off qmail-queue. Returns PID of child, or 0 for failure. */
+pid_t qmail_queue_open()
{
int pim[2];
+ int pie[2];
+
pid_t pid;
- static char *binqqargs[4];
+ static char *binqqargs[2];
if ( pipe(pim) == -1) return 0;
+if ( pipe(pie) == -1) return 0;
switch(pid=vfork()){
case -1:
close(pim[0]);
close(pim[1]);
+close(pie[0]);
+close(pie[1]);
printf ("Unable to fork: %d.", errno);
return 0;
case 0:
close(pim[1]);
+close(pie[1]);
if (vfd_move(0,pim[0]) == -1 ) _exit(-1);
+if (vfd_move(1,pie[0]) == -1 ) _exit(-1);
binqqargs[0] = QMAILINJECT;
-binqqargs[1] = "--";
-binqqargs[2] = (*address == '&' ? &address[1] : &address[0]);
+binqqargs[1] = 0;
execv(*binqqargs, binqqargs);
-printf ("Unable to launch qmail-inject.");
+printf ("Unable to launch qmail-queue.");
exit (EXIT_DEFER);/* child's exit caught later */
}
fdm = pim[1];
+fde = pie[1];
close(pim[0]);
+close(pie[0]);
return(pid);
}
@@ -628,10 +637,18 @@
char *dtline;
char *atpos;
int dtlen;
+ char *sender = 0;
+ char keychar[2] = { 'F', 'T' };
+ char *envptrs[4] = { keychar, sender, keychar+1, address };
+ int envlens[4] = { 1, 0, 1, 0 }; // sender and address get initialized later
+ int writestr;
if (*address=='&') ++address; /* will this case ever happen? */
- inject_pid = qmail_inject_open(address);
- if (inject_pid == 0) vexiterr (EXIT_DEFER, "system error, can't open qmail-inject");
+ envptrs[3] = address;
+ envlens[3] = strlen(address) + 1;
+
+ inject_pid = qmail_queue_open();
+ if (inject_pid == 0) vexiterr (EXIT_DEFER, "system error, can't open qmail-queue");
/* use the DTLINE variable, but skip past the dash in
* [EMAIL PROTECTED]
@@ -665,13 +682,33 @@
}
if (fdcopy (fdm, 0, DeliveredTo, strlen(DeliveredTo)) != 0) {
- printf ("write to qmail-inject failed: %d\n", errno);
+ printf ("write to qmail-queue failed: %d\n", errno);
close(fdm);
+ close(fde);
waitpid(inject_pid,&child,0);
vexiterr (EXIT_DEFER, "system error");
}
+ if (!(sender = getenv("SENDER"))) {
+ printf ("unable to acquire SENDER from environment\n");
+ close(fdm);
+ close(fde);
+ vexiterr (EXIT_DEFER,
[vchkpw] Patch - don't update tcp.smtp for users already covered by static rules
Here is an improved version of a patch that I posted once previously. I
recently submitted it to Tom and he pointed out that it didn't necessarily
do what it should have since it was based on certain assumptions. I've
updated it so that it doesn't just ignore IPs that have any rule in the
tcp.smtp file, but only those that are explicitly allowed to relay.
It takes the remote IP and compares it to the rules in tcp.smtp. It
aborts open_smtp_relay early if there is a rule in tcp.smtp that meets the
following conditions:
1. It covers the remote IP (obviously)
2. It specifies "allow" (currently it only recognizes all lower case,
since that's the form I've always seen and is what vpopmail uses. If it
needs to support upper as well, that's easy).
3. It specifies 'RELAYCLIENT=""'
Under those conditions, it assumes that the remote client is covered by a
static tcprules mapping and doesn't update tcp.smtp. Otherwise it will do
the update as normal.
The reason I originally wrote this is that under high-volumes, there is no
good reason to continuously update the tcp.smtp file to allow relaying by
addresses that are already allowed to relay. This also coveres things
like webmail servers, which are constantly logging into the IMAP server
unless you have an IMAP proxy, and can yield many tcprules updates under
load.
Please take a look and see what you think, as it is something I think
would be a valuable addition to the main vpopmail tree.
Thanks,
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
diff -urN ../clean/vpopmail-5.4.16/vpopmail.c vpopmail-5.4.16/vpopmail.c
--- ../clean/vpopmail-5.4.16/vpopmail.c 2006-01-17 14:30:52.0 -0500
+++ vpopmail-5.4.16/vpopmail.c 2006-05-10 15:31:40.0 -0400
@@ -2903,6 +2903,9 @@
*/
int open_smtp_relay()
{
+ if (check_static_relay()) {
+return(0);
+ }
#ifdef USE_SQL
int result;
@@ -3095,6 +3098,83 @@
//
+#ifdef POP_AUTH_OPEN_RELAY
+/* check_static_relay() looks to see if the remote IP address is in the
+ * TCP_RULES file, and if so returns true. Used to not update the relay
+ * table with IP addresses that are already covered by another rule.
+ */
+
+int check_static_relay()
+{
+ FILE *fs;
+ char tmpbuf1[MAX_BUFF], tmpbuf2[MAX_BUFF];
+ int found = 0, ipfound = 0, i = 1, x, y, z;
+ char *ipaddr, *p, *q, *r, *ip[4];
+
+ /* get the remote IP address as a string */
+ ipaddr = get_remote_ip();
+ strcpy(tmpbuf2, ipaddr);
+
+ q = strtok(tmpbuf2, ".");
+ ip[0] = q;
+ while ((i < 4) && q) {
+q = strtok(NULL, ".");
+ip[i] = q;
+i++;
+ }
+
+ /* open the tcp.smtp file and read in the static rules - these addresses
+ * are handled by tcprules and not the relay table */
+ fs = fopen(TCP_FILE, "r");
+ if ( fs != NULL ) {
+/* read each entry and compare it to the remote IP address */
+while (( fgets(tmpbuf1, sizeof(tmpbuf1), fs ) != NULL ) && (!found)){
+ if ( p = strchr(tmpbuf1, ':') ) {
+*p = '\0';
+ if ( !(strncmp(ipaddr, tmpbuf1, strlen(tmpbuf1))) ) {
+ ipfound = 1;
+} else if (q = strchr(tmpbuf1, '-')) {
+ ipfound = 1;
+ q = strtok(tmpbuf1, ".");
+ if ( strcmp(ip[0], q) ) {
+ipfound = 0;
+ }
+ i = 1;
+ while ((i < 4) && q && ipfound) {
+q = strtok(NULL, ".");
+if ( strcmp(ip[i], q) ) {
+ ipfound = 0;
+} else {
+ i++;
+}
+ }
+ if (r = strchr(q, '-')) {
+x = atoi(ip[i]);
+y = atoi(q);
+z = atoi(r+1);
+if ((x >= y) && (x <= z)) {
+ ipfound = 1;
+}
+ }
+}
+if (ipfound) {
+ if (q = strstr(p+1, "allow")) {
+if (q = strstr(p+1, "RELAYCLIENT=\"\"")) {
+ found = 1;
+}
+ }
+}
+ }
+}
+fclose(fs);
+ }
+
+ return(found);
+}
+#endif /* POP_AUTH_OPEN_RELAY */
+
+//
+
int vfd_copy(int to, int from)
{
if (to == from) return 0;
Re: [vchkpw] Why is vadduser creating a hierarchy?
On Saturday 14 October 2006 19:06, Rainer Duffner wrote: > BTW: Does the latest version of vpopmail include the patch someone > posted that fills up earlier hash-directories, where domains have been > deleted from, instead of creating new ones? > Nope, it doesn't (I wrote the patch, and last I heard it hadn't even been considered... ) I posted the patch here a while back - while it may take a little hacking, it should work fine with the latest vpopmail. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Custom Fields ?
> Hi, i am trying to use vpopmail to administer qmail base as mysql, i was > wondering if there is a way to create new fields when you create a new > user, for example when you create new user i would like the option to add > maybe a phone number field or an id number field, so the admins can look > up records quicker. > In my experience, as long as you add new fields AFTER the existing vpopmail fields, you shouldn't have any problems. Just remember that you're likely to break things if you do something funky. Also, you'll have to populate those fields manually after you create the user unless you want to hack the vpopmail code to do it directly. YMMV... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Custom Fields ?
On Wednesday 13 December 2006 01:47, Rick Widmer wrote: > Joshua Megerman wrote: > > In my experience, as long as you add new fields AFTER the existing > > vpopmail fields, you shouldn't have any problems. > > The order of the fields in the table should not matter. I believe > vpopmail always uses explicit lists, so as long as you provide all of > the required fields it should be happy. > OK, I just looked at the MySQL code (the backend I use, and therefore am familiar with) and you're correct. I don't know if that changed since sometime in 5.3.x, when I first played with extending the DB, but at this point it looks like the columns are explicitly stated in order for all relevant SQL queries, so the order in the DB shouldn't matter. Just don't change the order in the query without changing the code - that I know for certain :) > I believe vdelivermail has support for creating the Maildir for a user > when the first email comes in. All you have to do is create the > database entry and wait for a message. (Maybe the one sent by John's > onchange patch.) I may be wrong, I use cdb. > I believe you are correct - the user dir doesn't get created until the first attempt by vpopmail to either read or write to it (e.g., deliver a message, check via pop3, etc.). I don't think this depends on the backend, as every backend stores the location of the user dir effectively the same way. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
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.
>
Well I use the SQL backend for almost everything, including simple
delivery aliases, but I also use .qmail files for a variety of reasons:
1) While I want the ability to store aliases in the DB, I do it for system
purposes, and not qmailadmin aliases (at leat not right now).
2) I use the .qmail file in each users' home dir for things like user
forwards, spam tagging and vacation messages. In fact, I recently wrote a
squirrelmail plugin that uses vpopmaild to control the edits to the user's
.qmail file, and order is critical - most users don't want spam forwarded
or autoresponded to, but some users do, and this is controlled entirely by
the order.
3) Most importantly, to me the idea of storing aliases in the DB is just
that - it's for aliases. If you have a program that you want to pipe the
message through, or send a copy of your mail offsite, I'd much rather have
that be via .qmail file and not as a database line. In fact, IIRC, the
valias table is designed for users who don't have "real" local accounts,
either aliasing the valias to a real vpopmail account or forwarding it to
an off-domain account. If you have both a real account and a valias entry
I'm not sure what vpopmail does, but I believe it ignores one or the
other...
I kind of understand the desire to make everything accessible via an
abstract interface, and I think it can probably be done, but I'm still not
convinved that everything should end up in the DB. If you're running a
program to process the mail, it's probably best to set up a real (virtual)
account for it, rather than trying to do everything totally virtually in
the DB. If there's no program delivery, there are only two possible entry
types for a .qmail file that generate any results: a forward, which is
handled very well by valiases, and a mail{box|dir} delivery line, which is
effectively handled by an alias to the real account for that address. If
there is no real account for the address in question, then it shouldn't be
an alias in the first place, since the definition of an alias is an
account that doesn't have its own mail storage but points to another one
for that. If you're using valiases to bypass filtering on the "real"
account the better solution is to adjust the filter to ignore (or
otherwise properly process) mail to the alias...
If I'm missing any possible cases, by all means let me know. And I know
this is my opinion, and that others out there have different ideas. I'm
OK if you want to try to extend the functionality of Vpopmail to do more
stuff, just please don't break the current way of doing things.
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
[vchkpw] Anti-Spam Challenge Systems
This is an open letter to everyone on the vchkpw list, though I freely admit that it's primarily targetted at a single individual: If you send a message to the list asking for someone to send you something, and you have an anti-spam challenge filter on your incoming mail, don't expect to ever get a reply. This goes doubly so if you ask to use a piece of software that I've written but not really published for whatever reason (in this case, because it's gotten very limited testing and I just haven't gotten around to it - I'm happy to share). Especially since this list (or any list) is not the place to go around emailing tarballs, since they then have to go to everyone, and it's quite possible that most people don't even care about it. I'm more than happy to contribute back to the community, providing whatever pieces of software I work on for others to use. In return, all I ask for is a little courtesy. If you ask me to email you, don't make me jump through hoops to do so. I think most of the people here would agree with me, but I'm sure I'll get plenty of vocal feedback from those who don't. Everyone has their own opinion, this one's mine. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] 5.4.18 release candidate
> Tom Collins wrote: > >> On Dec 23, 2006, at 6:41 PM, Rick Widmer wrote: >> >>> - Don't update the relay CDB for statically covered addresses. >>> (extended version.) >> >> >> Do we have to worry about a race condition where I do my POP pickup and >> the relay CDB isn't updated with the new timestamp (since I'm in there >> from an earlier pickup) but the entry expires before my SMTP starts? I >> don't think I've ever used the pop-before-smtp feature, so I'm not sure >> on the details of how it works... > > No. Update_rules builds the final cdb file by concatenating the static > addresses in the file specified by TCP_FILE and the dynamic addresses > either from a database or file. This patch only makes excludes the > static addresses. If you are already allowed in by a static entry, > don't bother to manage your dynamic entry... > That is correct - this patch actually helps eliminate race conditions by reducing the frequency of CDB update. Because an address that is covered by a static rule will never be overridden by a dynamic one (since tcpserver is supposed to use the first rule it finds), this won't impact the security of the CDB. If it's denied, you'd never connect in the first place, and if it's allowed it's already allowed and the dynamic rule should never get matched. The reason I say "should" instead of "will" is that that's what the documentation states. I just tested and that's not what actually happens - it takes the best match. So there is one potential problem with this (though I consider it minimal) - if you have a rule that doesn't include the 'RELAYCLINET=""' and/or 'RBLSMTPD=""', you may end up getting denied if you're depending on pop-before-smtp. However, IMHO SMTP-AUTH should be used instead as it's both more reliable and more secure, but not everyone pushes that. So there may be unintended consequences with this patch... I'm not sure how to best address it, but I see 3 choices: 1) exclude the patch from the main tree but publish it as an add-on (not great); 2) include the patch and document the changes in how the CDB is built and works (better, but may cause breakage for some people); or 3) put the code inside an #ifdef and make it a configure option (I'd enable it by default, but it could go either way). I know nothing about configure, so I'm not sure how to do it, but I'd guess it's pretty simple to change... Anyway, those are my thoughts on how it works and the potential consequences of the patch... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] 5.4.18 release candidate
> > > Tom Collins wrote: > >> On Dec 23, 2006, at 6:41 PM, Rick Widmer wrote: >> >>> - SQL backend fixes - Extend length of domain from 64 to 96 in all >>> database backends. Add delete_spamassassin and delete_spam to the >>> limits table. REQUIRES DATABASE STRUCTURE CHANGES! >> >> Since MySQL is the most common SQL backend, we should include the SQL >> statements (ALTER TABLE) someone would have to use to make the >> necessary changes. > > I have a description of the changes in UPGRADE and have asked Joshua if > he has the SQL statements available. If not I'll figure them out and > update UPGRADE. > The following assumes that '--enable-many-domains' is used. If you use '--disable-many-domains', then you need to replace the ALTER command for the 'vpopmail' table with one for each domain table. Also, the 'ip_alias_map', 'vlog' and 'limits' tables only exist if the various configuration options are enabled, so they may or may not be relevant (I only use the latter 2, but I got the ip_alias_map tablename from looking at the code). ALTER TABLE `dir_control` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL; ALTER TABLE `ip_alias_map` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL; ALTER TABLE `lastauth` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL; ALTER TABLE `limits` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL , ADD `disable_spamassassin` TINYINT( 1 ) DEFAULT '0' NOT NULL AFTER `disable_smtp` , ADD `delete_spam` TINYINT( 1 ) DEFAULT '0' NOT NULL AFTER `disable_spamassassin` ; ALTER TABLE `valias` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL; ALTER TABLE `vlog` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL; ALTER TABLE `vpopmail` CHANGE `domain` `domain` CHAR( 96 ) NOT NULL; I'm sure the optional statements can probably be encased inside some sort of conditional, but my SQL knowledge is rather limited... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] 5.4.18 release candidate
> Joshua Megerman wrote:
>> I just tested and that's not what actually happens - it takes the best
>> match. So there is one potential problem with this (though I consider
>> it
>> minimal) - if you have a rule that doesn't include the 'RELAYCLINET=""'
>> and/or 'RBLSMTPD=""', you may end up getting denied if you're depending
>> on
>> pop-before-smtp. However, IMHO SMTP-AUTH should be used instead as it's
>> both more reliable and more secure, but not everyone pushes that. So
>> there may be unintended consequences with this patch...
>
> I think the consequences are - If you explicitly deny access, or
> relaying to an address or address range, a pop connection will no longer
> allow the connection to relay. It is probably very rare, and might
> even be considered a good thing.
>
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.
>> I'm not sure how to best address it, but I see 3 choices: 1) exclude the
>> patch from the main tree but publish it as an add-on (not great); 2)
>> include the patch and document the changes in how the CDB is built and
>> works (better, but may cause breakage for some people); or 3) put the
>> code
>> inside an #ifdef and make it a configure option (I'd enable it by
>> default,
>> but it could go either way).
>
> I'm partial to 2, but hope to hear what others think. I'd rather not
> add any more configure options, [1] so if it is considered too dangerous
> to have enabled full time I'd rather leave it as a patch, and maybe add
> it to the contrib directory. On the other hand, how many people are
> depending on pop before smtp from otherwise blacklisted addresses, that
> couldn't switch to smtp auth? How many are still using pop before smtp
> at all? I haven't supported it for a couple of years.
>
> Do you want to write the README text for this patch?
>
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 :))
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
[vchkpw] Further thoughts on my localrelay patch
ancements: a) Recognize the IP address of 0.0.0.0 or NULL and skip the CDB update altogether (I though of this this morning and have already implemented it). b) Provide some sort of tcpserver flag (e.g., 'UPDATESTATIC=""') on various static tcp.smtp lines to indicate that if a match is found for that rule, DO update the cdb as the dynamic tcpserver flags will override the static ones (such as allowing in an otherwise denied range). 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? Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] A vpopmail farm/NFS framework?
everything aggregated
as well, but never really found a good answer. In any case, I wrote a
patch to qmail that adds the machine name to the received header
("Received by qmail _on _") to make tracing mails easier - I
don't think I've ever publicly released it, but I'm currently working on
releasing a large patch cluster including it, and I plan on putting the
individual patches up as well - email me if you want/need it before I get
around to putting the cluster up...
> Any administrative issues that grow through this distributed model? I'm
> thinking about whether vqadmin or qmailadmin will continue to function
> correctly when run from any of the "farm" machines? Would I just allow
> one "admin" machine for vqadmin/qmailadmin to prevent issues?
>
If you use a SQL back-end for vpopmail and have vpopmail installed and
properly configured on whatever machine you use the admin tool on, you
should be fine. Just make sure you have write-access to the NFS-mounted
directories (via no_root_squash) or you'll be in for a world of hurt :)
Also, the /service directories were handled locally - it was safer to copy
updated run files (many of which needed to be customized for individual
machines) across the cluster than try to run them from NFS.
> Any risks of data collision/overlap or other issues that might surface
> with this multi-server model? Central MySQL should solve most of this,
> right?
> THANKS!
> D.
None that I've seen, except if you need individualized control files on
separate machines. The one that I remember most was the outgoingip
control file (if you use that patch), which we solved by making
/var/qmail/control/outgoingip (on the NFS mount) a symlink for
/etc/qmail/outgoingip, and then having separate files on the local server
with the correct address in each. I know there were a few more, but I
don't remember what.
One last suggestions - we used identical machines with hardware RAID
mirroring for the front-end systems. If we ever needed to add a machine
to the cluster, it was as simple as pull one drive from the mirror set
(replacing it immediately with a spare - the rebuild of a 36GB U320 SCSI
drive took ~6 hours), and pop it into a new system along with a
replacement drive to rebuild on. Keep the network unplugged the first
time you boot it, change all of the hostname and IP references (and purge
the queue if you need to - VERY important to avoid duplicate
deliveries!!!), and then bring it back up. Instant mail server, just add
platters :)
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
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. > Whoa... I wasn't expecting that... Just don't send me flowers or anything, OK? :) > 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. > OK, I think I'm seeing where you're going with this, and while it'll take a little design work (not to mention some help with different backends - I only use MySQL right now), I'm game. > 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. > Maybe - we'll see what works out the best after I do a detailed design on it. >> 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. > Well, I was thinking that a simple way to do it under the current struction was to have --enable-roaming-users="XXX" set the default, compile-time directive, and then be able to override it at runtime (thus keeping the current behavior without any changes). But forcing runtime configuration works too, as long as it's well documented . > 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.) > If we're taking the info out of vchkpw and moving it into an external process, we can design it right from the ground up. This may involve redesigning the relay table to add more info, or have some additional tables to do lookups in, but I'm already starting to get some ideas... >> 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 i
Re: [vchkpw] Further thoughts on my localrelay patch
> Josh just as curiosity what will they mega patch for qmail include? > Funny you should ask... >> Will do (once it's out :)) - 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 ^^^ I'm writing up the real documentation now - I have my patchlog, but it's hopelessly inadequate to provide to outside persons. I'll post both here and to the qmail list when I finish the docs/setup, which will hopefully be sometime this week. Until then, I ask for your patience :) Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Further thoughts on my localrelay patch
userid on the system. > I'm not sure I see the onauth system being used as generically as the onchange one - I definitely see how onchange needs to be available for a variety of functions, but onauth probably is a niche function, albeit an important one... >> 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. > Perl is good for daemons, bad for small client processes that run and terminate. I can handle perl too :) > 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 disk, so that if the service > stops, it can read the cache back into memory and know the status of > the authorized IPs. > > http://qmail.jms1.net/scripts/qmail-updater.shtml > > or maybe keep a directory full of "IP as the filename" empty files, > with the mtime of each file holding the last time they auth'd... and > a reaper process would periodically delete any files which haven't > been touched in more than 20 minutes (or whatever timeout you want to > use)... and a third script would be called whenever an IP which > didn't already exist is added, or whenever the reaper deletes > something, and that third script would rebuild the cdb files... this > is basically how my greylisting program keeps track of things, > although it uses both the "atime" and "mtime" timestamps (to hold the > "first" and "most recent" time each IP appeared.) > > http://qmail.jms1.net/scripts/jgreylist.shtml > I prefer not to do it on the FS, for performance reasons (among other things). But you have some good ideas - I'll check out your code. > 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). Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Local relay patch
On Saturday 06 January 2007 12:56, John Simpson wrote: > 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... > 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... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] onauth Roadmap (WAS: Local relay patch)
Rick Widmer wrote:
> John Simpson wrote:
>
>> 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.
>
> yeah,
>
> vi vpopmail.c
>
> duplicate the existing call_onchange function
>
> s/change/auth/g
> s/CHANGE/AUTH/g
>
> then...
>
> grep POP_AUTH_OPEN_RELAY *.[c,h]
>
> Replace what ever it finds with a call to call_onauth if needed. Keep
> track of what you remove, as you need to analyze it to decide what parms
> to send to call_onauth, and probably write a script for each (supported)
> backend that does the same thing.
>
> Not bad, there are only 14 instances... and you probably won't have to
> do anything but delete some of them. Be sure to keep the ifdefs around
> any calls to call_onauth, we still want to require the same ./configure
> option to enable the functionality.
>
Should be simple enough - I haven't had a chance to look at 5.4.18 yet, so
I'm not sure what the new code looks like and if any changes other than
that will be needed.
>> 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:
>> timestampi.e. sprintf("%lu",time())
>> servicepop3, imap, smtp
>> [EMAIL PROTECTED]
>
>
>
>> thoughts?
>
> You need the remote IP address to handle the existing functionality from
> the command line parms, so yes I think it should be there.
>
> The timestamp is an interesting idea. I would have left it to the
> script to find out what time it was called, if it cared. It sure makes
> a logger easy.
>
> I'm willing to assume the environment of the calling program is
> acceptable until such time as someone shows a reason to build a custom
> environment for the script.
>
OK, it looks like there are several tasks that need to be done, in several
phases.
1) Implement the onauth hook and document the API (should be simple,
unless there need to be changes to the onchange functionality, plus the
design work to make sure the API isn't going to need to be redone because
we forgot about something). Add --enable-onauth-script to configure as a
forward-looking replacement for the roaming-users functionality. Plan to
include in 5.4.19.
2) Create a new program (vrelayupdate?) that calls the existing code that
gets defined if POP_AUTH_OPEN_RELAY is defined using the new API, but link
against the existing code in libvpopmail.a for now. Change vchkpw to call
the onauth API and document that the new program should be used as the
onauth program to duplicate existing functionality. Deprecate the relay
update functionality and document that it will no longer be part of later
releases. I expect to get this into 5.4.19 as well.
3) Remove the non-common code used for updating the relay table and
rebuilding the relay cdb from the core vpopmail and move it into the
vrelayupdate program or it's support files. Move everything into the
contrib directory and provide a method for building it to match the
configuration of vpopmail. It will still link against libvpopmail so that
the various common functions will still be available, but all
auth-before-smtp-relay-specific functionality will be moved out of the
vpopmail code. Plan this for 5.4.20 or 5.4.21, depending on how long this
takes. Possibly have the code moved for 5.4.20 but not move the program
to contrib until 5.4.21. In any case, at that point pop-before-smtp will
officially be removed from vpopmail, and will be supported only through
external scripts. Also, --enable-roaming-users,
--disable-rebuild-tcpserver-file and --enable-relay-clear-minutes=# will
be removed from configure and any use related to that will require
--enable-onauth-script instead.
4) Possibly remove the authentication logging from vpopmailand make it
external, but a quick look at the code shows ENABLE_AUTH_LOGGING to be
pervasive and less likely to be a candidate for an external function,
although maybe just the call to it could be migrated outside (since
vuserinfo, vpopmaild and vdeloldusers all make user of it in addition to
vchkpw).
I need to do a little more looking to see what the exact API should be
(i.e., what info gets passed to the onauth script, but I expect it won't
be much different than what's been discussed here. It's mostly a matter
of walking the code so that I understand it to my satisfaction and think
about what else I can make a good argument for having available when
making the call. I'm leaning towards the timestamp, but I'll here
arguments on both sides. And for now I agree that there's no good reason
to much with the calling environment...
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
[vchkpw] vchkpw/onauth connection types
In developing the onauth API, one of the things that I want to be a part of it is the connection type. Currently, I've got pop3, imap, smtp, vpopmaild and other. vchkpw supports 4 different auth types (POP, SMTP, IMAP and WEBMAIL). It sets the connection type based on a list of known ports (25/465/587 for SMTP, 110/995 for POP and 143/993 for IMAP), and defaults to POP on an unknown conenction. If it gets a POP or IMAP connection from a static list of webmail IPs (defaults to 127.0.0.1 only), it assumes that it's a webmail connection (and there's a bug in that code too, but I'll address that separately). 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)? Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] onauth API
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] $3 is the numeric value associated with the service type. [2] $4 is the current timestamp as generated by time(NULL). [3] [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. [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. [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. 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. 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... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] vchkpw webmailips traversal bug
In vchkpw, you can statically compile in a list of IP addresses that are to be treated as webmail connections for auth purposes. However, the traversal of the list do es a loop based on dividing the size of the entire array by the size of the first element in the array. Since IP addresses can be anywhere from 8 characters (A.B.C.D\0) to 16 characters (AAA.BBB.CCC.DDD\0), this makes it likely that any added addresses will cause some sort of segfault, especially if several large (character-wise) addresses are added (since the default, "127.0.0.1" is only 10 characters). This patch fixes it by NULL-terminating the list of strings, and using that fact for bounds-checking in the for loop... This bug has been present since at least 5.4.13, but my guess is that so few people use this feature (I didn't even know about it until I was walking the code earlier today checking on the connection types!) that it's not likely to be hit very often. Still, it's a bug, and so this patch... :) Also uploaded to SourceForge as bug #1630944. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] vchkpw webmailips traversal bug
On Monday 08 January 2007 18:19, Rick Macdougall wrote: > Joshua Megerman wrote: > > In vchkpw, you can statically compile in a list of IP addresses that are > > to be treated as webmail connections for auth purposes. However, the > > traversal of the list do es a loop based on dividing the size of the > > entire array by the size of the first element in the array. Since IP > > addresses can be anywhere from 8 characters (A.B.C.D\0) to 16 characters > > (AAA.BBB.CCC.DDD\0), this makes it likely that any added addresses will > > cause some sort of segfault, especially if several large (character-wise) > > addresses are added (since the default, "127.0.0.1" is only 10 > > characters). This patch fixes it by NULL-terminating the list of > > strings, and using that fact for bounds-checking in the for loop... > > > > This bug has been present since at least 5.4.13, but my guess is that so > > few people use this feature (I didn't even know about it until I was > > walking the code earlier today checking on the connection types!) that > > it's not likely to be hit very often. Still, it's a bug, and so this > > patch... :) Also uploaded to SourceForge as bug #1630944. > > Thanks. > > I believe that's my patch or patch request at any rate. I'm not sure if > I or Tom C. wrote the code for that. > > Thanks for the patch. > My turn to say oops - As Tom pointed out in response to my sourceforge posting, I was mistaking the sizeof the pointer for the sizeof the string. I've closed the SF bug as invalid, please discard the patch (not that it doesn't work, but the original code is perfectly valid). josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
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.
>
OK, I can see that. More importantly, that's the standard for other
vpopmail command-line arguments ([EMAIL PROTECTED], not userdomain), so
even though it's just more work, it's not unreasonable.
>> $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.
>
I'm torn with this - mostly because I'm not sure that this information is
really that useful (at least right now). Also, I think you and I are
looking at 2 different pieces of information:
I'm looking at the connection type - this is only used by vchkpw to test
against the disable flags to prevent users from authenticating via methods
that they aren't allowed to use. In that case, there's only 4
possibilities: POP, SMTP, IMAP and WEBMAIL, which are #define integers
from 0-3. Also, technically there is no "other", as any unknown
connection is defaulted to POP.
You're talking about the actual service, which vchkpw will set to one of
{smtp|pop3|imap|smtps|submission|imaps|pop3s|webmail|}, depending
on what port (and possibly IP) it comes in on.
Again, the question is what info should we really be passing on to the
onauth script? And the answer is, I'm really not sure anymore :) Unless
we're trying to move the auth logging to the onauth script (which, BTW,
would be MUCH more complicated because there's so much that needs to be
embedded in other tools as well, as opposed to the auth-before-relay
stuff), I'm not sure it's really all that useful...
What does everyone else think?
>> $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.
>
Yes, you're right. This is my first real API documentation and I'm still
getting the hang of things... Timestamp will be sent as "%lu", so that it
can be easily handled by any type of script (shell, perl, C, etc.), and
because it's unambiguous as to what it means (once clearly documented :)).
>> [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.
>
See my above comments. I'm not convinced that compatibility with programs
outside of vpopmail is a good argument, but compatibility with other
vpopmail programs is, so I'll make that change :)
>
>> [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
Re: [vchkpw] onauth API
>>> 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.
>>
> Well, we run into a minor issue, but I think I can resolve it fairly
> simply.We need to return "internal" error codes if we have problems
> running the script, but we need to return "external" error codes if the
> script returns non-zero. I propose that we return codes >= 256 for
> "internal" errors (in the case of ENOENT or EACCES, either bit-shift them
> or add 256 (probably simpler to add 256), and return "external" error
> codes as-is. Either way, 0 is a success. What do you think? I'd like to
> keep our APIs consistant in this manner.
>
>> 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 thought about that and figured why not reuse the existing variable, but
> there's no reason not to use another one either (4 bytes of memory is
> pretty cheap these days :)).
>
In looking at the man page for wait(), the value returned in rv is NOT the
actual return code, it's bit-shifted by 256. You need to use the macro
WEXITSTATUS(rv) to get the actual exit code. So we can return rv directly
or unmodified E{NOENT|ACCES}, and just know that if the return value is >
256 that we have to bit-shift it back to get the actual exit code... I
think that works just fine.
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
Re: [vchkpw] Re: vchpw/onauth connection types
> Joshua Megeman wrote: >> It sets the connection type based on a list of known >> ports (25/465/587 for SMTP, 110/995 for POP and 143/993 for IMAP), and >> defaults to POP on an unknown conenction. > > Sorry, this isn't an actual thread reply, but I just came across an > issue with the vchkpw program itself. > > I use Dovecot for my IMAP server, and to get last auth to work properly, > I have to call the vchkpw program. LastAuth works now, but since vchkpw > defaults to pop, a pop restriction causes IMAP (and webmail) not to > work ;) Now I'll admit this is probably a mistake in how Dovecot does > vpopmail authentication - but I was wondering if we could also set the > connection type based on the binary name. > The connection type is based on the value of the TCPLOCALPORT environment variable, which defaults to 110 if it's not set. I don't know exactly how dovecot works, but if you're not calling it from tcpserver, that's probably what's happening. > For example, vchkpw-imap would set the type to imap. vchkpw-smtp would > set it to smtp, etc. This seems like a trivial change, and would only > require a softlink back to vchkpw to enable. Am I thinking straight, or > am I way offbase? > It's not an unreasonable way of doing things, although vchkpw will try to figure out what the connection type is based on argv[1] if the port is unknown. Maybe the best solution is to eliminate the default setting of LocalPort to 110 if TCPLOCALPORT isn't set, allowing vchkpw to look for "true" (smtp) or "imap" (imap) in argv[1]. I would think that if the local port variable isn't set, we should leave it as an unknown, and not force it to 110 (thus forcing a pop connection down the line). Anyone else? -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Re: vchpw/onauth connection types
> On Thu, 2007-01-11 at 21:30 -0700, Rick Widmer wrote:
>>
>> Joshua Megerman wrote:
>> > It's not an unreasonable way of doing things, although vchkpw will try
>> to
>> > figure out what the connection type is based on argv[1] if the port is
>> > unknown. Maybe the best solution is to eliminate the default setting
>> of
>> > LocalPort to 110 if TCPLOCALPORT isn't set, allowing vchkpw to look
>> for
>> > "true" (smtp) or "imap" (imap) in argv[1]. I would think that if the
>> > local port variable isn't set, we should leave it as an unknown, and
>> not
>> > force it to 110 (thus forcing a pop connection down the line).
>> >
>> > Anyone else?
>>
>> I'd be very nervous about changing the default action. I've already
>> learned my lesson (the hard way) about making tiny changes to existing
>> functionality - even when you think it shouldn't matter to anyone
>> else... it probably does.
>
> That would be my feeling as well - I would prefer to just add
> functionality that does not interfere with anything existing, and
> especially not change anything existing.
>
Well, changing the default LocalPort value won't necessarily cause a
change in functionality, as this is what the code does:
Get the value of the TCPLOCALPORT environment variable. If it's not set
(getenv returns NULL), set LocalPort to 110, otherwise use atoi to convert
the string to an integer and use that. Then, it does a case check on the
value of Localport, and here's why changing the default won't necessarily
break anything: If the port is anything other than
{25|110|143|465|587|993|995}, it checks the value of argv[1] for specific
substrings, and sets the connection type based on that:
a) if argv[1] has "true", it sets it to SMTP
b) if argv[1] has "imap", it sets it to IMAP
c) if neither a) or b) are true, it sets it to POP.
The biggest change that setting the default LocalPort to 0 rather than 110
would do is that it would allow for argv[1] to override the default
setting of POP, and it would set the VchkpwLogName to "vchkpw-0" instead
of "vchkpw-pop3". Since you cannot guarantee that an unset TCPLOCALPORT
is going to mean a pop3 connection on port 110, this seems like a logical
change. For users who are expecting things to work the same way, the only
difference will be the VchkpwLogName string will be different, and if they
are using SMTP or IMAP that doesn't set TCPLOCALPORT, it may well work as
documented.
>> It seems to me that since vchkpw uses TCPLOCALPORT to determine how it
>> is called, and Dovecot wants to use vchkpw for password checking, then
>> Dovecot should handle setting the environment variables properly.
>> Possibly it is a matter of the way Dovecot is being started that is
>> hiding the environment variable. Maybe you can set the environment
>> variable before calling vchkpw.
>>
>> You are running on a standard imap port, right?
>
> Yep - Dovecot (which also provides POP, though I'm not sure if it's a
> seperate
> binary like Courier) has some sort of 'native' vpopmail auth built in. I
> found
> that while it does work to authenticate, at minimum the lastauth data
> isn't updated.
> So it doesn't appear to be complete.
>
>> If Dovecot has a constant value passed into argv[1] I would be willing
>> to add that to the guessing code in vchkpw, but I don't like the idea of
>> adding _another_ block of testing for argv[0].
>>
>> I believe the best answer is to have the right port in TCPLOCALPORT when
>> you call vchkpw.
>
> I agree - I didn't realize there was a TCPLOCALPORT variable to set that
> would specify that - that seems like an easy fix. I'll check with the
> dovecot list.
>
I agree that this is also a correct solution, as this information is
needed to properly authenticate with libvpopmail. However, it doesn't
preclude the change to the LocalPort default for the reasons I outline
above. Also, I don't know what Dovecot passes as argv[1], but if it's
authenticating directly against libvpopmail, then vchkpw never enters into
it and the check against whether IMAP is denied would need to be written
into Dovecot directly...
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
Re: [vchkpw] Qmail with Simscan, SA and ClamAv
> I have also posted this to vchkpw list: > > I have a server with qmail running some 600 email accounts over some > 30 domains. I recently installed simscan, Spamassassin and ClamAv. > It all works really well, but during peak hours (say 300 to 500k per > sec inbound traffic) Thee server starts to bog down and progressively > gets slower and slower until 120 connections are maxed out and the > server starts rejecting smtp connections first and then pop > connections. This is a new AMD 64 bit with 1Gig Ram running on > Debian and running also Apache with php, mysql, and Horde webmail > (with very very few hits per day). If I turn off simscan, situation > returns to normal after a while. I have tried finding some > documentation about how many users and traffic qmail with simscan, SA > and Clam may handle, but it seems there is nothing out there other > than very general stuff like "many users", "thousands of users" > > Perhaps the problem is in my setup and some configuration for > simscan, SA or clam that I have set/not set incorrectly, ot I have > not realized this number of users and trafffic is just too much for > one server. Any suggestions or links to appropriate docs will be most > appreciated. > One thing that I found helpful was to put the simscan temporary directory onto a ramdisk. I have /var/qmail/simscan mounted as tmpfs, forcing the mode to 750, uid to simscan and gid to vchkpw (I use Vpopmail, YMMV), and specifying the size to 1G (my box has 1G ram and 2G swap, so the default tmpfs size is only 512M). Since anything put there is transient by definition, if I have a power failure and the contents die I lose nothing. And since simscan cleans up after itself, as long as you're not getting large numbers of very large emails all at once, it rarely forces the tmpfs to hit swap. I actually have a server with the same memory config that runs 4 separate instances of qmail on separate IPs (consolidation of multiple servers into one box), and "idling" it only uses roughly half a gig of RAM. That's for 4 instances each of qmail and clamd, plus an assortment of other daemons used only for one instance or another and a MySql DB to hold it all together. It bogs down a little on occasion when a large list goes through, but that's all CPU from virus scanning hundreds of emails at once. One other suggestion - if you don't already use it, patch qmail with the external-todo patch - it speeds up send of mail while processing the queue... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] qmail+vpopmail smtp-auth for roaming-users]
> Hi Micheal, > > Thanks for the reply. Indeed, I did use the "--with-authvchkpw > --without-authdaemon" but it made no difference. > > If I understand your email correctly, since I'm using courier-imap 4.1.2 > it is impossible for imap authentication to update the open-smtp file?? > Hence it is IMPOSSIBLE for any roaming users to send mail?? So what's > the solution (if any) - is it possible that ALL users who use > courier-imap 4++ are unable to send email and this is acceptable to > them?? Am I missing something?? > The solution is simple - use SMTP-AUTH instead of imap-before-smtp. If they can authenticate via IMAP, using SMTP-AUTH-patched qmail can also use vchkpw to authenticate against the vpopmail database. I understand the desire to make things easy for the users by letting them use imap-before-smtp, but it's really not the best way to do things these days... If you really, truely must use imap-before-smtp, use a different IMAP server. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] SMTP_VRFY supported?
> Hello, > > I'm trying to use a mail filter appliance with a qmail/vpopmail (gentoo) > install and am running into a issue with the filter generating excessive > email accounts due to the way qmail handles invalid email addresses. > > I'm familiar with the chkuser 2 patch and have tried it with little > success. I am using TLS on my system and the chkuser patch works > exactly one time then begins rejecting even valid addresses. The vendor > that makes the filter suggested using SMTP_VRFY but I'm unable to find a > way to implement this in qmail/vpopmail. > > Can anyone here point me in the right direction? > Sounds like there's something funky going on with the chkuser patch for you - do you have the same problem when not using TLS? I'm not a chkuser expert, but have you double-checked your chkuser settings? Qmail implements SMTP_VRFY, but it doesn't actually do anything. DJB (rightly, IMHO) decided that it didn't make sense to let people constantly hammer your system with VRFY commands to determine who was or wasn't a valid user, and so (per the RFC) qmail's VRFY implementation responds with a message that indicates a non-answer (252 send some mail, i'll try my best) and doesn't actually indicate whether the address is valid or not. Chkuser can result in giving the same information, as it will reject non-valid users, but this at least forces spammers to try to send mail, and get rejections (and possibly dropped altogether) rather than just scanning a qmail SMTP server... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] SMTP_VRFY supported?
> Quoting Joshua Megerman <[EMAIL PROTECTED]>: >> Sounds like there's something funky going on with the chkuser patch for >> you - do you have the same problem when not using TLS? I'm not a >> chkuser >> expert, but have you double-checked your chkuser settings? >> > > The only extra setting I'm using is the CHKUSER_ENABLE_UIDGID. From > what I've read on the Interazioni site this option will cause issues > wtih TLS. I enabled this because qmail-smtpd was unable to run vchkpw > without it enabled. I assume this is because of users/group > permission but even with the qmail & vpopmail user in the same group > vchkpw didn't run. > I don't have it enabled, and I have no problems running qmail-smtpd as vpopmail:vchkpw using tcpserver flags (-u vpopmail -g vchkpw). Which TLS patch set are you using? >> Qmail implements SMTP_VRFY, but it doesn't actually do anything. DJB >> (rightly, IMHO) decided that it didn't make sense to let people >> constantly >> hammer your system with VRFY commands to determine who was or wasn't a >> valid user, and so (per the RFC) qmail's VRFY implementation responds >> with >> a message that indicates a non-answer (252 send some mail, i'll try my >> best) and doesn't actually indicate whether the address is valid or not. >> Chkuser can result in giving the same information, as it will reject >> non-valid users, but this at least forces spammers to try to send mail, >> and get rejections (and possibly dropped altogether) rather than just >> scanning a qmail SMTP server... >> > > This makes sense but doesn't chkuser essentially do the same thing > SMTP_VRFY would do? > Yes and no. The VRFY command is outside of sending mail - a rogue client could connect to the SMTP server, and after issuing a HELO/EHLO greeting, just run repeated VRFY commands to see if a user is valid or not. Chkuser operates in the RCPT phase of the conversation, so a client has to start with a MAIL FROM command, which can be checked, and then each RCPT command can either be accepted or rejected - and chkuser can also be configured to reject ALL users after a certain number of invalid ones, preventing spam to real users if fake ones are also sent. It's a fine line, but it can make a difference. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] alias .qmail-default do not work, qmail complains "message_is_looping"
On Sunday 08 July 2007 03:32, Shaohui wrote: > So you means I should use the original file /var/qmain/bin/qmail-local, > right? But obviously, the original file /var/qmain/bin/qmail-local do not > work after we install vpopmail, do you have any other solutions? And as we > know, the installation guide in vpopmail never mention this file. > Um... have you REALLY read all the documentation on how vpopmail interacts with qmail? The domain-level .qmail-default file is used to call vdelivermail which then handles the rest of the delivery. All you need to do is call vadddomain to create the domain and it will create the proper .qmail-default file for you. Then use vadduser to add you users. From your original message (and thread on the qmail list), it appears that you are trying to run vpopmail by modifying the .qmail-default file at the domain level to run something other than vdelivermail, which DOESN'T WORK. I'm sure you could chain something in front of vdelivermail, but in order to deliver to vpopmil users, you MUST pass the message through vdelivermail. I sugget you (re-)read the documentation, as well as the man pages for qmail-command and dot-qmail, get your system working, and then try to tackle your problem. I suspect that some combination of yor script and a catchall account will do what you're looking for, but since I intentionally bounce all deliveries to non-existant users, I can't really help you with creating new mailboxes on the fly... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] vpopmail 5.4.20 released
> On Wednesday 22 August 2007, Rick Widmer wrote: >> http://vpopmail.sf.net/ >> >> 5.4.20 - released 21-Aug-07 > > Feels odd to ask this, but in the UPGRADE document, it lists the > "pw_domain" > columns as requiring updates, but my databases have just "domain" in them > except for the vpopmail table. > > I've upgraded them manually, but should I be re-naming the columns > manually? > I'd prefer not to take the plunge and ask instead. :) > > Moving from 5.4.17. > Looks like there was a bit of a disconnect early in the coding process (well before I ever heard of vpopmail, which was in the 5.3.x era), and only the vpopmail table has a 'pw_domain' column (to match the rest of the password structure naming, I assume). All of the other tables have a 'domain' column, instead. So I made an error when I wrote the fix and updated the UPGRADE document for 5.4.18 (I think it was that), and incorrectly labelled the column name for vpopmail 'domain' instead of 'pw_domain'. Thus, the relevant section of UPGRADE should really be: ALTER TABLE `dir_control` CHANGE `domain` `domain` CHAR(96) NOT NULL; ALTER TABLE `ip_alias_map` CHANGE domain domain CHAR(96) NOT NULL; ALTER TABLE `lastauth` CHANGE domain domain CHAR(96) NOT NULL; ALTER TABLE `valias` CHANGE domain domain CHAR(96) NOT NULL; ALTER TABLE `vlog` CHANGE domain domain CHAR(96) NOT NULL; ALTER TABLE `vpopmail` CHANGE pw_domain pw_domain CHAR(96) NOT NULL; ALTER TABLE `limits` CHANGE domain domain CHAR(96) NOT NULL, ADD `disable_spamassassin` TINYINT(1) DEFAULT '0' NOT NULL AFTER `disable_smtp`, ADD `delete_spam` TINYINT(1) DEFAULT '0' NOT NULL AFTER `disable_spamassassin`; Note that this is mostly what it said before, with the vpopmail table line changed to pw_domain instead of domain. Sorry I didn't catch this before it was released... Ideally I would think that the column names should be consistent across the tables, but that would cause mandatory breakage, and probably should be held back for a more major release (redo 5.5 or go to 5.6?). At least people will have a greater expectation of needing to read the docs carefully on somethign bigger than a point upgrade :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] Clear Password DB Field Size
Because of my looking at my DB layout just now to check the UPGRADE script, I just realized that there's another field that should probably be changed: pw_clear_passwd is only 16 characters long, and while that's more than sufficient for crypt (only the first 8 are significant anyway), it's insufficient for MD5. After digging the code, there's 2 places that this would need to change: 1) MAX_PW_CLEAR_PASSWD is currently set to 16, meaning that attmpts to set a larger password fail. 2) The column pw_clear_passwd is CHAR(16), so larger passwords won't fit. vgetpasswd() uses 128 character buffers, so we should be able to increase the clear password field to at least 64 without a problem. I'm not sure it really needs to go beyond 32, but I actually have been know to use passwords larger than 16 characters... Just a thought - feel free to overrule me on this one :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] POP3 and IMAP login same username without domain
> I'm migrating a server with Plesk to qmailtoaster (with vpopmail). > I have some email accounts with the same username and differente domains. > Say: > username at domain1.com > username at domain2.com > username at domain3.com > ... > > Using plesk, users could login via POP3 and IMAP using only the username. > I need to mantain this on the new server. > Um... I don't know how Plesk works (I've heard questionable things about it's Licensing status, plus it being closed source - I like to be able to fix my server bugs :)), but unless you are using a different IP address and POP3/IMAP server instance for each domain, I don't see how you could be doing this right now. If you are really using separate IP addresses per domain, compile vpopmail with --enable-ip-alias-domains, and make sure that reverse DNS is configured properly - see http://www.inter7.com/vpopmail/vpopmail.html for more details. There may be other ways to do this, but I don't know about them. Of course, I'd just make the users use their full email address to authenticate, but that's just me :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] POP3 and IMAP login same username without domain
> I have multiple domains in the same IP. > I tested Plesk with the same username in 3 different domains. > I think the way it works is by comparing username and password and > associate it with a domain... Not an elegant solution. > No, definitley not. > When I try to change the password to one that exists on the same > username for another domain it give me an error. > Ugh... that's really messed up. I'd tell you it's a good reason not to use Plesk, but you're already moving away from it :) > If it is like this I think I'm going to inform my users to add domain > to every login. > This really isn't as big a deal as you'd think - most ISPs require this kind of login, and for most email clients it's a one-time change. It's not like they have to change passwords or email addresses to something random. Just give them fair warning (and be prepared for a few phone calls anyway :)). Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Problem with add_alias
On Thursday 06 September 2007 01:18:32 am Rick Widmer wrote: > Alessio Cecchi wrote: > > I'm using vpopmail 5.4.20 with vpopmaild enable. > > > > When i add an alias from a telnet session: > > > > [EMAIL PROTECTED]:~$ telnet mail.pippo.com 89 > > Trying 83.49.65.71... > > Connected to mail.pippo.com. > > Escape character is '^]'. > > +OK > > login [EMAIL PROTECTED] X > > +OK+ > > vpopmail_dir /home/vpopmail > > domain_dir /home/vpopmail/domains/pippo.com > > [...] > > no_maildrop 0 > > system_admin_privileges 0 > > . > > add_alias [EMAIL PROTECTED] [EMAIL PROTECTED] > > +OK > > quit > > +OK > > Connection closed by foreign host. > > > > After i'm unable to send e-mail to the alias: > > > > Hi. This is the qmail-send program at s1.pippo.com. > > I'm afraid I wasn't able to deliver your message to the following > > addresses. This is a permanent error; I've given up. Sorry it didn't work > > out. > > > > <[EMAIL PROTECTED]>: > > Sorry, I couldn't find any host named server.com?. (#5.1.2) > > > > --- Below this line is a copy of the message. > > > > [...] > > > > @400046dea9ab22704ab4 delivery 2089: failure: > > Sorry,_I_couldn't_find_any_host_named_server.com?._(#5.1.2)/ > > @400046dea9ab22738ea4 status: local 0/10 remote 0/20 > > > > > > Please note the problem of the domain name: > > > > server.com?. > > That is where you told it to send mail received by [EMAIL PROTECTED]: > >add_alias [EMAIL PROTECTED] [EMAIL PROTECTED] > I think he's obscuring the real domain name, but the key here is the '?' after "server.com" and before the final '.' - it's how qmail indicates a funky character IIRC. > > Why this? > > server.com doesn't have any MX records, so qmail can't find a host to > send the message to. > But it does have an A record, so if he really was trying to send to "server.com", qmail should have responded with a "can't establish an SMTP connection" message instead. > > Could be the problem relate to the "" of the telnete session? > > No. I agree that it's unlikely, but maybe something else is happening. But I agree that the original poster needs to provide more info, preferably without hiding anything (other than passwords), so we can diagnose it better. Also, the output of valias showing the alias, and perhaps the actual alias DB dump showing it would be helpful too... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Problem with add_alias
>> > Could be the problem relate to the "" of the telnete session?
>>
>> No.
>
> Sorry Rick but the problem is crlf, the domain are only for example (on my
> server i have used real domain name like gmail.com), but the problem is
> the .qmail generated by the add_alias, infact if i run dos2unix
> .qmail-prova
> the alias works.
>
> Also if i open the same .qmail vith vim i see [DOS] for encoding.
>
Actually, looking at the code, he's right - the line in question is in
vpopmaild.c, line 1002:
if ((alias_line=strtok(NULL, "\n"))==NULL) {
The strtok tokenizes after the '\n' (), leaving the '\r' () as the
last character of the alias_line, which would have the exact effect he's
seeing. Looks like the same bug exists on line 1051 as well (identical
code block in remove_alias). Every other instance of strtok() uses one of
two defines for the token list - TOKENS or PASS_TOKENS, these are the only
two strtok() calls using an explicit token list. Patch is attached.
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]--- ../vpopmail-5.4.20/vpopmaild.c 2007-08-22 02:17:45.0 -0400
+++ vpopmaild.c 2007-09-06 09:47:04.0 -0400
@@ -999,7 +999,7 @@
return(-1);
}
- if ((alias_line=strtok(NULL, "\n"))==NULL) {
+ if ((alias_line=strtok(NULL,TOKENS))==NULL) {
show_error( ERR_ALIAS_LINE_REQD, 906 );
return(-1);
}
@@ -1048,7 +1048,7 @@
return(-1);
}
- if ((alias_line=strtok(NULL, "\n"))==NULL) {
+ if ((alias_line=strtok(NULL,TOKENS))==NULL) {
show_error( ERR_ALIAS_LINE_REQD, 1006 );
return(-1);
}
[vchkpw] Re: [vpopmail-devel] vpopmail 5.4.21 released
> Alessio Cecchi found a bug in vpopmaild add_alias command, and Joshua > Megerman provided a patch. If you are using vpopmaild you probably want > to upgrade... > You spelled my name correctly above... > Changelog: > > 5.4.21 - Released 06-Sep-2007 > Joshua Mergeman, Alessio Cecchi > - fix bug in vpopmaild add_alias command But not in the Changelog... :( Kindly fix it and repost the release if you could :) Thanks, Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Decided to make the plunge today on late version of vpopmail
> On two (low volume) machines with vpopmail interfaced with mysql as the > data > store, it seemed to work successfully. I updated the database schema with > no > issues. This is with v5.4.21 > Did you follow the UPGRADE document in 5.4.21 exactly and rename the 'domain' columns to 'pw_domain'? If so, then your DB is now wrong. Apparently the fix I posted about the UPGRADE document didn't make it into 5.4.21... The vpopmail table, and ONLY the vpopmail table, has a column named 'pw_domain'. Every other table should have a 'domain' column, as the earlier UPGRADE document listed (which incorrectly listed vpopmail as having a 'domain' column). The other suggestion I can make is try stracing the new version and see where it fails... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] vpopmail 5.4.22 breaks qmailadmin 1.2.X
> On 2007-09-17, at 1751, Jeremy Kister wrote: > 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 > I think you want it to be an #ifndef, not a #ifdef (I'm not looking at the code right now, and I'm about to walk out the door to go home), a your patch (I think) forces an 8-character limit if you _are_ using MD5, rather than if you're not... Other than that, looks reasonable (and appropriate). Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Mysql table
> qmail-newu: fatal: bad format in users/assign Before pursuing anything else, check this out - qmail-newu (part of qmail, and simply called by vpopmail) is telling you that your /var/qmail/users/assign file is incorrect/corrupted, and that it can't create the users.cdb file from it. Vpopmail uses the users/assign file to track what domains it owns, so if that file is bad you're in for problems. I don't know what field size restrictions are for that (neither the man page nor qmail-newu.c list any), but while that may not be your root cause, it's certainly a part of it... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Info on upgrading vpopmail.
> Hello, > > I have a question regarding vpopmail upgrades. The UPGRADE > documentation states: > > When recompiling vpopmail, you need to recompile all binaries that link > into the vpopmail libraries. These include QmailAdmin, qmail-smtpd (if > you have the chkuser patch applied), Courier-IMAP etc. > > 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? > I don't believe John's patch links agains vpopmail, so you don't need to recompile qmail unless I'm incorrect. You do need to recompile Courier (Courier-IMAP v3.x or lower, Courier-Authlib if you're using Courier-IMAP 4.x). The reason for this is because vpopmail only uses a static library, and thus any changes in vpopmail won't be applied without a recompile. It may work just fine depending on the changes, but you can also see wierd happenings down the line if you aren't consistent. The bottom line is, if you upgrade Vpopmail, you should re-bould anything that links against it Just In Case(tm) :) On a related note, any chance of making vpopmail a shared library? IIRC someone floated a patch around a while back to do just that, but I'd rather see it in the mainline since it does impact those things that link against it... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
[vchkpw] Shared libvpopmail thoughts
Following up on my recent post to [vchkpw], I did some digging back into the history of the shared libvpopmail patch and the discussions surrounding it, and have the following thoughts. 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, and thus am not sure exactly how can be affected performance-wise. That being said, here's my thoughts: 1) A shared library with a stable API would make recompiling outside programs (e.g., QmailAdmin) unnecessary, which would be a Good Thing(tm). 2) There has been some question regarding performance of the vpopmail programs when compiled against shared vs. static libraries. I suggest the following options be added for shared libraries at compile-time: a) --disable-shared - don't build libvpopmail.so, which is what vpopmail does now. b) --enable-shared - build libvpopmail.so, but don't link the vpopmail binaries against it - this gives other programs the ability to use the shared library, but keeps the vpopmail binaries statically linked. c) --enable-shared-binaries - build libvpopmail.so and link the vpopmail binaries against it. Implies --enable-shared. d) possibly, if it's not to difficult, have a --enable-shared-binaries= and/or --enable-static-binaries= option, which takes a list of binaries to link against the stated library, and links the rest against the other. So you could have static vdelivermail and vchkpw, but not vadduser, for example. Not sure if that really is necessary, but static linking does save space... 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. Also, just a supposition on my part, but if you're running (e.g.) courier-authdaemon linked against libvpopmail.so all the time, wouldn't that (theoretically) mean that other dynamically linked vpopmail programs would run faster than the static version since the library would already be loaded in memory? If so, perhaps the speed solution for a dynamic (e.g.) vdelivermail would be to run something that was dynamically linked all the time, so libvpopmail stayed in memory... Anyway, that's it for now - I haven't even tried the patch against the latest vpopmail, though I'm guessing it should be fairly easy (albeing possibly tedious) to integrate since it's not much in the way of actual code changes... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Shared libvpopmail thoughts
>> 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. > Hmm... that's a good point, although AFAIK the API is "stable" with respect to what the functions do for any given config.h. But you're correct that until things are documented and "blessed" (not to mention creating some sort of "official" API change process for the future, even if it's assigning 1 person as the only authority on changes). > 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 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? > Hmm... if we're talking about doing major changes to existing functionality, I'd call that a major version change, as you're going to break things when you upgrade if you don't follow through with the upgrade process properly. As far as the table layout changes, while I understand that it could improve performance some, I'm not sure if it's really that big a deal. I worked on a system with ~6.5K users that had no DB lag time whatsoever, but we also used master/slave mysql over 6-8 frontends at any given time. But again, I'd definitely call that a major revision change. Perhaps the first step is to document the API as it currently stands, and give people the option to build a shared library with the caviat that if you reconfigure vpopmail, you need to rebuild those things that link against it. That would be a 5.5 branch, since it doesn't change the current functionality (much). Then we can in parallel start developing the truly stable API and other changes that will become 6.0, and when we do we can increment libvpopmail.so to indicate the ABI difference. I'm not sure how much I can do to help with this other than ideas, testing and the occasional spurt of inspired programming, but I'm willing to do what I can. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Shared libvpopmail thoughts
> On Sep 25, 2007, at 6:31 AM, Joshua Megerman wrote: >> Perhaps the first step is to document the API as it currently >> stands, and >> give people the option to build a shared library with the caviat >> that if >> you reconfigure vpopmail, you need to rebuild those things that link >> against it. That would be a 5.5 branch, since it doesn't change the >> current functionality (much). Then we can in parallel start >> developing >> the truly stable API and other changes that will become 6.0, and >> when we >> do we can increment libvpopmail.so to indicate the ABI difference. > > I would love to see this happen, but it is going to take a > considerable amount of work. I'm willing to provide lots of input on > the API, but really don't have time to contribute actual code. > I know the feeling... > I can help out with documenting some of the ways that QmailAdmin > interfaces with vpopmail. Getting a new version of QmailAdmin to > compile to a shared vpopmail lib with a single vpopmail.h to describe > the API would be great. As it is now, QmailAdmin actually uses > vpopmail's config.h file at build time. That will definitely have to > go. > Yes, that would be a good step. One of the things that I think needs to be identified is all of the packages that we know of that interface with libvpopmail, and how they do so. That will help us develop the new API so that we can provide all of the necessary program interfaces. > If we use two different names, could we retain backward compatibility > by building a libvpopmail the way we do now (statically linked, apps > may use vpopmail's config.h, etc.) in addition to the new-style, > shared library with a well-defined API? > I don't know enough about how shared vs. static libraries work at a system/compiler level, but I would think this could work. However, I think long-term we want to eliminate the old-style API through the static library just for ease of maintainability. But I don't see a problem with generating both shared and static libraries, and letting the person compiling the package that uses them decide which one to use. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
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. > Conceptually I understand the difference between static and dynamic linking, I just don't understand the low-level mechanics of how dynamic linking works at runtime. But thank you for the comprehensable explanation anyway - I'm sure there are people out there who also appreciate it. > 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". > This part I didn't know - thanks! > 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. > OK - I knew and/or guessed about 3/4 of this, but thanks for clarifying. >> 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. > That's what I was wondering about... >> 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 the authentication modules. > > i can also see having "libvpopmail.so" for the client-facing > programs, then modules like "libvpopmailauth_cdb.so", > "libvpopmailauth_mysql.so", and so forth, for the back-end code to > handle the mechanics for that particular authentication back-end, > similar to how courier-authlib is structured. > That's not a bad idea - IIRC you can dynamically link shared libraries to other shared libraries, so the actual function calls could be handled via config data and function pointer arrays... >> 2) There has been some question regarding performance of the vpopmail >> programs when compiled against shared vs. static libraries. I >> suggest the >> following options be added for shared libraries at compile-time: >> a) --disable-shared - don't build libvpopmail.so, which is what >> vpopmail >> does now. >> b) --enable-shared - build libvpopmail.so, but don't link the >&
Re: [vchkpw] Shared libvpopmail thoughts
> On Sep 25, 2007, at 10:06 AM, John Simpson wrote: >> 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. > > 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 > > Just for reference, here's the .dir-control file for that server: > > 116 > 0 > 3 > 0 0 0 > 61 61 61 > 0 2 2 > 5 0 0 > 5 > > 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. Just for reference, I have a patch that does a lot of this for the MySQL backend. It's up on SF in patches, #1619600, and could probably server as a basis for this type of code everywhere. There's also a separate patch that allows per-domain control of the # of users per directory, also just for MySQL, but again it could serve as a starting point. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Shared libvpopmail thoughts
On Tuesday 25 September 2007 08:00:16 pm John Simpson wrote: > 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. > Yeah, that sounds about right - I'm great with patching (I learned C (I had experience with Basic & Pascal previously) by pulling in code from about half a dozen different MUDs and combining them into one), and I can take existing concepts and make programs for them moderately well, but I've rarely done full-scale development from the ground up. I've got a couple of things that I made from ground-zero that I'll get around to releasing someday, but I'm less inclined to spend my day doing all of the necessary things for proper software development than tinkering :) And I'm right with you as to poking holes in ideas - I have a tendency to "think outside the box", occasionally to the annoyance of the people I work with... > >>> 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? > I can see it either way, but it's one of those things that doesn't really drive the code development, so it can be decided later :) > 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. > Sounds good to me - I'm on the list, so I'll see it there (and am cc'ing it here). Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Shared libvpopmail thoughts
> Tren Blackburn wrote: >>> -Original Message- >>> From: DAve [mailto:[EMAIL PROTECTED] >>> Trying to figure out dir-control gave me a >>> headache and I never did get anyone to own up to knowing how it >> worked. >>> If someone would fix it, I would provide a 6 pack of Jones (any >>> flavor), >>> a carton of Marlborough reds, some tokens, a Magic Eight Ball, and a >>> big >>> bag of twizzlers to sweeten the deal. >>> >>> Dave >> >> Oooh! That's a sweet deal...I'll throw in a 6 pack of Beer from Canada >> from the brewery of your choice! >> > > Traction! Finally! I'll up the ante to guaranteed 24 hour turn around on > testing any fixes, I'll setup a VMWare server just so I can test any > patches. > > But that's not all... I will also throw in a pristine copy of a Mac > rescue CD with all OSes from 7.1 to 8.6 including all patches, AND > bottle of Jose Gold. Shipped of course, at no cost to the programmer who > fixes dir-control. > I don't have any suggestions on exactly _how_ to fix dir-control at this time, but I can try to explain how it works, since I did a lot of digging into it to figure out how to do backfills for my patch. This info is based on the mysql dir_control table, but it should be (mostly) correct for all backends. The first entry in the domain column, dom_# is the placeholder for the domain directory, and uses the vpopmail uid as the value of #. All other entries use the domain name for the real vpopmail domain (no aliases). The second entry, cur_users, is the current number of entries in the domain - this is important, because when this number is divisible cleanly by 100, it increments the directory counter. This is why I wrote my patch, as the number doesn't accurately reflect the number of users in any given directory, just the total for the domain. Also, the 100 is a compile-time value, although I have a separate patch that allows an extra column in this table to change it on a per-domain basis. The next 2 columns, level_cur and level_max, indicate how deep the tree is and how deep it can go. 0 means you're in the root directory, with no hash dirs. I think vpopmail supports going 3 levels deep (///), but I've only ever seen it go 2 (and onle because of lots of deletions causing the above problem). I'm not sure why this is in the databse, but I guess it's there so you can change it to 1 or 2 to prevent hashing or limit it to 1 deep - I haven't tried it. After that, there are 3 each level_start and level_end columns. This indicates what characters in the hash list are available for use. The list consists of "[0-9][A-Z][a-z]" - I'm guessing these fields are there so you can limit the hash characters to less than that, but again, I haven't tried it. Also, whil you can change the hash list, it's hard-coded at compile time and I've never seen reason to mess with it - see bigdir.c for details. Next, there are 3 level_mod fields. These are actually kinda pointless, since they tell you the offset from the end of the root domain name where the hash directory is located, but since the hash dirs are always single characters (unless you set it all up manually - which I guess you could do), these values are static and cannot change, so why they're in a database I have no idea. Level 0 is 0 because the hash dir is at /X, level 1 is 2 because it's /X/Y, and level 2 is 4 because it's /X/Y/Z. Next we have the level indexes, which is just the index in the hash list for that level of hashing. It starts at 0 for each level when the DB is created, but really gets initialized to level_start when it's first used. When a deeper level maxes out at level_end, the higer level increments and the maxxed out level goes back to level_start. If the topmost level maxes out, it creates a new level - no idea what it does if it maxes out at level 3, as that would imply (although by no means guarantee, since there's the dir increment issue mentioned above) 99 + (100*62) + (100*(62^2)) + (100*(62^3)) users are already on the system (that's potentially over 24M users, and even with deleting and re-adding users, would require over 200K instances where the user count was exactly divisible by 100). Finally there's the_dir, which is the actual string of the current hash directory - an empty string for no hash, "X" for level0, "X/Y" for level1, and "X/Y/Z" for level2. This is used for creating the new user directory when adding users, and gets changed whenever the hash changes. I hope this helps - I know just writing it has given me some ideas about things that can be changed/simplified with it, but I have to get back to me real job for the moment :) Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] clamav: 0.90.2 is slow?
On Wednesday 10 October 2007 08:13:29 pm Quey wrote: > If you goto www.clamav.net there is a link to it. > I heard they corrected the problem you mention in current, but clam is > still way to slow compared to other scanners so I don't use it anymore. > Q > Are you using clamscan or clamd/clamdscan? If the former, that's why it's so slow - see if you can switch. Also, what interface to your AV software are you using? Something like qmail-scanner that's a perl script is much slower than qscanq or simscan, which doesn't have the overhead of launching perl with each invocation. One other hint - something I do for all my servers (I use simscan not, but I've also used it with qscanq in the past) is put the scanning directory onto a ramdisk (I use tempfs these days, but a true ramdisk would be even better if you can dedicate the memory to it). It prevents the excess disk I/O overhead that slows the process down, and since it's transient data anyway that shouldn't get through in case of an error, the fact that the scanning space isn't crash-proof is a non-issue... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] [OT] VPS recommendations to offload spam/virus scanning?
> If, over time, the VPS becomes overloaded, I should be able to pay
> for a larger resource allocation with my VPS provider, or just
> duplicate the VPS and start another instance with it's own IP and
> have equally-weighted MX records point to each. I'd probably even
> host the VPS copy with a different provider for redundancy.
>
> Thoughts? Recommendations?
>
Don't use Verio - we have a system right now and they keep mucking up my
startup configuration, putting crontabs back that I've deleted, and
semi-randomly restarting services (including those I've turned off) every
time the do an OS update (they "relink" just about everything, which is
good for binaries but bad for configuration files...). I've already
spoken to someone once, and it seems liek they're still getting the hang
of doing it on Linux (they have apparently done this for a long time with
BSD). Probably great if you just need a {random|generic} linux box to
work with, or want all their default services running, but we're using it
for external nagios monitoring and I want nothing running that isn't
needed for that...
Josh
--
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
[EMAIL PROTECTED]
Re: [vchkpw] Problems with defaultdomain when authenticating from courier-imap
> Hello there, > > I admin a server running qmail, courier-imap and vpopmail. > Courier-imap authenticates against vpopmail, using authvchkpw. > > I recently tried to configure defaultdomain but it doesnt work on IMAP. It > works for POP though. > If you reconfigured vpopmail and rebuilt it, but didn't rebuild courier-imap/authdaemon, you're still using the old vpopmail library. If you're using qmail's pop3 daemon, it uses vchkpw directly, which is why it works. Remember to ALWAYS rebuild EVERYTHING that links against vpopmail (including qmail, if you're using CHKUS(E)R) anytime you rebuild vpopmail... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:473081d932007023912837!
Re: [vchkpw] Two qmails in same machine
> On Thu, 8 Nov 2007 14:01:07 +0100 (CET) > [EMAIL PROTECTED] wrote: > >> I'm gonna setup a qmail mailserver for mailscanning for a huge >> site... I have think that setting a qmail with qmail-scanner for real >> time scanning could be too slow because perhaps could arrive there... >> don't know 300 simultaneos mails.. so I think that could be better to >> setup a qmail-mail-server that only does rcpt checks and mfchecks in >> the Internet site and another qmail server not listening in internet >> interface that makes mail scanning in a reasonable time and in a >> reasonable number of simultaneous scans... (don't know 50 >> simultaneous for example...). The internet qmail server will pass >> from for example 50 to 50 mails to scanning qmail server... and this >> last to pass to they're respective mailservers... it's only going to >> be a scanning mailserver... >> >> So I have think that I could compile qmail one time and copy to two >> different locations for example /var/qmail and >> /var/qmail-scanning-server... is this possible? and is this possible >> without having two different vpopmails? two different databases for >> smtp auth... (Internet qmail scanner will be relay too) two >> differents tcp rules file... so could I share everything between them? >> >> What do you think about this idea have just had? > > I think you should off load the processing work. Look into running a > remote clamd/spamassing, or setup multiple mail hubs jms has a guide on > that at http://qmail.jms1.net > Not only that, but I would look into an alternative to qmail-scanner. It's a great package (and the one I started using to do virus scanning way back when), but the overhead of launching perl for each scan can be a killer. This is especially true if your concern is about lots of messages at once. I'd suggest looking at a compiled queue replacement program, like simscan or qmail-scanner (I've used both - I currently use simscan, but only because it's still being developed and I'd like to eventually use it for spam scanning as well). Also, if you don't do the virus scanning at the initial SMTP level, you end up bouncing viruses... Josh P.S. One last hint: put you scanning directory on a ramdisk - it speeds things up a ton! Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:473322fd32009061814407!
Re: [vchkpw] Two qmails in same machine
On Friday 09 November 2007 04:52:16 am [EMAIL PROTECTED] wrote: > OK then so I could have a box in wich I do... > > take qmail sources and patch them with johns (great and nice) patch... > > make setup check and ./config-fast fqdn > after this > > after this > > change /var/qmail for /var/qmail-scanning-server in conf-local... and again > ./config-fast fqdn > Close, but this will actually not work. The value in conf-qmail gets compiled in, so you need to do a "make clean; make setup check" again after changing it. My suggestion is that you actually keep 2 copies of your qmail source tree in case you need to recompile for whatever reason, that way you know you're rebuilding the correct one... > after this setup proper supervise scripts and I could share between two > qmails vpopmail (and his ddbb), tcp.smtp.cdb file and all and only have to > be careful that when I add a domain with vpopmail or anything else to > rsync files modified by vpopmail in users for Internet qmail... and in > internet qmail to have smtproutes file throwing all mail passed rcpt to > check (that will be of course on Internet server) to localhost listening > qmail server that scans mail... then this is all? am I wrong? > > and that's it??¿ there's no any known reason because this could crash... I > mean there's no specification by John Simpson or Dan Bernstein that this > shouldn't done then? > Multiple qmails using one vpopmail isn't something I've done, but multiple qmails on one box is something many people have done, including myself. There's no reason I can think of that sharing vpopmail would be a problem as long as you had all the right config files in place. Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:47345d2932006435332393!
Re: [vchkpw] Re: Upgrade to Vpopmail 5.4.26 and .qmail-default issues
> You do raise a good point, I wish Gentoo would get that part of it right. > Deviating from the standards are not a good idea. > I love Gentoo, but every now and then the do something boneheaded that makes me think that I should bail on it for KUbuntu or something like that. The only thing that's kept me on it lately is that while I'm no longer on the bleeding edge (I use a thinkpad R50p - at the time I got it, Gentoo was the only flavor I could tweak things with properly and still use "official" packages rather than rolling my own and having to remember to upgrade it manually), I still do occasionally tweak things (and rebuilding my primary workstation is a pain :)). Most notably they seem to have had some people with strange ideas of how to maintain qmail/vpopmail etc., but since it was their sandbox they got to make it so... Personally, no matter how good the maintainer, I prefer doing source for qmail/vpopmail et. al. - that way I _know_ what it's gonna do (or at least what I'm expecting it to do :)). Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:477bf638310544466613776!
Re: [vchkpw] Feature support questions: CRAM-MD5, SPA/APOP, SSL
On Friday 22 February 2008 06:00:15 pm Nick Bright wrote: > I'm working on adding security features and compatability to my server, > which is currently running vpopmail 5.4.17. At the moment, everything is > working fine, but there are many features my system doesn't support. My > end goal is to support virtually any combination of server options in > Outlook Express. While personally I detest OE, it is without a doubt the > most commonly used email client, so I'd like to make sure I support it > as well as possible. > > Currently, if someone check marks "Secure password authentication" in OE > (either for SMTP or POP), it does not work. Is it possible to get > qmail/vpopmail to support that option for both POP and SMTP? > > I've already got SMTP Authentication & SMTP CRAM-MD5 working properly, > based on the vpopmail contrib patch for such; as well as IMAP-SSL, > IMAP-TLS (courier-imap). > > However, courier-imap doesn't seem to want to use CRAM-MD5. Is there > something specific about vchkpw that would cause that to not work? > > Does anyone on the list know if there are patches for qmail-pop3d to > support CRAM-MD5 and TLS? I've already reviewed getting STUNNEL going, > and while I haven't gotten it working yet, I think I'm close. > > I don't need step by step instructions, as I've been maintaining a > qmail/vpopmail server for several years; but I would appreciate any > pointers towards good patches for supporting these features - if they > exist. > Unpatched, vchkpw currently only supports CRAM-MD5 for SMTP authentication. IMHO it's at least a misfeature, if not a bug. There's a patch at http://alex.zeitform.de/qmail/patches/qmail-popup-auth_cram_md5/vpopmail-5.4.x.patch that adds it for POP connection, but not IMAP. I've never gotten around to trying to add CRAM-MD5 auth to IMAP, as I just use IMAP over SSL to cover that, but it should give you pointers about where to check for how to add the support to vchkpw. If you do add IMAP CRAM-MD5 auth support to vchkpw, don't forget to add it to you IMAP capabilities line :) As for qmail-pop3d, IIRC there's not much that needs to be done to support CRAM-MD5 directly - just make sure it advertises the correct challenge in the banner. qmail-pop3d doesn't do any authentication directly in it - you need a cram-md5-enabled checkpasswd program. Direct TLS support can be added via at least one patch that I know of, using UCSPI-TLS - see http://www.suspectclass.com/~sgifford/ucspi-tls/ucspi-tls-qmail-howto.html for details (Note: this also patches qmail-smtpd, and thus can conflict with other SMTP-SSL patches...). IIRC, you should be able to find most of this stuff on qmail.org... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:47bf6362310541819949514!
Re: [vchkpw] Distribute Qmail + Vpopmail bundle
On Saturday 23 February 2008 01:55:14 pm Nick Bright wrote: > While the qmail sources are available, it is not GPL. It's my > understanding that the way qmail is licensed specifically forbids > repackaging. > Um, no. As the original poster stated qmail is now in the public domain, which means there is not only no restrictions to its distribution, there's not even any license anymore. And please try not to top-post :) Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:47c07799310544733214484!
[vchkpw] CHKUSER Bug (present in 2.0.9)
I just found a chkuser bug, which I will try to fix if the author doesn't beat me to it :) Bounce messages (i.e., from <>) are accepted for non-existant remote recipients. In our case, we have a rogue client who we used to perform secondary MX services for and stopped because 99% of the mail was spam that they were rejecting and leaving us to bounce. Unfortunately, no matter how many times we try, they refuse to remove the secondary MX record that lists us, so we get lots of messages sent to us that we reject because the domain is not in any of our control files. However, I noticed a couple of bounce messages for them in our queue today, and upon further investigation found that CHKUSER had allowed the null sender to relay despite the user being non-existant on the system. Even more interestingly, it seems to be a random occasional thing - I see other bounces (including one to the same user) getting rejected. The only difference I see is that they are coming from different hosts out of google, but that's all I can say. Here's the CHKUSER log messages for one accept and on reject for the same user: @4000480f8d7f04132104 15437 CHKUSER relaying rcpt: from <::> remote <:fg-out-1718.google.com:72.14.220.157> rcpt <[EMAIL PROTECTED]> : client allowed to relay @4000480f94c100eddc94 18912 CHKUSER rejected relaying: from <::> remote <:nf-out-0910.google.com:64.233.182.189> rcpt <[EMAIL PROTECTED]> : client not allowed to relay Any ideas? Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED] !DSPAM:48149113120507223516693!
Re: [vchkpw] vpopmail development
On Monday 12 January 2009 07:48:17 am ISP Lists wrote: > Can someone please provide a brief discussion as to when a vpopmail hashed > folder tree becomes "big enough" to warrant backfilling? Or, is "big" > just one concern amongst others such as: "rate of deletes and adds", > "filesystem choice"... > I'm not quite picking up why the backfill is important. > Well, I don't know what other people are considering "too big", but I actually wrote a backfill patch when I was working at a medium-sized college. We kept all 62 top-level hash directories on separate partitions, but didn't ever want to go to second level hashes - and with ~1200 adds (incoming freshmen) and deletes (outgoing seniors) every year, this became an issue pretty quick. The other issue with "backfill" is that the current implementation makes it so that you can easily exceed the 100 users per hash dir limit by deleting users from prior hash dirs and then adding new ones since the only check for a new hash dir is "total users/100". My patch and the reasons therefore can be found at http://sourceforge.net/tracker/index.php?func=detail&aid=1619600&group_id=85937&atid=577800. The main reason it's not currently slated for inclusion is that it's for the mysql backend only, and whatever process is used to provide backfill must be available for all backends. One last note - the idea of maintaining a list of backfill "slots" in a text file is a pretty good one, but it still doesn't address the issue of not properly calculating the number of users in a directory... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:496b440e32671399810511!
Re: [vchkpw] vpopmail development
> Joshua Megerman wrote: >> One last note - the idea of maintaining a list of backfill "slots" in a >> text >> file is a pretty good one, but it still doesn't address the issue of not >> properly calculating the number of users in a directory... > > What are you referring to when you say it doesn't properly calculate the > number > of users? The current hashing structure keeps track of additions only. > Once users > are removed, it is no longer up to date with correct user counts. That's > what > we're addressing with this proposed patch. Hmm... you may be right (that's the problem with posting first thing in the morning). The issue probably is more of a factor for existing systems that have done lots of adds & deletes over time than for new installations. As long as you provide some sort of script to properly calculate the new backfill info file, I suppose the issue becomes moot. Of course, there's still the issue of overpopulated directories and moving them out, but that's a different problem... Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics vpopm...@honorablemenschen.com !DSPAM:496b5efa32678902916388!
