[vchkpw] Re: autoresponder/vacation
Charles Sprickman writes: > On Tue, 4 Nov 2003, Paul L. Allen wrote: > > Sqwebmail's filters do this and more. You don't have to use Sqwebmail > > for them to take effect, only to define them > > Hmmm. I hate the look of that thing, The cosmetics can be changed. I found the user-interface for the filters to be unintuitive, but I'm told that those used to Outlook can figure it out (if they were competent with Outlook). > Perhaps I'll see what kind of maildrop file it writes for vacation > and steal that. If you're just doing this for intelligent people with shell access then that may be the simplest answer. For us, the ability for customers who are five cans short of a six-pack to be able to set up vacation responders without having shell access is important. > Although the qmail-autorespond has some tempting features, including > mysql support for storing the "away message" and the list of email > addresses it has replied to. With the sqwebmail filters you can tell it to save the mail that people sent you (to a sub-folder if that's what you want) - surely better than only knowing who mailed you but not knowing what they wrote. But the most important feature (from my perspective) is that it can be set not to reply to the same address within a specified period of time. Waking up to find all my disk space eaten by a vacation responder loop is one of my recurring nightmares. > Plus I think I can maintain some qmailadmin compatibility. That, as yet, has not been officially dealt with. There is still some disagreement as to the best way to handle it. -- Paul Allen Softflare Support
[vchkpw] Re: autoresponder/vacation
Charles Sprickman writes:
> > I'm finding that autorespond doesn't look like a good choice for people
> > used to a standard vacation responder
It is a BAD choice for a vacation responder. It lacks many features
ESSENTIAL in a vacation responder. You might as well ask if sticking
your naughty bits in a mincer is a good choice for people used to real
women. It is THAT bad.
> > Would other programs be "plug and play" (forget qmailadmin usage for a
> > moment)?
If you use sqwevmail and maildrop then you can do a lot better. Ezcept
that there is still a dispute as to whether this stuff should be handled
in vpopmail or qmailadmin. I have a quick and dirty hack that adds what
is necessary to vpopmail (it doesn't deal with quotas but somebody sent
me a hack to my hack which is claimed. to deal with quotas).
> > Some things I'm looking at:
{...]
Sqwebmail's filters do this and more. You don't have to use Sqwebmail
for them to take effect, only to define them
--
Paul Allen
Softflare Support
[vchkpw] Re: qmail installation script 1.3.6 final release
Nick Harring writes: > That's funny, it looked a lot like signal to me. Not only did I refer you to a seminal work by Claude Shannon from the late 1940s, I gave you a summary of the salient details - yet you fail to understand. A new subscriber to this list who has not checked the archives, or somebody who does not read every message (whether through laziness or a broken mail system) will regard the first appearance of what most of us consider to be noise as being signal. > Obviously the announcements aren't that regular, since I've been > subscribed to this list for something like 8 months now, and this is the > first one I remember seeing. Congratulations. You've been here longer than I have. The only thing is that, even with my notoriously-poor memory, I remember seeing MANY announcements from him. At least more than one a month. > I have no real desire to get into some large debate about this, however > I would definitely say that I vehemently disagree with applying a term > like entropy to questionably off-topic messages to a mailing list. Then you have no understanding of information theory. The use of the term "entropy" is not some metaphor or simile: information and entropy share the same dimensional units. To understand why, you should google for "Maxwell's Demon" and then do a lot of reading from there. > If you're so thoroughly concerned with signal to noise on a list that > subscribe to, I'd recommend unsubscribing. That would be your recommendation. It has the benefit to me of losing what I consider to be noise (and the benefit to some others of reducing what they consider to be the noise of some of my posts). It has the disadvantange to me of losing the signal (and the disadvantage to some others of reducing what they consider to be the signal of some of my posts). I consider trying to improve the signal-to-noise ratio to be a better approach. As you seem to have failed to note, I have regularly pointed out that "search the archives" is a bad answer. Because after a few months, the first few hundred hits you get from Google are "this has already been answered, search the archives." This is my empirical experience and nobody has yet said their experience is different. An FAQ, antiquated as it may seem, does the job a lot better than an archive search. An FAQ that pointed to the latest version of his installation script would keep us happy and keep him happy. This is how the world used to work before Google, and how it still needs to work when dealing with mailing lists. Google is NOT a substitute for an FAQ. Anyone who thinks otherwise already has all the answers and has no empathy for anyone who does not have all the answers. > Particularly since you've demonstrated that you're quite skilled with > vpopmail, so its doubtful you derive any real benefit from the list, The benefit I gain is in spotting proposals that would be detrimental to some users of vpopmail and suggesting alternatives that would allow more people to be happy. This is not entirely altruistic, because the reason I spot stuff like that is because the proposals would also be detrimental to my usage. I figure that I'm behaving ethically if I can provide an alternative that keeps the proposer happy and keeps me and a reasonable number of others happy without significantly higher workload on the developers. Do you disagree? > other than the emotional highs you get from tearing into people. I only tear into people I believe (I may, in specific cases be wrong) to be foolish. I get far greater satisfaction from helping people. Then again, one might consider forcing people to understand when they are being foolish as helping them overcome their innate disadvantages at perceiving reality. YMMV, depending what universe you inhabit... -- Paul Allen Softflare Support
[vchkpw] Re: passwd
X-Istence writes: > He cant do MD 5 auths, or does vchkpw allow for MD5 auth logins? If my unreliable memory is not letting me down, it can do CRAM-MD5 if you have plaintext passwords set. For some versions of vpopmail. -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail pasw encryption change..
Reinis Rozitis writes: > To be sure in that way if dont provide previously used salt (in the user > passwords which havent been added using 'vadduser') in crypt will the > authorization through pop work? > > Theoretically salt is the first 2 symbols, but will vpopmail (vchkpsw) > understand/use that? As I already told you, it uses the same underlying system crypt routines that passwd does. If you created your passwords using crypt, and the salt consists of valid salt characters, vchkpwd will understand them whether they are old-style DES or new-style MD5. These days vadduser and vpasswd will use the new-style MD5 crypt but vchkpw will copes with either (I'm not sure if it accepts some of the even newer crypt algorithms available on some systems: it's possible to code things so it's future proof and it's possible to code things so it's not). Of course, if you don't believe me, you could always try it and see... -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Nick Harring writes: > Storing cleartext passwords is generally horrible security, so this and > that don't really relate to each other. Except to the extent that vpopmail now supports cleartext passwords (I have a vague memory they're needed for CRAM authentication) > I whole heartedly agree. I've been poking around with #ifdef'ing around > the seeding of srandom, however I think your later suggestion of just > replacing rand() with reads from /dev/urandom is the Right Way. It's slightly more efficient not to seed rand if you're not going to use it. > Brute force is not the only attack. Precomputed attacks can be very > effective if the salt space is small. > > Precomputed attacks are brute force, I beg to differ. They are force, but not brute force. Brute force is trying random passwords until you succeed. A precomputed attack relies upon the fact that many people choose poor passwords, as does crack. Neither are brute force because they reduce the search space in a semi-intelligent fashion. In fact a precomputed attack is somewhat more intelligent than crack as the computer-intensive part is stored for re-use. > Precomputation just reduces the time frame required to run said brute > force attack. If you're guessing at each element, without any feedback > or algorithm other than trying a list of sequential possibilities, > you're brute forcing. Any algorithm that gives you an improvement on purely random guesses can no longer be considered brute force. > > I would add more #ifdefs to replace the call to rand with a read from > > /dev/urandom. Using /dev/urandom to seed rand() only gets you 32 bits > > of entropy (on most architectures). > > This is the Right Thing imho. Indeed. If you have /dev/urandom available what's the point of using rand at all? Using it to seed rand is slightly better than the seed suggested by Wall but doesn't buy you much extra entropy and never more than 32 bits (on most architectures). -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail pasw encryption change..
Roze writes: > The idea is such: There is an existing user database which I have to move > to a mailsystem (qmail + vpopmail + mysql). All the passwords are > encypted (no way to get plain-text) (with standart CRYPT) though there > is also SALT provided which is 2 first symbols from username. Just copy the crypted passwords over to the relevant field in the MySQL database. Vpopmail uses standard unix crypt calls. The newer versions of vpopmail will create MD5-crypted passwords instead of DES-crypted passwords on systems that support it. Either style of crypted password works. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
I'm going to try to answer both you and Tom at the same time. One of the few times I didn't bother checking mail at least once after finishing on Friday night and I have over 300 waiting for me on Monday morning. Nick Harring writes: > Tom Collins wrote: > > For generating a salt, I think we're fine with the following > > initialization: > > > > srandom (time(NULL)^(getpid()<<15)); Better than what you have, but I suspect that if Larry Wall came up with the solution I quoted he'd given it a lot of thought and rejected simpler solutions for valid reasons. > > I think it would be extremely difficult to predict the salt of a > > generated password, and even if it was possible, it doesn't really > > matter. Not if you store cleartext passwords too, that's for sure. > > Knowing a password's salt but not the encrypted password > > doesn't help you to crack it. If you can get the password file somehow, you get both the salt and the crypted password. And you're right that if somehow you have only the salt, or can predict it, it doesn't help you crack the password. But I am thinking of the case where the password file is (somehow) stolen and does not have cleartext passwords. If the random seeding process restricts the range of salt greatly, then a precomputed attack becomes more feasible. After all, it is the relatively small salt size and the abiliity of computers of a few years ago to mount precomputed attacks that led to modern unices replacing the old DES crypt with an MD5-based one which had much larger salt.. > > If you were trying to guess a randomly generated password, That's the other problem. If the random password generation in vpopmail uses the same seed method, the password space may be a lot smaller than we would like to think. > > If you knew a process ID range and time range for when the password > > was generated, you could try thousands, if not millions of seeds to > > find one that generates the salt. At that point, you could continue > > the password generating routine to determine what the random password > > was. You don't need to compare the salt to see if it's right, you just guess the initial seed and go through the same process that vpopmail does - either you get the right password or you don't. If you have an idea of the time you may find that the current seed generation drastically limits the seed space even if you have to take random guesses at the PID. My gut feeling is that the method currently used does reduce the seed space (but I'm not mathematical enough to prove it). Remember that rand() is entirely predictable if you know the starting seed, so no matter how many characters in the randomly-generated password, the actual entropy is no larger than 32 bits (the range of the initial seed) and possibly a good deal lower if the seed generation is locked into a small subset of that. With /dev/urandom you get a good deal more entropy for password generation and for MD5 salt. > While I would tend to agree that that might be "good enough", I would > also say that if its feasible it'd be much better to check for > /dev/(u)random at compile time and if present then use that. It's extra coding. :( But I think i's worthwhile. > I wouldn't bother changing the existing seeding function for rand, as > long as the only thing its being used for is salt generation. If I read Tom's reply correctly, it's also used for randomly-generated passwords. > The salt isn't really a route to attacking the password See above. If somebody can read the password file, the entropy of the salt is all that makes a precomputed attack infeasible. In some organizations, it is considered important to guard against that even if the fact is that if somebody can get the password file you probably have a lot more to worry about than that. If you use an off-site backup facility run by another company, how do you know that somebody there won't go through your backups and get the password files and then send a mail in one of your user's names that costs you a lot of money? > All it does is lower the brute force workload by a certain amount, Brute force is not the only attack. Precomputed attacks can be very effective if the salt space is small. > I would think just wrapping the srandom seeding in #ifdef's and adding a > check in configure would work, I would add more #ifdefs to replace the call to rand with a read from /dev/urandom. Using /dev/urandom to seed rand() only gets you 32 bits of entropy (on most architectures). -- Paul Allen Softflare Support
[vchkpw] Re: qmail installation script 1.3.6 final release
X-Istence writes: > I agree, that is totally not right. If he thinks he has something great, > let him tell others, it has been quite usefull for quite a few people > that asked me for help. Claude Shannon. Information Theory. Entropy. Do these things mean anything to you? Well, if those things are beyond your intellectual capabiilties, then do a google search on answers that have "search the arhchives" and see if you can find an answer to the question posed in a sensible amount of time. As Shannon proved, this regular announcement of a script update is barely distinguishable from noise because we can all predict its content. As I have often maintained (with no effectual argument to the contrary) we need an FAQ for stuff like this where this guy has the ability to change the FAQ to point at his latest version. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM \(R\) writes: > Oh my god, that is what I was looking for! There is a lesson to be learned. Next time, tell us where your immediate problem stands in the overall scheme of things. Something like "I'm trying to add a user from perl by inserting them into the MySQL database but cannot figure out how to crypt the password" would have allowed us to skip straight to the real problem. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Nick Harring writes: > This isn't actually true. Mysql provides an encrypt() function, which > takes two strings, the password and the salt. You learn something every day. I'd not enountered that function before. > On linux, and I would guess *BSD as well, when you supply $1$ as the > start of the salt then an md5 crypt, same as in /etc/shadow, is > performed. The problem then is providing good salt. Since MySQL's rand() appears to call the system rand(), this is not good salt. Quite probably good enough for many purposes, but not good enough if you want serious security (and you wouldn't be using the MD5 crypt unless you did). OTOH, I bet vpopmail also uses rand(). Ummm, some quick digging later and the situation is worse than I thought. Not only does vpopmail use rand(), it initializes srand with a variant of time(NULL) ^ getpid(). time(NULL) ^ getpid() has long been known to not be a good way of seeding the random number generator. I think the variant vpopmail uses is actually likely to make it quite a bit worse. If nothing else, I'd suggest replacing the rand() % time(NULL) ^ getpid() with time(NULL) ^ (getpid() + (getpid() << 15)) as recommended by Larry Wall. At best, I would attempt to determine if /dev/urandom exists (either at configuration time or at run time) and use that if possible, reverting to the Wall function if /dev/urandom is not available. > Wrong, and sometimes also wrong. There may be very legitimate reasons, > technical or political, for not allowing scripts to execute shell > commands on a mail system. There may be technical or political reasons, but he did not say that there were. And, in fact, it turns out that there were not. > There may be integration reasons why only DB queries can be performed, > instead of invoking a cgi or doing an ssh and executing a script. There may be, but in this case there were not. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM \(R\) writes: > Paul: The reason why I do NOT want vadduser or any commandline tool is > that I want to write a perl script which automatize user generation. > > Cool would would be If one could run: > vadduser $variable_password > or something like this in > Perl or PHP code! vadduser has always allowed the plaintext password to be specified on the command line as: vadduser email_address password Newer versions can generate a random password with: vadduser -r email_address Both forms can be run from perl using backticks. The random password from the second form can be collected from the backticks in perl. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
John Johnson writes: > He can also enable the learn password option in vpopmail, I think > this would be an easy way to deal with it myself. It's hard to tell since he didn't say why he wanted to do it in the first place. The problems with the learn password option are that there is a window of vulnerability (unlikely to be exploited) and that he may not wish users to choose their own passwords. He may wish to force strong passwords on his users, in which case learn password would be totally unsuitable. As somebody else reminded us, this guy has asked questions avout the password hashing before and received rather comprehensive answers which he apparently either ignored or could not understand. So I have my doubts that any sensible, rational, logical solution will suit him. He appears to be like the guy who locked his keys in his car and spent an hour using a bent coat-hanger inserted down the window seal to jimmy the lock so he could let his family out of the car... -- Paul Allen Softflare Support
[vchkpw] Re: "global" or sitewide alias/forward
Hans Rakers writes: > Quick question: Using qmail/vpopmail, how can i make mail for things > like [EMAIL PROTECTED] or [EMAIL PROTECTED] go to > one single maildir/account/alias for all my virtual doms, without having > to create .qmail-abuse and .qmail-hostmaster files for all my virtual > doms? With a new enough release of vpopmail, vadddomain takes a -e switch to specify the catch-all address for the domain. Because this gets the mail for any username which does not exist at that domain, it will automatically get abuse and hostmaster mail. This may or may not be good enough for your purposes. Unfortunately, there appears to be no command-line tool for modifying existing domains in this way. If you want to modify existing domains or do not wish to use the catch-all mechanism then you will have to do this manually. However, once having done this on one domain you can then automate it by creating a script of some sort that goes through each domain, creates the destination maildir with vadduser, copies the .qmail-abuse and .qmail-hostmaster files and sets their ownership/permissions. For new domains you can create a script that runs vadddomain then creates the target mailbox and copies the .qmail files. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM \(R\) writes: > I want to create new users like [EMAIL PROTECTED] NOT with vadduser > BUT with just inserting it via mysql-insert into the vpopmail > database. OK, you have now explained what you want to use instead. Somebody else pointed out that the maildir will be created automatically by vdelivermail if the user exists (I hadn't realized it did that until I read that message and looked at the code just now) so you can get away with doing that. What you have yet to explain is any valid or sensible reason WHY you want to do this. > Any hints, > how I can generate the encrypted password in the column pw_passwd > (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Not without breaking out of MySQL and returning to the shell. The hard way is to get a shell prompt, use passwd to set the password of a dummy system user then copy the crypted password into the MySQL command. The harder way is to write a perl script that generates some good random salt, calls crypt to crypt the password then uses the DBD modules to insert the user into MySQL. An easy way to do it is to add the user with MySQL giving garbage for the crypted password then use vmoduser to set a valid crypted password. The very easy way to do it is to run vadduser. You CANNOT do it all from MySQL. You CAN do it all with vadduser. What is more, I can see no reason why you would want to add a user but NOT have the maildir created at the same time, which is all you could achieve if you could do it all from MySQL If you have some automation tool that can only cope with adding MySQL rows then you'll still have to modify it to shell out to generate the crypted password, so you might as well modify it to shell out and run vadduser anyway. If you want domain admins to be able to add users this way because they cannot run vadduser you'll still have to write code that validates they can only modify their own domains, so you'd be far better off installing something like qmailadmin on your server. -- Paul Allen Softflare Support
[vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Oliver Etzel - GoodnGo.COM \(R\) writes: > I want to create new users like [EMAIL PROTECTED] NOT with vadduser Why would you not want to use vadduser? > BUT with just . With just what? > Any hints, > how I can generate the encrypted password in the column pw_passwd > (looks like this $1$S/TPu$GjMMj7yMJqG.0ckx) ??? Yes, I could tell you how to do that. But creating an entry in MySQL and crypting the password is only part of the process that vadduser (or any of the web admin interfaces like qmailadmin which use the vpopmail libraries) do. It really is easier to use vadduser or link to the appropriate routines in the vpopmail libraries (or use one of the webadmin tools). It is also safer, because if vpopmail changes in the future, vadduser will do whatever is necessary to accommodate that change whereas your method (whatever it is) may not. -- Paul Allen Softflare Support
[vchkpw] Re: password generation - vpopmail table - pw_passwd
Justin Heesemann writes: > i don't now if you are using php or anything like that, but most > languages support some kind of crypt() call. It is debatable what level of entropy is required for the salt when generating a password for vpopmail use. If you want maximum security, and already require the use of only the SSL forms of POP, IMAP and webmail access, and are completely paranoid that some rogue system user might just somehow find a loophole that allows access to the MySQL database, then you probably want high-entropy salt. But don't forget to switch off the "plain text password" feature. If you have the "plain text password" feature enabled, then you probably don't run a server belonging to the US military, the CIA or the NSA. You probably trust all your system users sufficiently and/or you are not too worried about passwords being stolen because you know your users will choose incredibly stupid passwords that crack can find in a couple of minutes. Basically, if you have plain text passwords enabled the entropy of the salt is irrelevant and you might as well use the same DES-style salt for each password. Nevertheless, there is a simple way of generating crypted passwords which just happens to have reasonably high-entropy salt (assuming the people who wrote certain portions of your flavour of Unix were competent) which is appropriate in either situation. Create a system user without shell access. Use passwd to set that user's password. Copy the crypted password in /etc/shadow into your MySQL table. It's relatively painless to do and guarantees good entropy on the salt if you happen to need it. You could even automate it with a little perl if you're feeling lazy. Which reminds me. I haven't got around to playing with the newer vpopmails with password generation (the release I'm using does everything I must have while later releases have bugs in areas that affect the must-have stuff). Does it use /dev/random or /dev/urandom if available? Does it use a sensible method of reducing the 0-255 range that /dev/random or /dev/urandom or rand() (spit) return into the salt range or does it do something silly that biases the results? If Knuth's descriptions of his algorithms for mapping random bytes to a reduced range leave you with brain-ache (they do me) then simply discarding any byte outside the range and getting another one is a reasonable approach with /dev/random and /dev/urandom. -- Paul Allen Softflare Support
[vchkpw] Re: Migrating qmail/vpopmail to another server
John McGivern writes: > Could anyone point me to a document that would outline how to migrate > all of the accounts and virtual domains from one server to another? > I already have the server all set up with the same stuff, I just need > to get the domains and accounts over. Rsync is your friend. Use it to copy over the entire domains directory. Use it to copy over the entire qmail control and users directories. That should cover most things, although you may have to do some tweaking to the assign file if you have system users that aren't in virtual domains. -- Paul Allen Softflare Support
[vchkpw] Re: Learn passwords with Courier IMAP
Michael Bowe writes: > To auth a username/password, Courier-IMAP takes the supplied username > and runs vpopmail's vauth_getpw() to retrieve the user's passwd entry. > > Courier-IMAP then crypts the supplied password and compares this against > the (crypted) pw entry supplied by vauth_getpw() Sigh. That means vpopmail might support forms of crypt that sqwebmail has never heard of. > Password learning is all done in the vpopmail's vchkpw() function, > which Courier-IMAP doesnt use Nor does there seem any way of kludging it without Mr Sam's co-operation. You could make vauth_getpw a wrapper around vchkpw which returns the crypted password but since he does not supply the plain password it still wouldn't work. Ah-ha! But what does qmailadmin call? It allows ordinary users to login to set certain preferences. So if qmailadmin calls the right thing then you're laughing. Unless you don't want users to have qmailadmin functions available to them. -- Paul Allen Softflare Support
[vchkpw] Re: clearopensmtp fatal
J. Kendzorra writes: > Not really your fault - ./configure --help shows: > --enable-tcpserver-file=~vpopmail/etc/tcp.smtp File where tcpserver -x > relay information is stored. I remember being bitten by this one, long ago. > I already sent mail to someone some time before (don't remember anything > anymore ;), that this should be changed. Maybe a bugreport would work > better? I don't know which reporting mechanism would work better, but I would prefer a configure script that would happily accept ~vpopmail. I do not think that vpopmail ought to look up ~vpopmail at run-time because of the overhead but I think it is reasonable for the configure script to be a little smarter. Although, having said that, I can see problems with making the configure script smarter. I can see people posting here saying that they moved the vpopmail home directory and changed /etc/password and things broke even though they used ~vpopmail in the configure rather than a full path. On balance, fixing the help is probably the best that can be done. -- Paul Allen Softflare Support
[vchkpw] Re: Learn passwords with Courier IMAP
Michael Bowe writes: > As far as I know, Courier-IMAP uses it's own functions to auth the > password, Yes and no. Courier-IMAP and the Courier POP3 server do have their own authentication routines which are effectively wrappers calling whatever authentication method you actually use. So if you tell Courier to use vchkpw authentication than it does end up using the vpopmail stuff. > therefore the vpopmail's learn password functionality will not be > available I haven't examined the vpopmail authentication code in detail, but I would guess that it gets handed a username and password, if it is not in learning mode then it does a standard validation, if it is in learning mode then it sets the password and returns that the login was valid. If it does work that way then it should be transparent to Courier. -- Paul Allen Softflare Support
[vchkpw] Re: HTML Autorespond
Eduardo P. Román O. writes: > Hi, i need to do an autorespond but in HTML, qmailadmin now can do > autorespond with text mail only (i think). Be warned, this is an autoresponder designed to respond to ANYTHING (well, it has some checks against responding to mailing lists and the like). It is there purely to provide an "We have received your query and one of our team of highly-trained monkeys will deal with it shortly." For that purpose it is reasonably adequate. Do NOT use it for vacation messages. If it encounters somebody else also using some other braindead vacation responder then it will rapidly generate zillions of mails. The autoresponder that comes with maildrop is a lot more flexible and can be told not to repeat the response to the seme sender within a specified period of time, so it can be used for vacation messages as well as ordinary autoresponders. When used with maildrop itself, you can then set conditions on if it should respond or not, useful when you have something like sales@ being aliased to user1@, user2@, etc. So you'd have a filter that did not invoke the responder if the mail was sent to sales@ but would invoke the responder if the mail was sent directly to [EMAIL PROTECTED] > I want use this tools but to do autorespond in html format. You would have to modify it to insert the appropriate MIME header and then format the content accordingly. Look at the MIME RFCs for further details. You would probably also want to add a switch to turn the MIME header on and off so it can also be used for plain text messages. You would probably also want to pass the HTML through lynx with appropriate options to generate alternative plain text for those whose mailers cannot handle HTML. And then you need to buy some protective clothing for when all those who HATE mail with HTML in it go after you with cluebats... -- Paul Allen Softflare Support
[vchkpw] Re: "Domain already exists" but doesn't really
W.D. McKinney writes: [...] > Error: Domain does not exist [...] > Error: Domain already exists Vpopmail does not gracefully deal with inconsistencies in various files and directory structures. In my opinion, vdeldomain should remove all traces of a domain before complaining of any inconsistencies. I.e., it should do what I have to do manually if there is an inconsistency rather than griping about an inconsistency and bombing out. I think vadddomain ought to be smarter too, and fix an incompletely-added domain, but I can live with it being stupid if vdeldomain can be used to wipe out all traces of a domain despite inconsistencies. Go to the vpopmail domains directory and delete the domain directory (if this is an alias domain then old versions of vpopmail will have created a soft link for it while newer versions will have created nothing for it). Go to the qmail control directory and remove the domain from rctphosts or morercpthosts (if it was in morercpthosts then run qmail-newmrh after removing it) and remove it from virtualhosts. Go to the qmail users directory and remove it from assign then run qmail-newu. Then, and only then, complain about any inconsistencies you found. -- Paul Allen Softflare Support
[vchkpw] Re: command to set catch-alls
Jeff Koch writes: > Is there any way to use the commands in /home/vpopmail/bin to setup domain > catch-all accounts? When I was stuck with this problem quite a while ago I just wrote a bit of perl to do the job for me. As others suggested in another thread, it was smart enough to ask for domain, postmaster password and then repeteadly prompt me for alias domains until it got a blank line as input, then it called vadddomain (and vaddaliasdomain if necessary) and wrote a new .qmail-default file to set the catchall to deliver to the postmaster's maildir. In newer releases of vpopmail, vadddomain has a -e e-mail_adress option. If there is an @ in the address you specify then it sets the catchall to forward to that address; if there is no @ then it sets the catchall to deliver to a Maildir of that name in that domain. However, beware that using -e to set the catchall to a maildir does NOT create that maildir (unless you set it to postmaster, because it creates the postmaster maildir anyway). I think it would be a good idea if it did create the maildir (if not set to postmaster) as well as creating the postmaster maildir. -- Paul Allen Softflare Support
Re: AW: AW: WG: [vchkpw] lock account after login failures
Feucht, Florian writes: > > Perhaps he did, but "locked out CONNECTIONS from that IP for 10 > > minutes" reads differently to me. If Tom had meant what you said, then > > I would have expected something like "locked out authentication attempts > > from that username/IP pair for 10 minutes." > > This idea is great, but doesn't work for me, because all traffic passes > a proxy firewall (including a esmtp daemon) - so the firewall is the one > and only entity which makes a connection to the mailserver... We have many clients behind firewalls. They too would suffer from a simple block on an IP address. > about the DoS attack: sure, it's possible to knock somebody out of his > mailbox... but i think this is better than if somebody takes it over... I think it's a close call. The difference between somebody deleting your mail before you can read it and somebody blocking your access day after day is small. Yes, if they can delete your mail they can also read it, which may be a bigger problem, but being unable to read your mail is bad enough. As I said before, there are ways to greatly reduce the chances of somebody getting at your mail. Give your mailbox a randomly-generated name and use an alias to deliver to it. Then it doesn't matter how weak your password is because they'll be trying [EMAIL PROTECTED] instead of [EMAIL PROTECTED] This is something that you can do right now, although it is a pain to administer. Maybe vpopmail and qmailadmin should be extended so that there is an option to create random mailbox names with aliases (to avoid name collisions the random mailbox names would have to have to start with an underscore or something like that). > if it happens that somebody starts DDoS this way, i can do the > following: > - look at my firewall log > - find out his (or her's ;) ) IP Address > - block the IP(-Pool) > - contact the ISP, if it doesn't stop. That was a workable solution three or four years ago. These days the script kiddies use distributed DoS attacks using hundreds of computers thay've managed to install backdoors on. You could spend every minute of your life blocking IP addresses and still not be able to pick up your mail. A tarpit is a two-edge sword... -- Paul Allen Softflare Support
[vchkpw] Re: Migrating to a new machine question?
Jesus Ruiz writes: > The problem is that my clients don't want to lose the email they save in > the old server. When we change they account to the new server. > > Any suggestion? Copy the existing mail over. Rsync is your friend... -- Paul Allen Softflare Support
Re: AW: WG: [vchkpw] lock account after login failures
X-Istence writes: > Paul L. Allen wrote: > > >Tom Collins writes: > > > > > > > >>What if the system tracked it by IP, and after three failures locked > >>out connections from that IP for 10 minutes? [...] > He meant log it on an account AND ip basis. Perhaps he did, but "locked out CONNECTIONS from that IP for 10 minutes" reads differently to me. If Tom had meant what you said, then I would have expected something like "locked out authentication attempts from that username/IP pair for 10 minutes." -- Paul Allen Softflare Support
Re: AW: WG: [vchkpw] lock account after login failures
Tom Collins writes: > What if the system tracked it by IP, and after three failures locked > out connections from that IP for 10 minutes? That has problems for companies behind a firewall which use external mail servers (we have several clients in that situation). All it takes is one person to type his password wrong and they're all locked out for ten minutes. Worse, he types it into his mail client configuration and polls every five minutes. The result is that they get onto us and complain that our mail servers are broken. Then we waste 15 minutes convincing them that they have to disable all their mail clients for ten minutes then turn them back on one at a time until they find the one with the bad password. -- Paul Allen Softflare Support
Re: AW: WG: [vchkpw] lock account after login failures
Feucht, Florian writes: > My idea is to store this information per user, so the others keep > unaffected from locked mailboxes. > > Another Possibility is to lock the account only for an specific amount > of time (lets say 10 minutes) after 3 password fails. So if somebody > tries some hardcore brute force, the database grows only for a small > period of time. You are still not considering the possibility that somebody mounts a denial of service attack. An attacker need only make three attempts every ten minutes to permanently lock somebody out. And the attacker can do that for every mailbox they know of on your system. How would you like it if I set up a cron job to run every ten minutes to block [EMAIL PROTECTED] I think you'd find it a little inconvenient. There are ways around the problem, as I suggested in another thread on security issues. Give your mailboxes random names like fekgopwa and use an alias to take mail for f.feucht and drop it into fekgopwa. Then people attempting to lock out the f.feucht mailbox would fail because the mailbox is actually fekgopwa. Pf course, you're still at the mercy of packet sniffers finding out not only the real mailbox name but also the password unless you use spop. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
Hello Red Herring Nick Harring writes: > This whole argument is ridiculous. Correct. So far I havw seen only one person post a sensible response, You are NOT that person... > The correctness of design doesn't really rely on what some random users > first guess of how it should work would be, You have NO understanding of ergonomics. A correct design anticipates what random users would first guess. This is NOTHING to do with what happens at a technical level and everything to do with the user interface. If software does not work how MOST people expect it to then it is BAD software. > because they're wrong to be guessing when man pages are > supplied. Sigh. So many people of LIMITED INTELLIGENCE have missed the point. It's not what the man pages say, it's not how it works, it's not how some masochistic geek who codes it thinks it ought to work, it's how the USERS want it to work. I don't give a crap how you, as a geek, think it ought to work. As a USER (I also happen to be a geek, but one who understands ergonomics) I know how I would like it to work. Is that so hard for you to comprehend? Obviously it is. And hey, the change I suggested meant that BOTH OF US could be happy. The jean-creeaming changes that Tom suggested means that not only can BOTH OF US be happy but that it is automatic. It works how you want and it works how I want. But you don't want me to be happy... Why is it that so many people resent a change that Tom can do in his sleep and which has no adverse affects on anyone?Give me a RATIONAL, LOGICAL argument and I will agree with you. Come up with crap like that and I will flame you to hell and back. > The One Correct Way of using new software in unix is to read > the docs first. Bollocks. If you want Unix to remain a minority platform then that's the way to go. If you want Unix to displace Windoze then you make it easy for idiots to configure and use. > However, I must agree with many others that silently doing the right > thing without changing the docs is a bad, bad idea. Gimme a clue here... Is doing the right thing a bad idea??? Is having relatively undocumented features that the intelligentsia can use a bad thing? Is a software utility, that no matter which order you specify its two mandatory arguments still does the right thing a bad idea? > I happen to not care about the order of the arguments, however I do very > much care that the documentation stay accurate for any future versions > of vpopmail. Please explain to us all how the documentation failing to mention that you can specify "real alias" as well as "alias real" will cause you, or anyone else, a problem. Give it your best shot... -- Paul Allen Softflare Support
[vchkpw] Re: autorespond on SourceForge
Tom Collins writes: > We essentially need a way to tell autorespond that it's acting as a > vacation responder, or an auto responder. >From the last time I looked at it, autorespond just doesn't have the smarts necessary. It is designed to respoond to any incoming mail, no matter what. And for an autorespondr replying that "All our highly-treined monkeys are eating peanuts right now but they'll get back to you when they've finished flinging their excrement at idiots like you" then that is fine. For an autoresponder you need a lo more smarts. It has to ignore any sign of mailing lists, It has to not respond to the same address twice in a given period of time. The mailbot which comes with maildrop has the necessary features. And it it is accessible by sqebmsil'x filters. Which is why I urge you to play with the latest sqwebmail. I have issues with Mr Sam whther or not you do, but the maildrop vacation stuff works and I'd hate tp see yet another alternative in qmailadmin. Again I offer you the chance to see what sqebmail does before implementing something different in qmaildadmin... -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
Erik Bourget writes: > You know, intense as this whole argument is, the fact remains that DWIM > is no substitute for proper documentation. Let's see, the documentation says vaddaliasdomain original alias. If you do what the documentation says, it works. If you reverse the arguments, it still works. It would be nice to document that the arguments can be either way around but it is not strictly necessary. > Patching software to accept every possible 'first-guess' input isn't > just sloppy, it's unmaintainable. But the point is that most people's first guess is the opposite way around, therefore the software was badly designed. And, as somebody else already pointed out, no matter which way you expect it to work, it works exactly as before: if both domains exist it was an error before and is an error now. If neither domain exists it was and error before and is an error now. If one domain exists and the other does not then an alias is created. It is impossible to do anything wrong with the proposed change in place tha you cannot do wrong with the existing code. In fact, the proposed change eliminates one possible error: that is misremembering what order the arguments should be in because you use ln a lot. That's not sloppy, that's good ergonomics. >From all the complaints, anyone would get the impression that the change forces everyone to do things differently. It does not and you can continue to use it the way you always have. From all the complaints, anyone would think that the change introduces a new error that you can make. It does not and it is impossible to do anything wrong that you could not do before. From all the complaints, anyone would get the impression that making software easier to use while retaining full backward compatibility is a bad thing. "Waah. Big bad man force me to use new software that can be used in ways I disapprove of. Waaah" "Is he also holding a gun at your head to force you to use it that way?" "No, but I disapprove in principle of software being easy to use and get all twisted and angry inside that somebody else is using it the easy way while I'm doing it the hard way to show my machismo." If the preceding paragraph is not your position then please give some THOUGHT as to why you believe it is such an awful change. If you have anything more plausible than it will add a couple of lines of code and will divert a few person-minutes of programming resources then feel free to share them. Here's a tip for you: if you state a broad general principle without justifying it and showing that it is actually applicable to this situation, I'll show exectaly why you're wrong as I just did with your "DWIM is no substitute for proper documentation." -- Paul Allen Softflare Support
Re: WG: [vchkpw] lock account after login failures
Feucht, Florian writes: > is this problem unsolvable, or did i say something wrong? Doing it the way you suggest, counting failures, means remembering state somewhere, somehow. If you have a lot of idiot users, this state could become very large and slow. Also there are two possible denial of service attacks: the first is somebody deliberately giving a bad password several times to lock some user out; the second is somebody deliberately giving a bad password for every user on your system in order to make the state cdb large and slow. A simpler, but less effective, mechanism is for vchkpw to sleep for several seconds before it returns an "invalid password" response. Again, there is a denial of service attack which can be used if somebody has a big enough computer or a distributed attack network: keep giving bad passwords for all users so there are lots of processes sleeping and your machine spends all its time swapping them in and out. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
Hi Anders Anders Brander writes: > Hummm Or something like: > "... the two domains to be aliased ..." - without saying which is which, > for the user it doesn't matter much. Oh Anders, I need rigidly defined areas of doubt and uncertainty! It's because I'm a boring old fart that I desperately need to be sure that I'm doing the right thing when I use something new. I need to know that I'm creating an alias domain for an existing domain and not aliasing an existing domain into the bit bucket. > A usage like: > "vaddaliasdomain [options] domain-a.tld domain-b.tld" - nothing to be > confused about. But a lot to be scared about unless you KNOW that vaddaliasdomain will do the right thing [tm] automatically. I think that the usage has to make it explicit that whichever way around you put in the arguments, it will do the right thing. Look how much effort Larry has to put into explaining that perl does what you expect (unless you expect something different). My take on it is that it's far too easy for developers to slip into the belief that everyone has read and understands the source, or that everyone has read all the pertinent mailing lists. It is also my belief that such an approach is WRONG. My belief is that software should not, in the majority of cases, require you to refer to the mailing list. My belief is that, in the majority of cases, software should not require you to read the documentation - it should do what you want it to. Because vpopmail bridges so many divides, it cannot intuit what you want. It doesn't know if you're using cdb for everything or using MySQL for everything or whatever unless you tell it. But, wherever possible, it should be DWIM. Tom's proposed patch allowing real and alias domain in any order is very much DWIM that pleases both sides of te argument. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
X-Istence writes: > > This is my patch, it doesnt allow for both types, but does what you want > :). It does do what I want, and if that were my only concern I have other solutions that I could use. I would like both options to be available so that those who have one preference can get exactly what they want. Tom seems to have come up with a better idea than mine, and if somebody is willing to code it then that is my preference. But I give you my thanks for understanding why I requested this feature and coming up with a partial solution. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
Hi Anders Anders Brander writes: > I think we should just ignore the "old" way of calling vaddaliasdomain > in the usage message, in that way new users will adobt the "new" way of > doing things. Ummm, that implies that one way is more "correct" than the other. I do not believe that to be the case. I believe that one way is more natural to some of us than the other and that each of us should be able to use the interface we prefer. > The autosensing will ensure that we don't brake old script Yeah, old scripts will still work. But old sysadmins like me will get confused (I'm old, it's nearly 3am and I've had a lot of wine so I'm easily confused). We do something and it works and then later we look at the usage message and find that it COULD NOT HAVE WORKED. That causes to go diving into the code to see what the hell is happening... The usage message MUST explain both alternatives. It will be a little clumsy, to be sure, but it must explain both alternatives. > I will NOT participate in that discussion. Bah, it's fun. You just need more wine... :) -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
Anders Brander writes: > A bit odd to document, Damn right. I still haven't figured out a sensible usage message. > but otherwise a fabulous idea. Bad Anders. Bad, bad, Anders. Letting people do what they find easiest is BAD. Ask the people who criticised me for suggesting it. > Please see SF Patch 812150 - It does exactly what you proposed here. That is not allowed! The people who criticised me for suggesting sdmething like this went ballistic because I did not provide a patch. Imagine how much more they will be upset because you did provide a patch. BTW, you're not part of "the community" because I was told that if my suggestion had any merit then "the community" would already have provided a patch. Yeah, that makes no sense to me either, but you provided a patch that some people hate therefore you are an evil person and eat babies on toast for breakfast. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
Toasterz Admin writes: > Paul L. Allen wrote: > > >Toasterz Admin writes: > >Actually, you're wrong. > > > how could i be wrong just because you say it's so. What a wonderfully compelling argument. How could you possibly be wrong just because I say so? Ummm, wait, you called me wrong because YOU said so. Only you did not provide compelling arguments after your accusation and I did. > your posts are irrefutable... Damn right. You CANNOT refute them so you resort to smoke and mirrors. Hint: if you want to accuse me of something, read a dictionary first. > why even try? I will NEVER deny anything I have posted. In fact I revel in it. > you don't have to convice anybody. do it yourself. if it's useful the > community will adopt. Ah, you have no concept of the costs of "code forking." One must alway try one's best to convince the project lead to adopt one's suggestions rather than cause a code fork. As it happens, the project lead posted with an improvement on my suggestion, so a code fork looks unlikely. Some of us accept the code lead's judgement in these matters... > since you like to talk about proprietary software vs. open source, i'll > let you know what really makes software of any kind successful... > developers. Wow, you're right. I have one billion (count them) developers for "Fuck You, You Bastards - Lite." Once you install it, it causes your computer to electrocute you then destroy itself. Ordinarily, it would bomb, but because we have more developers than any other piece of software it is a guarnateed success. You're right, it's the developers that count. > at root, microsoft became what it is for one simple reason, people > wrote software for it. You are so gullible I have e bridge to sell you. Actually, several bridges. > ms courted developers early and often. MS FUCKED developers of competing products early and often. Hang on a moment, this is a *nix list so you must be a troll. > you really ought to apoligize to the list for your bad behavior. U, pot, kettle, you hypocritical lying bastard... > since you're nasty. s/nasty/truthful and kelly hates it/gi -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
JB writes: > A one line bash script, which I provided Sorrry, I did not see your attachment in any of your posts. Please repost it so that we all can benefit and the vpopmail maintainers can distribute your wonderful script (if they think it is a sensible solution). > will do the job for Millions of people. Or whatever number need it, whether it's 0.1% of us or 99.9% of us. My attitude to software is to try to deal with the needs of everyone, not just the needs of the majority and definitely not just the needs that Microsoft claims falsely that everyone has. > You could have fixed the problem yourself in less then 10 seconds, I can fix the problem for MYSELF in less than 10 seconds. To fix the problem for others requires submitting a script (ummm, I still don't remember seeing yours) and persuading the vpopmail developers to include it in the distribution and add documentation. Do you understand how to multiply ten seconds by the number of people who have to expend those ten seconds? Do you understand the virtues of consistency in user interfaces? BTW, the overhead for the vpopmail devlopers is pretty much the same whether it is the inclusion of a script or modification of vaddaliasdomain. Apart from having to wade through people flaming me for suggesting a possible improvement to the user interface, that is. You, and a few others like you, have made a simple change, requiring little effort, that would please many people, into something that will eat into what little time the vpopmail developers have. Be proud of yourself, JB. > instead, you flame me. Yep. Because you showed a significant clue deficiency, and still do. > You are a fucking twit Opinions will differ on that one. Obviously I have one vote on my side and I presume that you have one vote on your side (although you are so clueless I cannot be certain that you agree with yourself). Where the rest of the votes lie is another matter... As I invited another idiot to do, please explain to us all why it is so important to you to prevent the suggestions I made being incorporated. I took care to ensure that those who were happy with the current behaviour would get it by default, yet those who were unhappy could get what I think to be more sensible behaviour. Tom Collins came up with an improvement on my idea that would let all of us get the behaviour we wanted AUTOMATICALLY. Now please explain to us all why you are so much against all of us getting what we would like provided that you get what you like and those who disagree with you can go screw ourselves. Y'know, my understanding of Open Source is that it advances by people suggesting ideas (and, if they are capable, providing patches). We all get what we want, although there may be some extra configuration issues. I thought that the definition of Closed Source was "you take what we give you and you damn well better not complain." It seems to me that you want Closed Source vpopmail because you have advanced no better argument than "because I say so." Feel free to debate me on substantive issues (if you can). By all means offer technical refutations of my arguments (if you can). However, if all you can say is "Wah, I don't want that though I can't explain why" then FOAD. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
[EMAIL PROTECTED] writes: > Gotta give this Paul guy a round of applause. Indeed. I know you meant that ironically, but I understand your misperceptions. > I have never seen anyone who uses his sheer incompetency as a brutal > attack weapon. Have you ? Many, many times when I have dealt with the idiots who get loose from alt.flame. Look in a mirror for an example. > if it is soo important to you It is rather trivial to me personally because I can work around it. And if I thought that I were the ONLY person who thought this a good idea I WOULD work around it. However, in the spirit of Open Source I contribute ideas that I think might help a significant number of others. It's called "improving the product." > and it seems from what you're saying that it is also soo important to > everyone else Please show me where I wrote "everyone else" or even implied it. I suggested that a significant number of others might find it useful. I thought that was the Open Source way - you design something that is capable of satisfying ALL users, not the small number that are satisfied with how Microsoft decree the software will behave. Tell us all, just what do you personally have to lose if I and others get a feature that would make us happy even though you would be unhappy if FORCED to use that feature, if the feature is optional? Come on, what makes you so insistent that I should not have something that I consider useful if I do not force it upon you? Why is it that giving me something I would like, at no expense to you, is so personally hateful to you? > we That is the Royal "we" is it? For your information, Tom Collins posted a suggestion which would make the behaviour automatic no matter which way around you wanted the arguments. With his suggestion, you and I could be equally happy - if all we wanted was to make our lives easier and not to make the lives of those who disagree with us harder. It is my understanding that if Tom thought my suggestion as bad as you do then he would not have offered an improvement. YMMV. > would love for you to submit a patch at once so we can all benefit. I am not fluent in C. I am fluent in perl and could contribute a script instantly. However, I do not believe that a script is the correct answer. Either my suggestion is idiotic (as you imply) and no script is needed or it is a sensible suggestion and is better handled within vaddaliasdomain. > This way, only a bit of your precious time is wasted and not THOUSANDS of > man hours Hmm, I suggested that there might be thousands of people who would like the same behaviour. I would guess that, on average, it would take them five minutes to knock up a suitable script (a lot less for me, a lot more for those unfamiliar with scripting languages). That is a LOT less than thousands of man-hours. Please tell us where I claimed that thousands of man-hours would be required or give us justification for you inferring that from what I actually wrote. Or admit that you are putting words in my mouth. BTW, please let us all know when you understand enough about mailing lists NOT to quote the entirety of the mail to which you respond. Some of us would take that as an indication that you have finally heard the ringing of the cluephone, even if you have yet to figure out what the ringing means or how to deal with it. -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
You don't read so good, do you? JB writes: > Write a shell script that takes the arguments in the order you want and > pass them to vaddaliasdomain in the order expected, I already explained that while I am more than capable of coming up with that idea and implementing it all by myself, that such a solution does not help the many others who have this same problem. Now you may think it sensible that hundreds or thousands of people each spend time writing a script that overcomes an OBVIOUS DEFECT in a piece of software but I do not. I think it more sensible to fix the defect at source, thereby minimizing the total amount of person-hours wasted. But since you did not bother to read (or could not comprehend) my previous message where I stated that, no doubt this too will pass several miles over your head. GOOD software design requires creating a user interface that is optimized for the common case. The common case is people who already know about the order in which ln expects its arguments and who have to add several alias domains at once. I'm picking up some vibes here... Apparently, you do not understand that either. "Me used to having to do a lot of extra key-presses. Me no want change. Change bad. Me hated vpopmail being ported from abacus to computer." -- Paul Allen Softflare Support
[vchkpw] Re: Feature request for vaddaliasdomain
[EMAIL PROTECTED] writes: > If you do this often enough, why not just write a simple little shell > script to accomplish this: I'm way ahead of you. It asks for the main domain, the postmaster password and prompts for alias domains (finishing if nothing is entered for an alias. Then it sets things up and adds a blackhole (we have several clients who get nothing but spam to some old mailboxes). But then a client comes along and wants to add another couple of domains as aliases. Yeah, I could knock something up for that, but I generally avoid that except when our needs are divergent from everyone else's. If I knock up a script, there will be others in the same situation who also have to knock up a similar script to do the same thing. Where something would be useful to many, it is better to have it as an optional part of the distribution. > Say you have 100 domains you need to alias to 1. The worst one of our clients has managed so far is 13, added in dribs and drabs of two or three at a time. For one it makes no difference. For hundreds I'd go the perl script reading a text file route. For twos and threes the current argument order of vaddaliasdomain is annoying. -- Paul Allen Softflare Support
[vchkpw] Feature request for vaddaliasdomain
A feature request for vaddaliasdomin. I would like a configure option (best) or a command-line switch (not so good) that reverses the order of the two arguments. I'd like it for two reasons: 1) It is then the same order as for ln (original, alias) so easier to remember if they're that way around. 2) We get clients who register lots of domain names and want them aliased. After the first vaddaliasdomain I can up-arrow to recall the command but then I have to left-arrow over the original domain (a pain if the network in between me and the server is bursty because it's easy to overshoot) so I can modify the alias domain. Reversing the order of these two would greatly cut down the number of times I have to left-arrow. Obviously it would have to default to the old behaviour, but those of us who knew of it could take advantage of it. -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail and local users - user_over_quota message
David McMahon writes: > What's the best way to set up a combo local and vpopmail > system? One way is to make it entirely virtual. The downside is that your local users have to configure their mail clients to use [EMAIL PROTECTED] instead of just username. The upside is that it's consistent; it's easy; it allows local users to have a different mail password from their system password (if you only let users log in remotely using SSH but they don't all use spop or simap then this is important). -- Paul Allen Softflare Support
[vchkpw] Re: synchronize control files
Tim Hasson writes: > I am developing a web based interface on it using php/mysql [...] > My worst fear is of a exploit like the recent SSL v2 vulnerability > where an unautheticated user, or an anonymous user, could just simply > exploit the apache process, and use it as a step stone. You're worried about an obscure SSL vulnerability when you're using PHP? Unless you're planning on a dedicated mail server with no user accounts having webspace, your setup will be wide open. Without an add-giving the eqvuivalent behaviour of suexec, you need to make any directories and files that you need to modify readable and writeable by the httpd user. So anybody with web space on the server can write some PHP to read and/or trash other people's mail. Being worried about obscure attacks when you're using PHP is like worrying about somebody 100 yards away striking a match when your clothes are on fire. -- Paul Allen Softflare Support
[vchkpw] Re: question about autoresponder change
Jeremy Kitchen writes: > However, qmailadmin also uses this for its 'vacation replies' Yes, the newer versions do. When I move it to our production servers the HTML will be hacked to ensure that our users cannot misuse the autoresponder in this way. > So, there's the dilemma, it appears that one package is trying to have > two different purposes in life, and those two purposes conflict with > each other. Sqwebmail has a better vacation response system and that's what our users will be using. -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail 5.3.27
Charles Sprickman writes: > They probably would have gotten an answer had they shown the perms on > their ~vpopmail/bin directory and their ~vpopmail/domains/*/* directories. Giving information like that always helps. :) > I think "polite" in this case referred to the "I installed it correctly, > so there must be a bug" attitude. :) There are three ways of looking at that. Somebody can be so bone-headed that he or she is convinced that everything was done correctly and refuses to consider the possibility that an error was made. This, i believe, is what you meant by it. The second way of looking at it is that if somebody follows the installation process and documentation to the letter and it still doesn't work then there really must be a bug. I did a correct install of one of the newer betas and found that I couldn't add domains or users. The third way of looking at it is that if it is possible to install it incorrectly then there is indeed a bug in the installation process or the documentation. -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail 5.3.27
Hi Derek [Replied to on the list because I think it marginally relevant[ Derek writes: > And, just for future reference, people may be a little more willing to > help you if you're a little more polite with your postings. OK, "polite" is eomething I associate with saying "Hi Derek" at the start - it's largely low-entropy noise and I don't care too much if it's not present. What you probably mean by "polite" is what I mean by "considerate." That is people check google and mail archives before asking a question that has been answered many times on this list. Or maybe by "polite" you mean what I mean by "intelligent." But I forgive those who are new to this stuff, have little or no experience of it, and need an answer desperately. I've been there. I've needed answers quickly even though I consider myself intelligent (oh, how self-delusion leads us astray) and TRY to be respectful when I ask others to give me answers. I also know many people in many countries whose grasp of English is far better than my grasp of their language. Strangely, I know the translations of "kisses" and "hugs" in many languages. :) Bottom line: if somebody is obviously doing his or her best to get an answer, I will respond if I can. If somebody is trying to get me to do hi9 or her homework for them I will flame. I think the person who asked was stuck, but I didn't have an answer... -- Paul Allen Softflare Support
[vchkpw] Re: courier-imap / sql files
Hi Anders Anders Brander writes: > Extra security? I've always hated the vpopmail model, "all users are one > user" It has advantages and disavantages. It means that vpopmail runs under a dedicated user and group without (at the moment) any need for set-id. IMAP and POP servers do need setuid root if they are to work for system users and so I'd be more worried about them being compromised for root privilege than them being compromised so that somebody could turn himself into the vpopmail user and read other people's mail. I would go so far as to say that on a system where all users have vpopmail-owned mail and if the IMAP and POP3 servers were setuid vpopmail then you would have more security not less because only the mail system is exposed if somebody finds a hole (I'm not saying that somebody trashing mail is desirable but it's better than them trashing the whole system including mail).. > > Oh, unless you're using a PHP webmail > [snip] > > There could be many other reasons to give domainmail-admins > system-users. Admin'ing mailinglists for one. I've never played with it, but qmailadmin appears to support ezmlm mailing lists without needing system users. > Yep, or maybe the biggest feature. But hey, qmail is delivering to > systemusers isn't it? vdeliver doesn't even get run? As I understand things. But I have never looked too deeply into that. We don't have system users in the traditional sense. Clients have user accounts for FTP to their web sites but do not have shell access. Although we have a few admins as system users that's only so they can su root when necessary, their mail is handled through a virtual domain just like our customers. We don't have people who log into our servers to read mail in between playing nethack or whatever. > But theres much more to it than buffer overflows. How do we trust the > calling program, for one thing? You don't trust the calling program. You ensure that the directory these utilities are in is rx only to vpopmail:vchkpw. If somebody can su to those or insert a malicious program into ~vpopmail/bin and get it executed then you have more problems than a calling problem passing something weird. Those risks are present in the current model anyway, so adding these utilities does not make matters worse. If somebody can make a calling program maliciously call the database modify utility to wipe out arbitrary users they can do so under the current model too. The only thing these utilities would be doing in addition to what is currently done is providing a way of hiding the MySQL password. Essentially you would be extracting a few functions from libvpopmail, putting them into separate programs and adding the "get MySQL password" stuff to those additional programs. I don't see that this imposes an additional risk provided those additional programs are kept small and written well. Compared to having the password wired into libvpopmail.a, it is a significant improvement... I suppose we could always look how Courier does it to see if there's a better way, but that's cheating. -- Paul Allen Softflare Support
[vchkpw] Re: courier-imap / sql files
Hi Anders Anders Brander writes: > IMHO it's the correct (tm) way to do things. It's not just a fiddle, > it's the best solution. I would say that the setuid-thing is a fiddle. I think which way you regard as a fiddle depends very much upon what you do on your system. > I think we confused eachother, we were talking about two different > cases. > I: When domain.tld is given a systemuser for their mail. Ah, we don't do that. We probably could, since we have to give them a system user to FTP their web site, but why bother when vpopmail lets you get away with a single user? Oh, unless you're using a PHP webmail interface, in which case you'd be forced into giving each domain a separate system user to prevent people reading mail for other domains. Hmmm, but unless you have an equivalent of suexec for PHP then you'd have to leave directories writeable by the httpd user so that people can delete mail, which means that a malicious user could delete mail for other domains (the malicious user would have to guess at filenames and it would take many guesses to stand a chance of hitting one, but it's your CPU cycles he's burning not his). I know you asked me to leave PHP insecurity out of this, but I'm guessing that the reason you have a system user for each domain is a fiddle to work around PHP insecurity in the first place. > You: When systemusers needed personal mail. > - and now i can see the trouble ahead, but not that much trouble. The trouble is that vpopmail can be used in so many different ways. > OT: We use the billing-model too :) But we also have skilled users, the > kind that just sends you the conf-file, the kind that writes their own > zone data. The kind that never calls, and when they do - you KNOW that > they have a very good reason to do so. Our users are almost all technically incompetent. We expect them to call and blame us for what turns out to be their own problem. We charge them for that. > I was illustrating that it could quickly get hairy, when arguments have > to be passing to/from these tools. I think argument and value passing is reasonably well understood, relatively easy to code and the methods of avoiding buffer overflows known if not always widely applied. Provided the utilities are restricted to reading and writing the database it should be easy to ensure there are no known exploitable holes. > Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have > the great sendmail-flamefest now :) Indeed. But it's a valid point. Given the number of systems running sendmail which has had many exploits, a few very small pieces of well-audited setgid code pose far less of a risk. Particularly when sendmail is setuid root and the code I'm proposing would be setgid to a group used for no other purpose. Sendmail has bullets in 5 of the chambers and people play Russian Roulette with it all the time yet surprisingly few are killed. -- Paul Allen Softflare Support
[vchkpw] Re: courier-imap / sql files
Anders Brander writes: > > It could get rather unwieldy if you use MySQL for other things. > > Why? Just a gut feeling that if you have many MySQL users for one purpose and many more MySQL users who are there purely as a fiddle to allow vpopmail to work then it could make life difficult to distinguish the two. But I am easily confused. :) > It could easily be done with vadddomain, the user must pre-exist as it > is now, vopmail just have to create the .mysqlpass-file or whatever it > is called. Or am i missing something here? Yes, you're missing me having to do two things instead of one. There are ways of setting up vpopmail so that if I add a system user then they automatically get mail. Yes, those solutions are non-standard hacks using custom scripts but they exist. My work is finished after I do useradd. Every time I have to do two things to add a user it not only increases my workload it increases the chance that I do one but not the other. As I think I may have said, I am easily confused. :) > Another possibility it will open, is the users who administer their mail > with shell-access (mailinglists, other things) could have access to > their vpopmail-databases and do with them as they like. You may have users like that. We have one user like that (me) and one user who thinks he is like that (my boss, who gets more pointy-haired with each passing day). This is one of the reasons vpopmail goes in so many different directions - it has to attempt to cover so many different usage patterns. For instance, the quota stuff is essential for a company wanting to offer a hotmail/yahoo/whatever service. For us it gets in the way of us billing people extra for going over their allotted usage. > They could make ther own internal php-tools for example, You let your users play with PHP? I hope you have something that emulates suexec so you have some rudimentary protection against them using it to explore the filesystem. Then again, in your environment it may not matter. In ours PHP without an suexec equivalent would be a disaster. PHP, without modifications, is a security nightmare for any user who wishes to have a web interface create or modify files. When you have to make directories world-writeable or writeable by the UID of the HTTP server then you have a security nightmare. > setuid programs can be a very nice solution to many problems, but i > think that we should consider the possibility of just using standard > filelevel security. That's something that has been audited and proven > for years. Ummm, I don't trust ANYTHING. I remember when the third edition of the Camel book came out reading of many attacks that had not been mentioned in the 2nd edition because they had not been known then but had always been present. How about the race hazard when executing shell or perl scripts (these days largely eliminated)? How about the many race hazards suexec is vulnerable to (I know of no exploits and the checks it does are better than no checks at all)? As we both know, the only way to secure your computer is to ensure it has no connections to the outside world and you are the only one who has physical access - as soon as you relax those constraints you are taking risks. The question is: is this particular solution playing Russian Roulette with 5 out of the 6 chambers loaded or only 1 of the 6 chambers loaded... > It's a great idea to have several small tools to do tasks, my point was > just that it's not enough to return 0 or 1 (or 57). Again, I was illustrating how the simple case of password authentication (without APOP) would go. The idea was to establish the general model for doing this sort of thing with setgid cleanly. > It may turn out to be the best solution - but i see lots of problems > with this solution. > Mainly the passing of arguments to/from these tools. If it were just > TRUE/FALSE-returns i would be all for it - well, almost ;-). I always envisaged that these tools would be passed arguments - you can't do authentication without a username and password. :) And that they would return at least one value. Obviously, any tool which reads userinfo has to return several values. But although it is possible to program such things insecurely and vulnerable to buffer overflox exploits, it is also possible to program them securely (unless Ken Thompson has hacked your C compiler, in which case you're screwed whatever you do). Provided these tools are kept SMALL then a code audit will catch any currently-known vulnerabilities like people allocating a fixed amount of static memory to hold a string which the user determines. And provided they're small, the chance that the C compiler introduces an as-yet unknown vulnerability is also small. Set-id code is not without known hazards and there may be unknown hazards. I was addressing the question of whether there was any way of doing things relatively securely with set-id code. I don't think the risks are significantly high
[vchkpw] Re: courier-imap / sql files
Anders Brander writes: > If you add a special group to every user you are back where you started. I didn't say it was a good solution. I said it was a solution. Compared to that, a lot of the alternatives look good. > I can't see what's wrong with a mysql user per system user. That would > be really clean and effective. It could get rather unwieldy if you use MySQL for other things. > If the admistrative tools is integrated into vpopmail, i fail to > see any troble ahead (user/admin-vice). I can see one. I set up a system user. Who wants e-mail. So then I have to use another tool to add that user to vpopmail. > It would completely remove any use for any setuid/setgid-hacks. That is the one advantage I see to it. Whether or not one views that advantage as compelling is another matter. > > 3) A very small utility that is setgid vpsql. It does the following > > when passed a username and password to verify. > > You will also need small tools to do all other sorts of operations, > quota, valias and so on. I did mention those at the end. And even said that I preferred several small tools to one large one that use switches to decide what it did because that would mean more code and a harder time auditing it. > > c) Connects to MySQL. > > - and forgets username and password. OK, I take your point. It no longer needs them at that juncture and it's barely possible there's something exploitable later. > It's not as simple as that, think about APOP authentication... I don't have need of APOP so I didn't think about it. I was trying to establish the general principle for doing it setgid with minimal risks. I think something (well, several somethings) along those lines would be feasible without opening up vulnerabilities. None of us like set-id and try to avoid it, but there are times when it is better than the alternatives (if sufficient care is taken). Compared to the major hunk of setuid code that is sendmail and which a lot of systems run, this ought to be far less likely to be exploited. It's not the only solution and it may turn out not to be the best solution, but at least it's there for consideration (and possible improvement). -- Paul Allen Softflare Support
[vchkpw] Re: courier-imap / sql files
Tom Collins writes: > This is an interesting point and I'd love to find a clean solution to > this issue. I don't think you'll find a clean solution which doesn't involve set-id. All the others are messy to administer, like a MySQL username per system user or adding a special group to every user (do all *nixes handle that well these days?) How about this: 1) An additional user and group, vpsql, used for absolutely no other purpose (except perhaps as owner of vpopmail database). 2) MySQL username and password in a file readable only by vpsql user and group, and writeable only by vpsql user (if that - most people will probably edit it as root). 3) A very small utility that is setgid vpsql. It does the following when passed a username and password to verify. a) Reads the information in the password file. b) Drops setgid so it can do nothing further with the password file. c) Connects to MySQL. e) Verifies mail username and password against database. f) Returns go or no-go. I expect at least one person will poke holes in that somewhere, but I think the general principle is correct. Assuming you can drop setgid reliably (and not have it resurrected by an exploit later) then it ought to be safe. It would need a very close code audit but there's not going to be much code there to audit. The overhead of an extra process invocation per authentication is undesirable but, I think, unavoidable. You could just build it all into vchkpw but then a code audit would be a lot harder. Admittedly, if you read the password file as the very first thing you do and drop setgid as the very second thing you do then the rest ought not to matter, but with a separate vpsql user/group/program there is far less code containing possible exploits if somebody does know a way of regaining setgid after dropping it. Extending the idea to do allow qmailadmin and the like to modify user details is a SMOP. My preference would be for several utilies each restricted to one task like authentication, get user info, write user info rather than one big one that takes switches telling it what to do. -- Paul Allen Softflare Support
[vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
VeNoMouS writes: > in short, YES, because how is it related to what any one here reads, I'm someone here. I'm reading your latest post. Surely, by your own standards, I have a right to reply to it. > as far as ive seen this has been a post a q and answer forum, For six months it was a q and no a forum. That is what some of us think of as a problem and which to address so that once more thare are a's in response to q's. > not hi im gonna state my fucking opinion on what ever the fuck i feel > like, If I understand you correctly, you agree with posts that are questions and posts that are answers but NOT posts that are opinions. And yet the ONLY posts I have seen from you have been opinions. Please explain. > who died and made you ceo of inter7? Nobody did, any more than they made YOU CEO of Inter 7. And yet you feel entitled to post your opinion here while denying me mine. I will also point out that in the last six months Inter 7 has done absolutely nothing to support vpopmail while Tom has. So if you were to ask me who died and made me the CEO of Tom Collins your question would have slightly more relevance. > as i said before, take it to personal emails and leave us the fuck out of > your bitching. If you want to bitch to me without bothering the list, I suggest that YOU take it to personal e-mail first. If you convince me in personal e-mail that you are right the I will apologise to the list. If you continue to attack me on the list I will continue to respond. The choice is yours, even though I suspect you are too stupid to understand the options. And you still have not learned how to unnecessarily quote all of the mail that you are responding to, even after being fed large doses of clue. The cluephone is ringing, it is for you, but your service has been disconnected... -- Paul Allen Softflare Support
[vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
VeNoMouS writes: [A load of crap] So you quote the WHOLE of my mail to lecture me about wasting bandwidth and brainwidth in the mailing list and post it to the mailing list. Please find a dictionary and look up the meaning of the folliwing words: "hypocrite" and "moron." -- Paul Allen Softflare Support
[vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
Hello Rick Rick Macdougall writes: > I think Tom and Ken have resolved their issues off list So it appears. Ken has not resolved my issue with his involvement with vpopmail. > and we We??? Do you claim to speak for everyone on the list? Surely not because at best you can speak for everyone on the list EXCEPT me. And I suspect there may be one or two others you do not speak for either. > would appreciate it if you did the same. Gosh, wouldn't it have been a good idea if you wanted to avoid unnecessary traffic on the list if you had mailed me DIRECTLY instead of posting to the list? If you want to make your point ON the list then you have to allow me to respond there. Well, whether you allow me or not, that's what I'm gonna do. If you want to discuss this by mail then feel free to take it there. If you want to rebuke me on the list, however nicely, then expect me to respond there. As I explained to somebody else today, all you get to control is what you read and write and where you post it. You do not get to control what I read and write and where I post that. Any attempt to claim the moral high ground about unnecessary traffic to the list which is POSTED TO THE LIST will get the rebuke it deserves ON the list. > If Tom or Ken has an issue, it may belong on the list, if you personally > have an issue with Inter7 and/or Tom it does not. I disagree with your statement, for which you have provided no backing. If I disagree with Ken being an admin and can provide a compelling argument for my belief then that DOES belong on the list. I believe I have provided grounds why Ken is not a suitable choice for an admin. Perhaps you would care to provide some reasoning, however slender, why I should not take issue with Ken here. > Thank you in advance for your understanding. You are ever the optimist... -- Paul Allen Softflare Support
[vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
Robert Kropiewnicki writes: > I've spoken definitively to no such thing. What Ken Jones will do now > that he has been granted admin access (bravo Tom!) is not at the core of > my argument. My argument is that he has done enough in the past for > vpopmail development to warrant his inclusion as an admin. I disagree with you there. What Ken did in the past prior to the last six months is sufficient to get him many mentions and many praises. And if he had continued doing the same in the past six months then he would still be project leader. It is those past six months, and the responses from Inter 7 in the past few days, which are critical. I give you a preview of the next UK Olympics Selection Committee meeting... A: who are we going to select for the 1500 metres? B: I suggest Roger Bannister. He was the first person to run the mile in under 4 minutes. He has a proven track record. C: *groan* Bad pun! D: I want to know how he has performed recently. Surely that is important. B: It doesn't matter how he has performed recently. What matters is that he used to be the best! E: Do any of you bozos know that Roger Bannister is DEAD? B: That doesn't matter. What matters is that he once broke an important world record. Therefore we should select him. > Many of the projects I spoke about in terms of personal experience had > more to do with internal infrastructure projects. Actually, it was > projects for external paying clients that would often be the reason they > were put on hold. With any business, the needs of the paying clients > come first. You said it. With Inter 7, as long as people keep paying them to install vpopmail BECAUSE they have their name on the project, their motivation in times of difficulty will be to divert resources to paying clients and let vpopmail development go unattended for six months. In fact they DID let vpopmail development go unattended for six months and only paid attention to it once more when it appeared that the Inter 7 name would no longer be listed as its developer. If it takes that to motivate them into paying attention to this list then they are NOT good candidates for an admin position. Because if they can delete the other admins then we return to a situation where vpopmail development is a lower priority than Inter 7's paying customers and can be neglected for half a year at a time. > For the most part I can agree with this argument. If Ken were going to > have complete and total administrative control again to the exclusion of > Tom, I would completely agree with this argument. As I understand Tom's assessment of things, if Ken has equal powers to Tom then Ken can kick Tom out. As I understand the mail from the Cat, that is something I consider to have a significant probability of happening. > However, as it stands right now, Ken and Tom are both listed as > administrators Can one administrator delete the other administrators? Can one administrator copy the whole CVS tree then delete it? As I understand it, Tom's only defence against a sneak attack of that nature is to maintain his own local CVS tree (which is a pain). Would Inter 7 do anything like that to re-assert the brand ownership of vpopmail so that they continue to be the first port of call for people who have problems and are willing to pay for answers? I don't know. But after the Cat's catty mail and Ken's equivocating mail I cannot deny the possibility. That may be grossly unfair to Inter 7, but they are the ones who control what they did and what they wrote, not I. If what they did and wrote causes me, and many others, to distrust them then that is their fault. If I needed urgent support, so urgent that paying an outside consultant were warranted, then Tom would be top of my list and Inter 7 would be the very bottom, just below the option of selling my soul to the devil for an answer. The position of Inter 7 on my list is absolutely nothing to do with anything that Tom has done and everything to do with what Inter 7 have failed to do for six months and have done for the past few days. As a user of vpopmail, I am no longer happy with an Inter 7 involvement of any kind. -- Paul Allen Softflare Support
[vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
Robert Kropiewnicki writes: > Do you work for Inter7? Can you speak definitively to the fact that > they've shelved vpopmail for good on their end? No, you can't. And can you speak definitively to say that they haven't? Despite Ken's sudden re-appearance here, can you positively, definitely state that Ken is going to be as active now and in the future as he was six months ago and that there will be no more sudden disappearances for months on end? > I've seen enough projects in enough companies get put on hold for > periods of time because there was something else that required more > attention. Heck, I've had projects I've worked on get put on hold > because management decided something else was a more pressing matter > only to return to the project when the pressing matter had been > completed. And in those cases I would expect the companies involved to be honest with external clients who are waiting for the completion of those projects, at least if the client asked when it was going to be ready. Clients are funny that way - if you tell them there has been a delay they may accept that delay but if you ignore them they go somewhere else. By not even saying that he was busy or delegating it to somebody else Ken put himself in the situation where people walked away. > Failure of Inter7's management to recognize the need for either visibly > active development or at the very least, acknowledge the fact that Ken's > hands were currently tied due to being assigned other projects should not > be held against Ken. No, it should be held against Inter 7. Which may or may not be Ken himself. Whether it was Ken's decision or that of a pointy-haired boss makes no difference. Somebody at Inter 7 thought it acceptable for Ken to ignore this list and vpopmail development for 6 months. I do not think that acceptable. > Disagree. If Linus Torvalds had to step away from working on the Linux > kernel for an extended period of time, would he have to justify why he > still deserved to be a lead on the project? If he stopped working on the kernel for 6 months without telling anyone, without responding to bug reports or patches and effectively stalling development until somebody forked development then he damned well would have to justify being a lead again. But we both know that Linus would not do that. If circumstances forced his absence for a prolonged period he would delegate control temporarily. Ken did not even delegate control temporarily. It was left to Tom to pick up the ball after realizing that Ken had apparently given up on things. It appears that the only reason Ken has expressed any interest since is because Tom formally took control and so Inter 7 would lose the right advertise themselves as the developers of vpopmail. I do not see any behaviour by Ken or Inter 7 that justifies Ken having administrative control but I do see a lot of behaviour by Ken that justifies him NOT having administrative control. -- Paul Allen Softflare Support
[vchkpw] Re: Inter7, vpopmail, and open source standards
Ken Jones writes: > Since I have been working on vpopmail almost every day > for the last 5 years (including most weekends), it is very > difficult for me to hear people saying I have not done enough > lately. Even during these last 6 months where we have not > made a new devel release If I had submitted bug reports or patches during those six months and there had been no new release in all that time then I would say that you had not done enough no matter how much work was going on behind the scenes that I was unaware of. > I continue to work on it just about every day: So far, so good... > training people, Training employees so that they can offer paid support to customers? Training paying customers? Those are business operations from which you gain but the rest of us do not. > trouble shooting, installing, Ditto. If you're doing that stuff for free then criticisms of you were harsh (but still valid because bugs need to be fixed). If it's paid work then it doesn't count. I get paid to install vpopmail on systems but I do not in any way claim that such work contributes to vpopmail development except indirectly if I find and report a problem. > trying to work on new documentation, New documentation would be good. But secondary to fixing real bugs or adding features needed to support enhancements in sqwebmail and the like. And 6 months to update documentation seems rather excessive to me. Can we see it or did a dog eat it yesterday? > monitoring the mailing list. Ummm... If you monitor the mailing list then why did you not notice several months ago that Tom and others have been working on vpopmail? If you monitor the mailing list then why do you rarely notice that Tom has put out a new development release and update the Inter 7 website to reflect that? If you monitor the mailing list then why did you not notice several days ago that somebody keeps maliciously subscribing auto-responders to the mailing list and remove them? I have to say that I now agree with Tom irrespective of Ms Cat's ill-advised mail. You just pegged my bullshit detector at FSD. -- Paul Allen Softflare Support
[vchkpw] Re: SMTP-Auth bug in passwords?
Mike Miller writes: > I believe what you say (that if I enable MD5 passwords, then it will work > for both), I didn't say that. I said that if vpopmail were written correctly then it would work for both. > There should really be a note that it will accept existing crypt > passwords but store new ones in MD5. If it actually does work that way then I would agree with you. > I just didn't want it to stop working when migrated users. If I were you I'd look through the source or try it on a test box before risking it on a production server. -- Paul Allen Softflare Support
[vchkpw] Re: SMTP-Auth bug in passwords?
Mike Miller writes: > Any way to convert an entire large site of cdb files (probably > 150 domains) into MD5? Actually coverting is the wrong word [since you > can't do that unless there is clear text passwords], but rather to have it > choose between both MD5 and CRYPT passwords (based on length) to migrate > from crypt to MD5? I don't know how vpopmail handles this. If it was written correctly then on most recent releases of *nix then both types of crypted password in the same cdb ought to be possible. DES crypt requires two characters of salt chosen from A-Za-z0-9./ while MD5 crypt requires eight characters from the same character set prefixed by $1$. The wrong way to code things is to examine the crypted password (which starts with whatever salt has been used) and figure out whether it's DES or MD5, extract the appropriate amount of salt and pass that with the plaintext password to crypt and see if the result matches the crypted password. The really wrong way to code it is to fix at compile time what type of crypt should be used when validating passwords. The right way to code this is to use the crypted password itself, in its entirety, as the salt for crypting the plaintext password when you validate the password. Versions of crypt which support MD5 also support using the entirety of the crypted password as salt and then figure out how much of that really is salt without you having to bother. Do it this way and both types of crypted password can be used in the same file even though when passwords are set or modified they will be converted to whichever type of crypt you said you wanted to use. If vpopmail does it that way then you can happily turn on MD5, with existing passwords continuing to work and new or changed passwords being MD5 crypted. If vpopmail doesn't do it that way then you have problems until the next release appears. -- Paul Allen Softflare Support
[vchkpw] Re: SMTP-Auth bug in passwords?
Mike Miller writes: > Okay, but should it be _allowing_ this as a password or don't you think > that it should reject it? I think that it is behaving at it is documented to behave and that your expectations are wrong. > There is a very big difference between 'webmaste' and 'webmaster23445' > in terms of security, as I just found out. Not a big difference, but more than the difference between webmaste and webmaster00 which is what you said was being used. Password cracker programs try using the username as a password in combination with one or two digits at the end as the FIRST thing they do. Mail authentication is not tarpitted like user logins so a cracker can happily try all combinations very quickly. If that mail login also happens to be the username and password for a user login you start to have serious problems. If you think webmaster23445 is secure you need to think again. > The reasoning for my use of CRYPT is that most of my users are still from > when VPOPMAIL didn't support MD5. Crypt is capable of supporting both styles of password in the system passwd file so if vpopmail has been coded correctly then it ought also to support both types of password. It is a simple matter of using the crypted password itself as salt when doing a trial crypt of the plain password. > But in terms of this situation, the base64 password that the user sends > would likely be better decode_base64()'d and then compared against the > clear-text password. Comparing against the plain text password would allow longer passwords. Having plain text passwords is, itself, a security problem. Think about users who use the same username and password everywhere, including their on-line banking. Think about being the only one of the systems that user uses which holds the password in plain text. Think about what happens if that user claims there was an unauthorized on-line withdrawal. Your system being the only one to have the password in plain text is not proof of guilt and the others having the password crypted is not proof of innocence, but you try convincing a jury of that... -- Paul Allen Softflare Support
[vchkpw] Re: SMTP-Auth bug in passwords?
Mike Miller writes: > Nope. Not using MD5 passwords. That would explain it then. As Tom said, DES-style crypt ignores everything after the first eight characters of the password. MD5-style crypt has a higher limit, from memory I believe it's something like 126. -- Paul Allen Softflare Support
[vchkpw] Re: Inter7, vpopmail, and open source standards
Chris Pugh writes: > If this statement is true then make impartiality the > byword. Total admin control over the project should be > given neither to Tom nor Ken, but to an independent > indiviual, a moderator, not necessarily someone with a > vested interest in the vpopmail project. But somebody with no vested interest is also somebody who is unlikely to put much effort into it or to understand enough about it to resolve conflicts about what changes should or should not be made. The right person to head a project is one who either does most of the work or directs most of the work. That used to be Ken. It is now Tom. With Tom there have been many improvements and bug fixes that would NOT have happened without him. > On the Inter7 base page vopomail along with other > items is listed under 'Free Software' > > http://www.gnu.org/philosophy/free-sw.html > > Who is going to draw what line and where? According to that link, everyone has the right to improve and redistribute their changed version, which is exactly what Tom has done. Over on http://www.opensource.org you will find links to Eric Raymond's thoughts on code-forking. It is his opinion that as long as a project is active and well-run then code-forking is undesirable (although not forbidden even then) but that when a project becomes inactive or badly-run then code-forking may be necessary. As has been made clear by others, Ken stopped doing anything with vpopmail for several months, did not apply bug-fixes sent to him, etc. When something like that happens then code-forking is not just permissible, it's desirable. In fact, when a lapsed project is taken over it is not usually seen as code-forking but merely a change of ownership and a name change is unnecessary. Nor is there any guarantee that Ken would devote more effort to it in the future since Ms Cat told us all about the bigger and better things that Ken is working on. And while I understand Inter 7's desire to be associated with vpopmail because of the kudos it gives them, that same fact also worries me because they may be tempted to take full control and kick Tom out so that once again vpopmail is perceived to be an Inter 7 product. If Ken had been as active as Tom has these past months then that wouldn't be a problem, but he has not. If Ms Cat hadn't stepped in then the prospect of Ken being able to kick Tom out wouldn't be such a concern, but after her mail it is - that was very much an "it was our product originally and we demand full and exclusive control" mail. Yes, it's sad that Ken no longer has control of a product he did so much work on but that's what happens to people who let GPL projects lapse. And until and unless Ken decides to play a major active part in development once again he has no technical need of control (a commercial need, perhaps, but that is insufficient justification). If Ken wanted to keep control he should have kept working on it and been responsive to bug reports and submitted patches. It's as simple as that. If Ken decides to code-fork away from Tom's work then it is Ken who should rename his product, not Tom, because ownership of vpopmail transferred when Ken turned his back on it. The fact that Ken is now showing an interest again does NOT mean that control or the name reverts to him. He had his chance to keep working on it. He had his chance to say he would be busy for a few months and to delegate control temporarily to somebody else. By not responding he blew it. It is also worth noting that Tom is setting up CVS so that a TEAM of people can continue to work on vpopmail even if Tom is temporarily unable to do anything on it himself for some reason. With Inter 7 revision control was essentially if and when Ken decided to make changes. This is yet another reason why Tom is the better choice to control the project because he is ensuring that it will continue to be developed even if he cannot work on it; when Ken turned his back on vpopmail all work stopped until Tom forked it. Tom has done after a few months of control what Ken did not after several years of control - he's put it on CVS. I'm not criticising all the great work Ken did in the past. But he stopped doing it... -- Paul Allen Softflare Support
[vchkpw] Re: Inter7, vpopmail, and open source standards
dalmata writes: > No need to use bad words. Those words expressed my feelings exactly; other words would not. > That is a personal attack Correct. As were her comments about Tom. Her attack was more subtle but it was still a personal attack. I consider her attack to be worse than mine precisely because it was disguised and intended to mislead people into thinking it was not an attack but a call for unity. > that is useless and uncomfortable to me. I found it useful and comfortable. You get to determine what you read and write, not what I read and write. Therefore your only way of avoiding discomfort is to exert the control which you do have over what you read and not the control which you would like to have (but do not) over what I write. > I am sure that Bill Gates would be very glad to read this thread. I doubt it because this thread shows that nobody owns GPLd software and that monopolies are not possible in Open Source. The fact that there can be dissent is entirely foreign to Bill's methods of operation. Bill would be far happier if Inter 7 had been able to enforce their desired control over Tom Collins and the users of vpopmail because then development of vpopmail would have stalled again. Bill would be far happier if owners of projects could insist that nobody fork them because they had left the project idle for several months and ignored requests for bugs to be fixed. > And Ben Laden to read your comments. Dubya has done more to drive up al-Qaeda recruitment than bin Laden ever did. Which is only fair because bin Laden has always been a puppet of the same people that control Dubya. The attacks of 9-11 benefited Bush and his cronies immensely, which is why the ample warnings were "ignored," why the US Air Force did not follow Standard Operating Procedures that day, and why there continues to be a massive cover-up over events. For a European you are almost as misinformed as most people in the US yet you do not have their excuse of media willing to cover up Bush's lies and incompetence. This recent article by a UK Member of Parliament covers only a small portion of the damning evidence against Bush but should be enough to let you use google to find the rest. http://politics.guardian.co.uk/iraq/comment/0,12956,1036687,00.html -- Paul Allen Softflare Support
[vchkpw] Re: Inter7, vpopmail, and open source standards
Ms. Catherine Kouzmanoff writes: > It is a time to call together everyone on this list to insist that Tom > Collins add Ken Jones or another representative from Inter7. I've been using vpopmail for a few years now and didn't really care who was in control as long as somebody was. When I saw Ken's comments I thought that perhaps Tom had acted a little precipitously in blocking Ken. After seeing your shameful comments I am inclined to think that Tom was correct. Ken himself seems like a nice guy who is genuinely concerned for the users and who feels left out. You seem like a piece of shit determined to keep the Inter7 stamp on vpopmail at all costs (which fall upon the users). Tom has done a damned good job and Ken has been inactive recently. If I had to choose one or the other then I would choose Tom on that basis alone. After your shameful diatribe I am of the opinion that Ken NEVER have admin access to the sourceforge project while you remain an employee at Inter 7. You have George Dumbya Dush's talent for uniting people. Most of the world now hates the US and most of this list now hates you and Inter 7. Well done! -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail + freebsd Compile error
Tom Collins writes: > A small group of developers is actively maintaining it there. It would be nice to know what some of the more dangerous-sounding programs in ~vpopmail/bin do without running them without giving a -? option and hoping that it will be treated as an invalid option and therefore the program will display a little usage information. It looks like the docs have not caught up with these. Even a minimal description of what they all do would be helpful. I'd volunteer to read the source and create minimal descriptions but the source doesn't say what they do either. -- Paul Allen Softflare Support
[vchkpw] Re: 5.3.26 error with chkusr patch + mysql
[EMAIL PROTECTED] writes: > The approach of tarpitting is to slow down the attacker without impacting > your network or requiring additional resources on your end to deal with > the cracker. That is the ideal. The ideal is unachievable. > I *think* it does this by analyzing the volume of incoming > SMTP requests from the same host. I do not know if it does it this way or not but if it does then it can be circumvented. Instead of trying usernames at one domain then moving onto the next you pick a very large number of domains and try the same username at each of them before moving on to the next username. If you have multiple machines under your control (most viruses these days install remote-control backdoors) then you can get away with fewer domains. > I think its entirely appropriate to respond VERY slowly to an unknown > username request. HOWEVER, if I suddenly have a shortage of SMTPD daemons > because they are left open to service the "chkuser tarpit", and that hurts > my email service quality, then I haven't gained anything. I would rather > be fast at dumping chkuser denials and let them guess. Precisely. The problem with tarpits is that unless they block IP addresses with a large volume of authentication failures they can be turned into denial of service attacks very easily, but if they work that way then they cannot be effective against distributed attacks. And if you make them effective against distributed attacks by temporarily disabling mail connections for a domain then the tarpit can still be used as a DoS attack against that domain. -- Paul Allen Softflare Support
[vchkpw] Re: courier pop3d
Tom Collins writes: > I'd love to hear from someone who's tried with a recent version, and > whether it worked or failed (and if it did fail, where/how did it fail). I tried it with 5.3.24 and authdaemon authentication worked fine. I then had to switch to 5.3.26 because of a bug in 5.3.24 and it still works fine with authdaemon. -- Paul Allen Softflare Support
[vchkpw] Re: qmail + vpopmail + maildrop + sqwebmail + qmailadmin + vqadmin
Casey Zacek writes: > Basically, I'm looking for any pointers for getting vpopmail, > maildrop, and sqwebmail working together nicely. Since it's been a long time since you've looked at it, you will probably be surprised to learn that sqwebmail now supports the generation of maildrop filter files. When used as part of the Courier MTA I believe that they integrate seamlessly. When used with vpopmail they don't integrate at all. The vpopmail and qmailadmin teams are still deciding the best way of handling things. I posted one workaround here a week or two ago that patches vdelivermail in a way that means nothing else has to change and, more importantly for me, qmailadmin can be used as is to administer domains. That is especially important to me now that the newer versions of qmailadmin allow more ways of controlling what happens to mail for unknown users (delete, bounce, drop in nominated maildir, forward to external mail address) - I didn't want to lose any of that functionality. As for quotas, I don't know. They're not something I've had to play with because we prefer to permit clients to go over quota so our accounts department can send them a nice mail saying their options are to delete old mails or pay us for additional disk space. -- Paul Allen Softflare Support
[vchkpw] Re: vpopmail and learn passwords
Hello Peter Peter Palmreuther writes: > > I know a lot of users who are paranoid about giving their passwords > > out to anyone. > > But obviously not paranoid enough to use non-plain-text authentication > like APOP, which would make it impossible to learn the password *head > shaking*. And not paranoid enough to know that using the same password for more than one purpose is a VERY bad idea. One of those systems might store passwords as plaintext allowing all the admins to see them. Systems which use qmailadmin allow ordinary users to log into it (this is documented but very easy to miss) and from there they can change their paassword and other aspects of their account (what can be changed depends upon the version). -- Paul Allen Softflare Support
Re: AW: AW: AW: [vchkpw] Clear Passwords
Andrej Dragicevic writes: > Here is a sample. > > $pwd = "\$1\$LObTh\$LcOWUS4U6glAr2vB4oycr0"; // this is the vpopmail > password > $decrypted = "test"; > > if ( crypt($decrypted, "\$1\$LObTh\$") == $pwd) > echo "success!"; > else > echo "failure!"; > ?> That approach works but relies upon you figuring out where the salt ends and passing it to crypt. The more popular flavours of Unix these days have at least two different ways of crypting the passwords: the old-style DES-based and the new-style variant-MD5-based. They have different lengths of salt for the different methods. An easier way to do it is to use the crypted password itself as the salt, because a crypt that can handle both styles is usually smart enough to accept the crypted password as salt and separate the salt out itself. So you'll probably find that if (crypt($decrypted, $pwd) == $pwd) does what you want. Well, I'm assuming that in PHP "==" is a string comparison operator as well as a numeric comparison operator (in perl the string comparison operator is "eq" and your "==" comparison would almost always be true even with the wrong password because strings which don't look like numbers are treated as 0 in perl). -- Paul Allen Softflare Support
[vchkpw] Re: 5.3.23 vadduser segfaults
Tom Predmore writes: > Wouldn't 5.2.2 be better to use rather then 5.3.24? It depends upon how many risks you want to take and how much you need stuff that's in the 5.3 line but not in 5.2.2. Sadly, the inter7 link to development versions led me to 5.3.23 and not 5.3.24. I did have a vague memory of 5.3.24 being mentioned but I'm suffering from mail list overload, goldfish memory, a very full deleted folder and idiot customers taking up most of my time because they managed to get infected with both msblaster and sobig at the same time (I don't deal with Windoze stuff directly but their infected machines were overloading the firewalls we supplied that are 99% idle in normal use and, of course, they were too clueless to deal with the problem in a sensible fashion). Sigh. Customers. You can't live with them; you can't cut them up into small pieces and flush them down the toilet (not if you want to get paid). -- Paul Allen Softflare Support
[vchkpw] 5.3.23 vadduser segfaults
I upgraded from 5.2.1 to 5.3.23 recently to get a fix for the bug in vchkpw that stopped the authdaemond authentication working. I found that vadduser has a segmentation fault when I try to add a user (no switchs used). By not giving the password as a parameter I find that it waits until I press return after entering the password a second time before segfaulting. I also found that vadduser does the same thing (and I suspect so will vmoduser and vdeluser). Configuration switches used to build it were: [EMAIL PROTECTED] \ --enable-tcp-server-file=/var/vpopmail/etc/tcp.smtp \ --enable-tcp-rules-prog=/usr/bin/tcprules \ --enable-roaming-users=y \ --enable-relay-clear=30 Due to a setup I inherited which I'm reluctant to change, the original vpopmail installation of a much earlier version has /home/vpopmail specified as the home directory but /home/vpopmail is actually a symlink to /var/vpopmail, with anything that has to refer to the vpopmail directory using /home/vpopmail (I know it's not efficient, but the guy who did that install had done almost all of it with vpopmail living in /home/vpopmail when the boss told him he wanted the mail stored on /var because it was a much bigger partition). I mention the symlink just in case it has a bearing on the issue. I see from the changelog that in 5.3.17 a change was made in vcdb.c to stop vadduser dumping core if the -s switch is used, and I suspect that might have introduced a bug (although if I do use the -s switch it still segfaults on me). For now I've copied over the 5.2.1 versions of vadduser, vadddomain, vmoduser and vdeluser (I don't know what vdeloldusers is for and there doesn't seem to be any documentation about it) and hope that there are no subtle incompatibilities. Any ideas (better still, fixes) would be appreciated. -- Paul Allen Softflare Support
[vchkpw] Re: Vpopmail + qmail + courier + imp - IMAP login problem
Hi nik nik [tm] writes: > I am sure you have heard this one before, Yes, but only recently. > I have the problem where once you login to imp (with IMAP) with more > than 5 characters long user part of the email, then all the shorter > usernames cannot login (until I restart the services) The problem is actually that the longest username used so far screws up any shorter usernames. It is a bug in vchkpw not clearing a buffer. Tbere is no problem if you call vchkpw from separate processes (because each invocation leaves a clear buffer area on most OSs) but there is a problem if you call it from sutdaemond. The fix is either don't use authdaemond or get the latest beta vpopmail, -- Paul Allen Softflare Support
[vchkpw] Re: mysql gone away. Please help a noob.
Hi jon kutassy writes: > I took the windoze approach and restarted mysql, and its all working > fine!! Which has the same effect as the suggestion in an earlier reply: flush privileges, but results in a longer outage of mysql. An alternative to doing "flush privileges" from the mysql client is to do a "mysqladmin flush-privileges" (or "mysqladmin reload" which means the same thing but is less typing). And you didn't use the Windows approach. The Windows approach is to reboot the computer any time you make a change. In fact, the Windows approach is to force a reboot upon you any time you make even a trivial change to the configuration. I suspect the day is not far off when Windows will report "You have changed a critical configuration flag by toggling the caps-lock key. Windows must reboot now." Followed in a future release by "Windows has detected that the position of the mouse has changed and must reboot." (oh, my mistake - that last feature has been in Windows all along, it just fails to work most of the time and when it does work you think it's a random crash). BTW, does anyone know if Microsoft-owned Hotmail is still using qmail despite Bill's repeated attempts to force them to switch to Exchange? :) -- Paul Allen Softflare Support
[vchkpw] Re: Help please, double message
Mailing Lists writes:
> Hi folks, need an help.
> I set up my qmail-vpopmail system to filter mail via maildrop. So i put
> this two lines in my .qmail-default file
>
> | /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox
> | /usr/bin/maildropmailfilter
>
[...]
> Obviously, removing the firt line solve the problem, but invalid
> addresses are no more notified.
As yet there is no official solution to having user mail filters
automatically acted upon, but one is being worked on. An interim
solution is to create a .qmail file in the user's directory (e.g.,
/home/vpopmail/domains/your.domain/user/.qmail with the line
| /usr/bin/maildrop .mailfilter
Note that this .qmail file is NOT processed if mail is delivered
to the Maildir by an alias. Qmailadmin generates aliases which
deliver direct to the Maildir (.qmail-user contains a path to the
Maildir) although this will change (has changed?) so that qmailadmin
crates aliases which actually work like forwards so that the users'
.qmail file is always processed.
An unofficial solution for use with vpopmail and the filters created by
sqwebmail, is as follows. You may be able to adapt it to whatever you're
using. Basically, the patch means that if there is no .qmail file in the
user's directory but it finds a .mailfilter file then it pretends that
it found a .qmail file containing the line shown in the interim solution.
If you're not using sqwebmail to generate filters then you'll have to
modify it accordingly.
1) Create /usr/local/share/sqwebmail/maildirfilterconfig (that's the
default location, you may have told sqwebmail to put its shared stuff
elsewhere) with the lines:
MAILDIRFILTER=../.maildirfilter
MAILDIR=./Maildir
2) In vdelivermail.c, replace the function (and comments preceding it)
with this:
/* Check if the vpopmail user has a .qmail file in thier directory
* and foward to each email address, Maildir or program that is found
* there in that file. If there is no .qmail file but there is a
# .mailfilter file then invoke maildrop on the filter file.
*
* Return: 1 if we found and delivered email using .qmail or .mailfilter
* : 0 if not found either .qmail or .mailfilter
* : -1 if no user .qmail file or .mailfilter file
*
*/
int check_forward_deliver(char *dir)
{
static char qmail_line[500];
char tmpbuf[500];
FILE *fs;
int i;
int return_value = 0;
int deliver_err;
chdir(dir);
/* format the file name */
if ( (fs = fopen(".qmail","r")) == NULL ) {
/* no .qmail file, so check for .mailfilter */
if ( (fs = fopen(".mailfilter","r")) == NULL ) {
/* no .qmail or .mailfilter file, so return -1 */
return(-1);
}
/* there was no .qmail file but there was a .mailfilter
* file so invoke maildrop */
strcpy(tmpbuf, "| /usr/local/bin/maildrop .mailfilter");
deliver_err = deliver_mail(tmpbuf, "NOQUOTA");
if (deliver_err == -2) {
printf("system error\n");
vexit(111);
} else if (deliver_err == -3) {
printf("mail is looping\n");
vexit(111);
}
return(1);
}
/* format a simple loop checker name */
snprintf(tmpbuf, 500, "[EMAIL PROTECTED]", TheUser, TheDomain);
/* read the file, line by line */
while ( fgets(qmail_line, 500, fs ) != NULL ) {
if (*qmail_line == '#') continue;
/* remove the trailing new line */
for(i=0;qmail_line[i]!=0;++i) {
if (qmail_line[i] == '\n') qmail_line[i] = 0;
}
/* simple loop check, if they are sending it to themselves
* then skip this line
*/
if ( strcmp( qmail_line, tmpbuf) == 0 ) continue;
deliver_err = deliver_mail(qmail_line, "NOQUOTA");
if (deliver_err == -2) {
printf("system error\n");
vexit(111);
} else if (deliver_err == -3) {
printf("mail is looping\n");
vexit(111);
}
return_value = 1;
}
/* close the file */
fclose(fs);
/* return if we found one or not */
return(return_value);
}
--
Paul Allen
Softflare Support
[vchkpw] Re: user setup of forwards
Benjamin Tomhave writes: > .qmail-default in the sofast.net domain root -- it's the standard call of > maildrop ../mailfilter within that file. Do you have just maildrop or /usr/local/bin/maildrop? That might not be on vpopmail's path. Is /usr/local/bin/maildrop actually there? If you cd into the sofast.net domain then cd .. and do an ls, do you see mailfilter in the listing? Oh, and have you done a mailq do see if they really have vanished or if they're deferred? -- Paul Allen Softflare Support
[vchkpw] Re: user setup of forwards
Hi Benjamin Benjamin Tomhave writes: > (Cross-posting to vchkpw and qmailadmin mailing lists.) > > I'm currently running qmailadmin 1.0.25 and vpopmail 5.3.20 (been waiting > for a 5.4 release). When users login to qmailadmin with their personal, > non-postmaster accounts and create a forward, a .qmail file is created in > the account/ directory, at the same level as Maildir. Correct. It's only recently that I've been playing with a version of qmailadmin new enough to do that, and it came as a surprise. I can think of two reasons why such functionality may have been added. The first is that it allows users to set up forwards for their mailbox without having to pester the domain administrator to do it for them. This could have also been achieved by having qmailadmin permit a user to create/modify/delete a .qmail-username file ONLY if it matched their mailbox name, but this way allows the domain administrator to over-ride the user's forward with an alias (although setting up an alias for a user that delivers to that user's maildir using qmailadmin requires some devious trickery, it is possible). The second is that it appears to be the way intended (but, as far as I can see, undocumented) for users to enable sqwebmail mailfilters. If their forward contains: | /usr/local/bin/maildrop .maildirfilter then vdelivermail will hand over delivery to maildrop. The only other way I know of invoking maildrop is to manually edit the .qmail-default file, thereby sacrificing vdelivermail functionality and running the risk of a careless domain administrator undoing the maildrop change by playing with the catch-all settings. Manually putting maildrop into .qmail-default is not an option in our usage where we have many clients each with virtual domains, some of whom want to be able to use all the features of qmailadmin including whether to have mail to unknown users bounced or deleted or to change which account acts as catch-all. But I also feel that instructing users that if they want to use mail filters they have to type in the above delivery instruction into the forward is not a tenable option. Some of the users we get are not capable of typing their own e-mail address into their e-mail clients correctly. One of them appeared to not even know what her own surname was, having called herself [EMAIL PROTECTED] when in fact she was [EMAIL PROTECTED] (no, she was not recently married or divorced). So I hacked my copy of vdelivermail so that if it couldn't find a .qmail file in the user's directory it then looked for a .maildirfilter file in that directory. If it found the .maildirfilter file then it pretended that it had just read a .qmail file containing the above delivery instruction. That meant that if anyone set up an sqwebmail filter it automatically worked without them having to create that awkward forward. It also meant the user could temporarily over-ride the filters by setting a forward if they wanted. I did submit a patch to Tom but he didn't say whether or not he intended to use it. BTW, I did read somewhere that qmailadmin developers were considering dropping aliases because an alias bypasses the user's .qmail file if they have one, but a forward does not (because it gets re-injected into qmail). I consider that to be a feature rather than a bug. Imagine a sales team, where the alias sales@ expands to the maildirs of all the members of the team. One of the team sets up a vacation autoreply in sqwebmail. Because sales@ is an alias, mail to the sales team bypasses his filter, which is exactly what you want. If qmailadmin drops aliases then that would have to be done with a forward and mail to the sales team would get an unwanted vacation reply. > This does not appear to be getting processed correctly as the messages > appear to disappear into oblivion (w/o so much as a bounce). It works for me, although I'm using vpopmail 5.3.23. I don't know if it was broken in some earlier versions. Are you sure the contents of the .qmail file are sensible? > I've typically always manually setup forward as .qmail-account in the > domain's base directory, not through use of .qmail files in the user's > directory. You still can do that if you're the system admin or the domain admin. It's just that now users can do it themselves but the admin can over-ride them with a "traditional" alias if necessary. > Second, is use of the .qmail file the best/correct implementation, It is an additional feature which permits additional functionality, namely users being able to set up a forward without having to ask the domain admin to do it for them. If your domain has a lot of users who frequently want temporary forwards, you'll appreciate this. > or was this "fixed" in 1.0.26 (which I haven't had time to compile yet) > by reverting back to the .qmail-account format in the domain's > base directory? If you use qmailadmin as the domain administrator you still have the "traditional" .qmail-account. --
[vchkpw] Re: "vpopmail documentation initiative"
Hi Ron Ron Guerin writes: > There will probably always be gems in the archives that appear nowhere > else. But "search the archives" should only be the answer for very > recent, or very obscure things that have yet to find their way into the > documentation. Archives should supplement documentation, not _be_ > documentation. Again we're in perfect agreement - "search the archives" is good for something that's come up recently. The vchkpw uninitialized buffer causing authentication errors if you use courier-imap with authdaemond is a very good example (and one that bit me). I think you're right about obscure stuff to the extent that an answer of "I think I saw somebody mention something like that a few years ago" is better than no answer at all, but I don't think that obscurity or unpopularity are, by themselves, an excuse not to document something. It is my experience that if somebody asks it once then sooner or later somebody will ask it again, unless it's about a bug that has since been patched (and even then you may get people running old versions who didn't encounter the bug until recently). I also know that in some quarters pre-canned scripts and good documentation are frowned upon. The theory being that mail is such an important issue that you have to understand the mail system to postgraduate level before you install it. I don't think that is a sensible attitude any more. Most Linux distros come with sendmail out of the box, it works and there are even (*spit*) GUI configurators for those who need them. Linux is never going to catch on as a desktop OS without those GUI configurators. MS Exchange, pile of steaming manure that it is, is so simple to install that a monkey could do it. OK, last I heard, the default Exchange install left it an open relay and you had to know about undocumented registry keys to prevent your Exchange server being relay-raped, but everyone wants simplicity of installation. Every so often, my boss (who has learned to hate all things from MS through bitter experience) moans about how long it takes us to figure out how to get something up and running and maybe we should switch all our servers to Windows. For the average company wanting their own mail server, it's cheaper to pay for Exchange with its bloated price and bloated per-seat licensing than to pay somebody to figure out how to install Linux, qmail, sqwebmail, etc. Total cost of ownership is a lot higher, but initial expenditure is lower and that's what usually counts. I see that qmail is falling in popularity simply because it is such a pain to learn how to install and configure to do what you want. It might be the fastest, it might be the most reliable, but the learning curve is a killer and the documentation is only slightly better than "read the source and figure it out for yourself". Add in the learning curves for sqwebmail, qmailadmin, vpopmail, etc., and the result is depressing. If you're a big ISP who has hit scaleability problems then the expenditure of learning qmail et al. is acceptable. If you're a small ISP you're going to stick with sendmail (or Exchange if you're a small ISP who has never heard of Linux). The bottom line is that the documentation MUST improve so that this stuff remains viable for even large ISPs, let alone small ones. I expect that Red Hat would produce nice GUI configurators for qmail, sqwebmail and the rest (going by Red Hat's recent performance they would be somewhat broken) if only DJB would be a little more flexible. I can understand why DJB wants to protect his reputation, especially in light of Red Hat's most recent cock-ups causing the Gtk team much undeserved criticism and hassle, but DJB's attitude will be the eventual death of qmail. :( What is needed for qmail to be viable in the long term is for Red Hat to pay DJB to produce RPMs for them that they promise not to tamper with in any way and to allow them to release RPMs containing the popular patches after he's vetted them and to have the install process explain that DJB vouches only for the unpatched version. > It could be only a few of us will work on it sporadically. And that's > ok too. The important thing is to get started on it. I was going to > fix some things for myself, and now I'm going to submit those fixes for > everyone else's benefit. It's how much of the code gets written in Free > and Open software. Someone who can, scratches an itch and makes it > available to everyone else. Hmmm, how about creating a CVS tree for the documentation. If there's no way of preventing documentation volunteers messing with the source tree then it might have to be a separate CVS. The overhead on the development team would then only be giving volunteers access to the documentation CVS and checking that submissions are close enough to being correct to be accepted. To kick if off, although it's not a vpopmail issue per se, I can document how to get sqwebmail and qmailadmin working on a server
[vchkpw] Re: "vpopmail documentation initiative"
Ron Guerin writes: > I don't think spending an evening wandering around Google and hitting > dead links is a substitute for proper documentation. I would agree there - googling is very much a last resort. And the whole point of open source is that we all put back in whatever way we can, so a collaberative documentation effort can pay dividends very quickly. I'd also say that "search the archives" is no substitute for a proper FAQ. I remember the days when newsgroups and mailing lists DID have FAQs. Then search engines came along and everybody saw them as a substitute for an FAQ. And for a few months people were correct. For a few months a google search would be just as quick and effective as a real FAQ. But after a couple of years, a google search is a complete pain. HUNDREDS of results pages with people asking the question you want answered and the response is invariably "do a google search of the archive." The original answer to that question is ZILLIONS of pages down the list and unless you have a few months to waste you'll never find it. "Search the archives" equates to "nobody can be bothered to maintain an FAQ because nobody has realized just how useless a google search is when dealing with a large archive where most questions are answered with 'search the archives.'" The qmail list is one of the worst I've seen for this. Yes, if you have a lot of time to spare you can eventually find the answer. But "search the archive" is never going to be as quick a solution as "the answer is in the FAQ." Time for some analysis here. Maintaining an FAQ takes time and effort, so it's very tempting to abandon it in favour of "search the archive." But searching the archive takes each of the HUNDREDS of us who are looking for an answer far more time and effort than it took somebody to maintain the FAQ. If one takes a naive view as an FAQ maintainer then it is obviously to the maintainer's benefit to tell people to search the archive. But unless the archive maintainer is an expert in EVERYTHING, he or she will eventually have to spend a LOT of time searching an archive about a completely different topic because the FAQ for that has also been abandoned. We're talking "iterated prisoner's dliemma" here. There is a cost to maintaining an FAQ but there is a much bigger cost to having to "search the archive" for the many other topics one does not understand fully. Mutual co-operation really does pay off... My apologies if I've offended anyone, but it's late, I've had a lot of wine, and I've wanted to get that one off my chest for well over three years. I even put my money where my mouth is. If there is an FAQ (on whatever) and I have something useful I submit it to the maintainer. But all too often the FAQ has been abandoned in favour of "search the archive." -- Paul Allen Softflare Support
[vchkpw] vpopmail, sqwebmail and maildrop[
Hi I'm trying to figure out how to get the new filter functionality in sqwemail (I have 3.5.3) working with vpopmail 5.3.23 (which I'm just about to install because I was using 5.2.1 until I found the authentication bug affecting courier-imap). I've searched mailing list archives, dug around on google, read the maildrop docs and still the solution eludes me. I can get it to work if I manually create a .qmail file in a user's maildir but that is not an option on a server which will eventually have many virtual domains each administered by the holders of those domains names and who can add users at will. It looks to me as if /etc/maildroprc might do the trick but unfortunately I cannot afford to play with anything that might cause mail to bounce because my pointy-haired boss decided to use his new personal domain as a test domain on this server and once it was able to send and receive mail he used it to subscribe to various mailing lists that generate hundreds of mails a day about his cherished hobby. Any solution must meet the following requirements: 1) Fully compatible with sqwebmail's filters. The whole point of trying to get maildrop to work is to allow the use of those filters. 2) Fully compatible with qmailadmin. It must not require tweaks to .qmail files that get undone when they are modified by qmailadmin. In particular, qmailadmin must be able to modify .qmail-default without disrupting filtering. 3) Does not require any manual intervention by me to enable filters for newly-added users. When a domain administrator adds a new user with qmailadmin then filters should automatically be available and should not require the administrator to request me to turn filtering on for a new user. These requirements do not seem unreasonable to me so I suspect that either vpopmail has yet to catch up with the new sqwebmail filters or I'm missing the blindingly obvious (almost certainly the latter). Any help would be greatly appreciated. -- Paul Allen Softflare Support
[vchkpw] Re: "vpopmail documentation initiative"
Adam Hooper writes: [FAQs] > But nobody wants to maintain it! I sure as hell don't, I find it > infuriating. None of the 5 other admins can be bothered with it either. > Users STILL use the faq all the time, with 6-month-old data, but nobody > wants to bother keeping it up to date, because it takes lots of > research, time and patience. Yep, it takes a lot of time and effort. But I know how much time and effort I spend trying to hunt down answers in google. It is a LOT. And it's a lot because usually there is no FAQ and I'm reduced to searching mailing lists. And invariably the search results are dominated by people asking the same question I am and being told to search the list. Which means there are a lot of people spending a lot of time googling mailing lists. > Worst of all, mailing-list questions don't disappear, they appear with > just the same regularity. Except now the key phrase is "search the faq." I go back to the days when "that is answered in the FAQ" was a standard reply. And the thing is, when somebody said that then the answer usually WAS in the FAQ and the person who asked the question could find the answer within seconds of being told to look at the FAQ. These days I have to search mailing lists and my experience is that it can take several hours to finally get an answer because I'm wading through all the "search the list" responses, stupid questions, stuff that matches the search criteria but isn't what I'm after, etc. If, instead, I came across an "it's in the FAQ" responses I'd immediately look in the FAQ. In fact, the chances are the google would throw up the FAQ ahead of the mailing list archives anyway. > Proper netizens are indeed grateful and spend time to offer suggestions, > but proper netizens can usually find most answers on Google anyway, so > they'd never ask the question in the first place! I consider myself a proper netizen, and reasonably skilled in setting search criteria, but it takes a LONG time to find some answers on google when you have to wade through mailing lists. > In brief, a FAQ does surprisingly little to quell mailing list/IRC/ > private email clutter. Then you misunderstand my point. I know that the "search the list" clutter will be replaced by "it's in the FAQ" clutter. But the former means I then spend hours wading through the clutter before I eventually get to the answer while the latter means I get the answer very quickly. I wasn't arguing for an FAQ to get rid of clutter but to allow people to find answers quickly. I know that doesn't help list subscribers avoid clutter but it does help everyone looking for answers. > To wrap up: In my experience, a FAQ is a f*cking pain. Good luck finding > somebody who'll want to put that amount of time and effort -- I know > I'll never do one again :). I agree, maintaining an FAQ is a pain. So is googling list archives where most questions are answered with "search the list." If there were more FAQs around I'd save enough time that I could afford the time to maintain an FAQ. -- Paul Allen Softflare Support
