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
> >
> >
> >
>
