Not receiving
I have several clients who say that they can send fine but when receiving is happening it hangs on the first one and then gives up the error number is 0x800ccc19 Does anyone know if there is a simple answer to this. Kind Regards Chris Chris Green www.activ8.com Tel: +44(0)1702-316-963 Fax: +44(0)1702-316-962
RE: Not receiving
That is an outlook express error and the problem is with whatever method they're using to check their email, either client or server-side. Either way, it's not qmailadmin related and we'd need far more information to diagnose the problem. Dave -Original Message- From: Activate [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 5:52 AM To: [EMAIL PROTECTED] Subject: Not receiving I have several clients who say that they can send fine but when receiving is happening it hangs on the first one and then gives up the error number is 0x800ccc19 Does anyone know if there is a simple answer to this. Kind Regards Chris Chris Green www.activ8.com Tel: +44(0)1702-316-963 Fax: +44(0)1702-316-962
Re: Not receiving
I have had this problem in the past. Some junk mail was in the mail queue for those users. I used Netscape to read their mail and then forwarded all but the bad message back to them. - Original Message - From: Hubbard, David [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 3:58 AM Subject: RE: Not receiving That is an outlook express error and the problem is with whatever method they're using to check their email, either client or server-side. Either way, it's not qmailadmin related and we'd need far more information to diagnose the problem. Dave -Original Message- From: Activate [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 5:52 AM To: [EMAIL PROTECTED] Subject: Not receiving I have several clients who say that they can send fine but when receiving is happening it hangs on the first one and then gives up the error number is 0x800ccc19 Does anyone know if there is a simple answer to this. Kind Regards Chris Chris Green www.activ8.com Tel: +44(0)1702-316-963 Fax: +44(0)1702-316-962
RE: qmailadmin 0.84 and vpopmail-5.0 patch
Seems like multiple admins in at the same time could result in collisions if they were changing the same thing at the same time, e.g. both are looking at the properties of one user and typing a new name or password, one hits submit, the update happens, the other hits submit, the first admin's changes are wiped out. There's lots of other scenarios there. Dave -Original Message- From: Bill Shupp [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 1:28 PM To: [EMAIL PROTECTED] Subject: Re: qmailadmin 0.84 and vpopmail-5.0 patch Ken, Just put up my 0.85: Now that you can have multiple administrators, you can also have different administrators logged in at the same time. Do you see this a problem? Cheers, Bill Shupp
Re: qmailadmin 0.84 and vpopmail-5.0 patch
on 9/26/01 12:31 PM, Hubbard, David at [EMAIL PROTECTED] spake: Seems like multiple admins in at the same time could result in collisions if they were changing the same thing at the same time, e.g. both are looking at the properties of one user and typing a new name or password, one hits submit, the update happens, the other hits submit, the first admin's changes are wiped out. There's lots of other scenarios there. While this is true, I think it would be rare. The vpopmail command line tools can be used by multiple administrators, and I've never had a problem (with as many as 4 administrators at one time). I'm not as concerned with people overwriting each others changes as I am vpasswd corruption, or exceeding qmailadmin user/forward/alias limits, etc. Regards, Bill
RE: qmailadmin 0.84 and vpopmail-5.0 patch
Bill Shupp wrote: While this is true, I think it would be rare. The vpopmail command line tools can be used by multiple administrators, and I've never had a problem (with as many as 4 administrators at one time). I'm not as concerned with people overwriting each others changes as I am vpasswd corruption, or exceeding qmailadmin user/forward/alias limits, etc. I'm assuming then that maybe one admin deleting a user and then another changing that user's password would not result in any problems other than an error about the user not being found or something? Thanks, Dave
Re: qmailadmin 0.84 and vpopmail-5.0 patch
on 9/26/01 12:54 PM, Casey Zacek at [EMAIL PROTECTED] spake: I was emailing back and forth with Gabriel Ambuehl about the no-forwarding-postmaster's-email topic, and I accidentally deleted the last one, but I believe the concensus was that deleting postmaster and making it just forward to another admin (or even non-admin) account is feasible because the only thing that relies on postmaster existing is the code to detect whether a domain is an alias or not, but that code is no longer needed (or something along those lines), so it should be ok to whack postmaster. Is that right, Gabriel? Qmailadmin already allows you to forward postmaster mail elsewhere, even to another account at the same domain. Bill
Re: qmailadmin 0.84 and vpopmail-5.0 patch
on 9/26/01 2:24 PM, Brad Dameron at [EMAIL PROTECTED] spake: Bill, One issue I might see is users being able to add more than their limit. Based on what I see in the code it loads the limits when it first opens and checks to see how many of each already exhist but doesn't check again until the refresh is clicked. Maybe add in some checking to see how many exhist every time a screen is displayed? I already fixed that for a different reason. Some people had trouble with caching. So, I added an additional check on limits when the addition of a user/alias/forward/robot/list at the beginning of the appropriate add..now function. Before, the checks were only done when you brought up the add screen. Now it does it before the add screen and just before the adding takes place. But with multiple administrators, I could see the slim possibility of going one over the limit if the additions happen closely enough. But I can't imagine it being any worse than that. Regards, Bill Shupp
non-postmaster administrators
Now that the multiple administrator idea is integrated, seems to me the next logical step would be to allow the postmaster (and other admins?) the right to grant admin privileges to others. What do you folks think? Should this be the function only of the system administrator? Or maybe an option in the qmailadmin-limits file so that it's turned off by default, but can be turned on on a per domain basis? Cheers, Bill Shupp
Re: non-postmaster administrators
Hubbard, David spoke forth with the blessed manuscript: If anything, I'd like that as a configurable option on a per-domain basis. I fully agree there. -Original Message- From: Bill Shupp [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 5:59 PM Subject: non-postmaster administrators Now that the multiple administrator idea is integrated, seems to me the next logical step would be to allow the postmaster (and other admins?) the right to grant admin privileges to others. What do you folks think? Should this be the function only of the system administrator? Or maybe an option in the qmailadmin-limits file so that it's turned off by default, but can be turned on on a per domain basis? -- -- Casey Zacek Senior Staff Engineer NeoSpire, Inc.
Autorespond 2.0.
Anyone have any additions they want to see in the new autorespond or any bugs? --- Brad Dameron Network Account Executive TSCNet Inc. www.tscnet.com Silverdale, WA. 1-888-8TSCNET
Re: Re[2]: qmailadmin 0.84 and vpopmail-5.0 patch
On Wed, 2001-09-26 at 14:13, Gabriel Ambuehl wrote: -BEGIN PGP SIGNED MESSAGE- Hello Casey, Wednesday, September 26, 2001, 7:54:25 PM, you wrote: Not only that, but (at least for me) it's really up to the customer, and the customers want this ability, so I'm very glad it's there. Trust me, you really DON'T want to have multiple administrators messing with the data at the same time as the number of problems resulting from this kind of stuff is indefinite. It's hard enough to get RDBMS backed solutions working correctly over the web and the vast majority of code which is marketed as multi user capable really breaks if two people are operating on the same sets of data at the same time. The only thing that could be done in a halfway safe way (i.e. user can at most destroy his own account which the admin can fix afterward) is to allow NORMAL users to change their pws while someone else is working with the system. I disagree. The RFC's state that email domains should accept email to postmaster. It doesn't state that postmaster has to be a pop account. One problem with having postmaster as a pop account, for some sites, is no one ever checks the postmaster email. They only check thier email accounts. So for those sites it would be better to not have postmaster as a pop account, and instead forward the postmaster email to the real pop account of the primary user. With the above type of setup, it would be very nice to allow that primary user to be the domain admin. Sites that would have multiple administrators changing email passwords, and hence create problems, can just not use this feature. I was emailing back and forth with Gabriel Ambuehl about the no-forwarding-postmaster's-email topic, and I accidentally deleted the last one, but I believe the concensus was that deleting postmaster and making it just forward to another admin (or even non-admin) account is feasible because the only thing that relies on postmaster existing is the code to detect whether a domain is an alias or not, but that code is no longer needed (or something along those lines), so it should be ok to whack postmaster. Is that right, Gabriel? With the new feature that Bill Shupp added, you can go ahead and delete the postmaster account and setup another user to be the admin. Then forward the postmaster email to an email address. It basically says what I said. AFAIK, the code I was referring to isn't yet integrated so it is safe to delete the postmasters and AFAIK it's still allowed in the pre5 and perhaps always will be although I still think is a bad thing TM. Ken if Bill may introduce new features before 5.0 is released, couldn't you introduce my patch too (cause I'm building some code that relies on some form (I don't care too much which one) of vaddaliasdomain() being present)? I think we are going to stick with the current domain alias code. It was there in the old 4.9 version and the early 4.10 versions and tested to work fine. It got removed from the later 4.10 version when we completely rewrote the code. I then added it back into the 5.0pre releases and it seems to be working fine. Adding in your changes could possibly break things, and break current sites, and would require more testing than I care to do. So unless there is an overwhelming reason from folks to use your code, I think we will stick with the current alias code. I'm sorry you are building code that relies on your changes. perhaps you can modify your code to use the alias code in the current 5.0pre releases. Ken Jones
