Re: Suspending an POP3 account.
Changing permissions can be quite messy. Imagine where you have to do it for 1000 or more then when they pay you change them allover again. Best is to change authentication method from passwd file to database. The default tables have a suspend colum... Joe. - Original Message - From: Reid Sutherland [EMAIL PROTECTED] To: Joshua Nichols [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 3:48 AM Subject: Re: Suspending an POP3 account. (lack of payment) clients when using a passwd/shadow authentication method. Any ideas on a solution? Though different checkpassword and pop programs will handle the problem differently, changing the _permissions_ on the ~Maildir/* so the owner doesn't have read access will work. That is, typical Maildir perms are 700, change it to 300. All mail will be delivered as usual, but the pop account will not work. If the user has telnet access, they will be able to circumvent this, but in a situation where you have expiring pop accounts, I'm assuming they don't. I imagine you could easily set the return error so that the user's mta tells them they're delinquent. It's not everyday the problem is a permission denied read on the Maildir. This sounds really good too. This will give them a more descriptive error instead of password error as suggested before. A password error will often simply mean that and end up confusing the client in most cases. But a permission denied error could result in them thinking, 'Hey, maybe I should pay my bill on time next time'. Thanks for the tip. -reid
Re: Suspending an POP3 account.
On Wed, Jun 13, 2001 at 09:42:04AM +0300, Joe allegedly wrote: Changing permissions can be quite messy. Imagine where you have to do it for 1000 or more then when they pay you change them allover again. Best is to change authentication method from passwd file to database. The default tables have a suspend colum... Well, lemme see now... You have to have a process that creates a user, yes? That (at least) entails making some file system entries and setting the permissions appropriately. And you have to have a process that removes a user, after all, users do disappear, yes? That (at least) entails removing some file system entries. And so now we have this disable process, yes? And you're saying it's messy because that involves changes to the file system? That doesn't follow. Changing user states intimately involves the file system. I think that diddling with an authentication mechanism has the downside of giving very poor feedback to the user. Pop clients notoriously mask error messages and an incorrect password message will rarely be interpreted by the user as an I haven't paid my bill message. It certainly won't be interpreted by the POP client that way. I still think a good method is to rename the Maildir and create a temporary Maildir with an single mail that tells them precisely what the problem is. If you have to touch the file system this is no big deal and the resultant message to the user - if worded correctly - will not be vulnerable to misinterpretation. Regards. Joe. - Original Message - From: Reid Sutherland [EMAIL PROTECTED] To: Joshua Nichols [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 3:48 AM Subject: Re: Suspending an POP3 account. (lack of payment) clients when using a passwd/shadow authentication method. Any ideas on a solution? Though different checkpassword and pop programs will handle the problem differently, changing the _permissions_ on the ~Maildir/* so the owner doesn't have read access will work. That is, typical Maildir perms are 700, change it to 300. All mail will be delivered as usual, but the pop account will not work. If the user has telnet access, they will be able to circumvent this, but in a situation where you have expiring pop accounts, I'm assuming they don't. I imagine you could easily set the return error so that the user's mta tells them they're delinquent. It's not everyday the problem is a permission denied read on the Maildir. This sounds really good too. This will give them a more descriptive error instead of password error as suggested before. A password error will often simply mean that and end up confusing the client in most cases. But a permission denied error could result in them thinking, 'Hey, maybe I should pay my bill on time next time'. Thanks for the tip. -reid
RE: Suspending an POP3 account.
Didn't you all ever read the manpage for passwd? From the refered manpage: Account maintenance User accounts may be locked and unlocked with the -l and -u flags. The -l option disables an account by changing the password to a value which matches no possible encrypted value. The -u option re-enables an account by changing the password back to its previous value. The account status may be given with the -S option. The status information consists of 6 parts. The first part indicates if the user account is locked (L), has no pass- word (NP), or has a usable password (P). The second part gives the date of the last password change. The next four parts are the minimum age, maximum age, warning period, and inactivity period for the password. Just a classic case of RTFM. THAT won't just work for OpenBSD. I'd rather edit the shadow file for locking up users. And besides, what usermod does in Linux is exactly this: put an ! just before encrypted password in shadow.
Re: Suspending an POP3 account.
On Tue, Jun 12, 2001 at 10:19:33AM -0300, Fernando Braga wrote: THAT won't just work for OpenBSD. I'd rather edit the shadow file for locking up users. And besides, what usermod does in Linux is exactly this: put an ! just before encrypted password in shadow. BSD systems don't work with shadow passwords. They are using password databases (/etc/pwd.db). The master file is /etc/master.passwd I'd just run vipw and put a ! before the users password. -- * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * * Roedingsmarkt 14, 20459 Hamburg, Germany * Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Suspending an POP3 account.
Hi, I'd like to be able to suspend a POP3 account without changing the client's password. Is there anything I can do to the home directory or Maildir to accomplish this? What I'm doing the for incoming mail is a simple .qmail file that creates a message and spits back an error saying the account is suspended (sort of like a vacation program). So I want to make sure the .qmail is usable but also prevent the client from logging in via POP3. I've attempted changing the ownership of the Maildir to someone else, but that didn't work and only defered incoming messages. Most likely I'll have to store password somewhere and replace it in the shadow file with a 'x' when suspended, and put the crypt password back once the account is restored. I think this advice might come in handy for someone handling delinquent (lack of payment) clients when using a passwd/shadow authentication method. Any ideas on a solution? -reid
Re: Suspending an POP3 account.
On Mon, Jun 11, 2001 at 05:58:19PM -0400, Reid Sutherland allegedly wrote: Hi, I'd like to be able to suspend a POP3 account without changing the client's password. Is there anything I can do to the home directory or Maildir to accomplish this? What I'm doing the for incoming mail is a simple .qmail file that creates a message and spits back an error saying the account is suspended (sort of like a vacation program). So I want to make sure the .qmail is usable but also prevent the client from logging in via POP3. I've attempted changing the ownership of the Maildir to someone else, but that didn't work and only defered incoming messages. Do you still want incoming mail delivered for such accounts? If so, the easiest thing to do is change the name of Maildir to, say, Maildir.suspended and then in the .qmail file go: ./Maildir.suspended/ | bouncesaying Account suspended When they become active again, remove the .qmail file and rename Maildir.suspended back to Maildir. Don't forget the chmod +t $HOME to defer any deliveries while you are making these changes. If you do not want the incoming mail delivered, then a permission change plus a .qmail file that only generates a bounce message is fine. Mind you, the POP error message they get wont be very friendly and maybe that's the intent. If it's not, you could additionally create a hand-crafted Maildir that has just one message in it regarding the suspension. Regards.
RE: Suspending an POP3 account.
(lack of payment) clients when using a passwd/shadow authentication method. Any ideas on a solution? Though different checkpassword and pop programs will handle the problem differently, changing the _permissions_ on the ~Maildir/* so the owner doesn't have read access will work. That is, typical Maildir perms are 700, change it to 300. All mail will be delivered as usual, but the pop account will not work. If the user has telnet access, they will be able to circumvent this, but in a situation where you have expiring pop accounts, I'm assuming they don't. I imagine you could easily set the return error so that the user's mta tells them they're delinquent. It's not everyday the problem is a permission denied read on the Maildir. --joshua.
Re: Suspending an POP3 account.
On Mon, Jun 11, 2001 at 05:58:19PM -0400, Reid Sutherland allegedly wrote: Hi, I'd like to be able to suspend a POP3 account without changing the client's password. Is there anything I can do to the home directory or Maildir to accomplish this? What I'm doing the for incoming mail is a simple .qmail file that creates a message and spits back an error saying the account is suspended (sort of like a vacation program). So I want to make sure the .qmail is usable but also prevent the client from logging in via POP3. I've attempted changing the ownership of the Maildir to someone else, but that didn't work and only defered incoming messages. Do you still want incoming mail delivered for such accounts? No. It's as if the account is dead, but the username is kept active. I've already created a .qmail that produces a bounce. If so, the easiest thing to do is change the name of Maildir to, say, Maildir.suspended and then in the .qmail file go: ./Maildir.suspended/ | bouncesaying Account suspended When they become active again, remove the .qmail file and rename Maildir.suspended back to Maildir. Don't forget the chmod +t $HOME to defer any deliveries while you are making these changes. If you do not want the incoming mail delivered, then a permission change plus a .qmail file that only generates a bounce message is fine. Mind you, the POP error message they get wont be very friendly and maybe that's the intent. If it's not, you could additionally create a hand-crafted Maildir that has just one message in it regarding the suspension. I've attempted a permission change on the Maildir, but then it won't run the program in the .qmail file. So to sum this up, I want to prevent both POP3 login and SMTP delivery, and I've already done the SMTP prevention. -reid
Re: Suspending an POP3 account.
Reid Sutherland [EMAIL PROTECTED] writes: [...] Most likely I'll have to store password somewhere and replace it in the shadow file with a 'x' when suspended, and put the crypt password back once the account is restored. Not qmail related, but a trick I like to use is to just prepend *LOCK* to their crypted password entry. Then to restore the account and put the correct crypted password back, you just remove *LOCK*. For example, if I have sgifford:abc12345: in /etc/shadow, it becomes sgifford:*LOCK*abc12345: That solves the problem of where to put the password, but maybe there is a more elegant qmail-based solution. Good luck, -ScottG.
Re: Suspending an POP3 account.
Reid Sutherland [EMAIL PROTECTED] writes: [...] Most likely I'll have to store password somewhere and replace it in the shadow file with a 'x' when suspended, and put the crypt password back once the account is restored. Not qmail related, but a trick I like to use is to just prepend *LOCK* to their crypted password entry. Then to restore the account and put the correct crypted password back, you just remove *LOCK*. For example, if I have sgifford:abc12345: in /etc/shadow, it becomes sgifford:*LOCK*abc12345: That solves the problem of where to put the password, but maybe there is a more elegant qmail-based solution. Good call, this is the most viable solution so far. I think it's the best way IMHO. -reid
Re: Suspending an POP3 account.
(lack of payment) clients when using a passwd/shadow authentication method. Any ideas on a solution? Though different checkpassword and pop programs will handle the problem differently, changing the _permissions_ on the ~Maildir/* so the owner doesn't have read access will work. That is, typical Maildir perms are 700, change it to 300. All mail will be delivered as usual, but the pop account will not work. If the user has telnet access, they will be able to circumvent this, but in a situation where you have expiring pop accounts, I'm assuming they don't. I imagine you could easily set the return error so that the user's mta tells them they're delinquent. It's not everyday the problem is a permission denied read on the Maildir. This sounds really good too. This will give them a more descriptive error instead of password error as suggested before. A password error will often simply mean that and end up confusing the client in most cases. But a permission denied error could result in them thinking, 'Hey, maybe I should pay my bill on time next time'. Thanks for the tip. -reid
Re: Suspending an POP3 account.
I've attempted a permission change on the Maildir, but then it won't run the program in the .qmail file. That's not how it works. There must be something else you've done. Did you change the permissions on the home directory as well? How about the .qmail file? Show us the exact error message in the log that tells you that it won't run the program in the .qmail file. Also, show us the contents and permission of the .qmail file. Regards.
Re: Suspending an POP3 account.
On Mon, 11 Jun 2001, Reid Sutherland wrote: For example, if I have sgifford:abc12345: in /etc/shadow, it becomes sgifford:*LOCK*abc12345: That solves the problem of where to put the password, but maybe there is a more elegant qmail-based solution. Good call, this is the most viable solution so far. I think it's the best way IMHO. Didn't you all ever read the manpage for passwd? From the refered manpage: Account maintenance User accounts may be locked and unlocked with the -l and -u flags. The -l option disables an account by changing the password to a value which matches no possible encrypted value. The -u option re-enables an account by changing the password back to its previous value. The account status may be given with the -S option. The status information consists of 6 parts. The first part indicates if the user account is locked (L), has no pass- word (NP), or has a usable password (P). The second part gives the date of the last password change. The next four parts are the minimum age, maximum age, warning period, and inactivity period for the password. Just a classic case of RTFM. -- Antonio Dias
Re: Suspending an POP3 account.
On Tue, Jun 12, 2001 at 12:36:48AM -0300, Antonio Dias wrote: Just a classic case of RTFM. Yeah, and you better read very closely too, because these commands don't work across all platforms. (Case in point, solaris 8 doesn't support passwd -u) --Adam
