When account expires user still receives email
 

I have made a 'discovery' in that when a useraccount's password expires (8th field in the /etc/shadow file) he still receives emails into his mailbox. I tried to delete the mailbox, and sent an email to this user, and he still recieves email (of course i can read it because I am root on the mail server) - so the system creates again a mailbox for this user. So apparently although the password expires, the account is still active.

:scratch:

The brute force method for this would be to delete the user manually (userdel) but I've discovered that I can use the "-f(number_of_days)" flag in the useradd/usermod which will disable the account (and therefore i presume that no more mails can enter the mailbox of that user) after "number_of_days" from the expiration of the password... So I modified this user's account using "usermod -f0" to disable the account as soon as the password expires. (The password was already expired.) The result? The user still receives email!! :cry:

So I must presume that the effect of disabling the account takes places not when the password already expires, but when it is going to be expired. So I ask now, how can I introduce the policy for all ALREADY-EXPIRED users in my mail server such that their account be disabled?

Also, when their account is disabled (because i'm not 100% sure of it), this implies that their entries from /etc/passwd and shadow removed or that their /home directory is removed? :Pengy:

The user will still recieve emails, unless you completely remove the account. The basic reason for this is simple. Disabling a password (which is what happens when the password expires, or you manually disable the account) only disables the user's ability to use thier account. They'll still recieve mail, any system wide user account updates, and so on.

Why doesn't the account just stop doing everything? Because that would make the average sysadmin's job a lot harder. For one thing, the same process that is used to disable or expire an account is the same one that kicks in when the user mistypes there password a given amount of times.

Imagine what would happen if someone changed their password, then forgot what it was, or kept typing the old one in until the account disabled itself. Then, they call the help desk for a new password, or to get the account unlocked. In the meantime, their supervisor, a customer, or someone else sent them an important email, or something was installed/upgraded. If that account were disabled in the manner you suggest, the problems would be horrendous. How do you recover a tossed email? How would you like to have to run the update or install again because one person made a mistake? Even better, how would you like to rebuild a user's directory, because you disabled it while they were away on vacation, and in doing so, it removed their /home directory?

For these reasons, a disabled account acts like a normal one, with the exception that noone can log in. To stop a user from getting mail, remove that user from your mail server setup. Of course, that has its own downsides, if you intend to reinstate the user at another time.

after reading your explanation, now i ended in more doubt and cannot see the actual difference between the 7th and 8th field of the /etc/shadow file. I mean, what's the difference between the password having expired, and the account being disabled (by the -f flag)?

by the way, I wrote a script which removes mailboxes if a users account expired by 200 days. This will avoid the mail server from growing by these expired accounts which will continue to receive mails from spammers/mailing lists... I've removed 13GB of data, imagine that!! But incidentally today i've noticed that although i removed their mailbox, these expired accounts still kept receiving mail... that's my whole point of removing them permanently.

Disabled accounts are accounts that the Admin is taking out of service. Vacations, employees leaving, and so on are why you'd disable an account. Basically, you're disabling them to restore them or have access to them later. The vacation example is obvious. You don't want to leave an unused account available to a hacker, especially if the user is unlikely to notice login times. Another example for disabled accounts would be when an employee leaves a company. An employee that's let go obviously shouldn't retain rights to that account, but even employees that go peacefully should have their accounts disabled. You don't want to delete them, because you'll likely transfer them to whoever takes over their job later on.

Expired accounts are different, simply because they are a more automatic event. If a user ignores the prompts to choose a new password every so often, that user is locked out of their account until they talk to an administrator. This could be the same as a disabled account, but it's nice to have a difference. This way, the system can notify you if someone lets this happen. If nothing else, it can warn you that they are going to call. Also, you can set this to be logged, so that if it happens repeatedly (someone stubborn), you have a record with which to let thier surpervisor deal with the problem. In some places, people get fired or probationary measures for letting their passwords expire.

Another reason to have two different fields is to let you, as admin, tell the difference between the two. Otherwise, you might accidently unlock a disabled account, instead of one that expired. Lastly, having expired as a different value is a good way to remind you if someone leaves, and you're not notified of it.

In short, there are differences, but their usefulness depends on how tightly you control your user's passwords and account access. It's nice to have the ability to use both, in any case.