Sorry for the delay. Not only did we have to get PM to agree to letting us post this description, but I had to get over the jet lag returning from the US!
A user with mboxadmin capability can log in as any other user simply by using a magic username that indicates that he or she wants to exercise that privilege. For example, suppose "Mr Superman" wants to log in as "Mr Minion" then the IMAP conversation would go like this:
Code: Select all
1 LOGIN "mboxadmin:Mr Superman:Mr Minion" "superpassword"
where "superpassword" is Mr Superman's password. If Mr Superman wants to exercise his powers, his mboxadmin capability, using, for example, Thunderbird, then he sets up an account in Thunderbird and uses "mboxadmin:Mr Superman:Mr Minion" as his username and provides his own password, "superpassword", when prompted.
This is not like delegate access where Mr Superman is granted permission to see Mr Minion's mail, it's a lot less subtle than that: Mr Superman assumes the identity of Mr Minion and, as far as the IMAP server any anything else is concerned it's Mr Minion that has logged in. However, it is possible to tell that Mr Superman has been using his mboxadmin capability if auditing for the IMAP server is turned on (eg "omconfaud -a imap 9"). For example, on my machine where I've created users called Mr Superman, Mr Normal and Mr Minion I get this in the audit log (~/logs/audit, where "~" is usually /var/opt/scalix):
Code: Select all
user-signon
time 1141852352 Wed Mar 8 13:12:32 2006 -480
user-agent-id IMAP4 Server 10.1.0.060307-jch
client-type 14
client-ip 10.17.64.142
user 115 Mr Minion/sheep/CN=Mr Minion 36011 36011
mboxadmin-authenticator 114 Mr Superman/sheep/CN=Mr Superman
signon-status 0
Of course, because Mr Superman has assumed the identity of Mr Minion, the corresponding user-signoff record looks like this:
Code: Select all
user-signoff
time 1141852540 Wed Mar 8 13:15:40 2006 -480
user 115 Mr Minion/sheep/CN=Mr Minion
duration 193
signoff-status 0
Now, if Mr Normal was watching over Mr Superman's shoulder and thinks that this mboxadmin stuff is really great and he'd like to read Mr Minion's email as well, he'll attempt to log in using the username "mboxadmin:Mr Normal:Mr Minion" but he'll fail and we'll get this record in the audit log:
Code: Select all
user-signon
time 1141852713 Wed Mar 8 13:18:33 2006 -480
user-agent-id IMAP4 Server 10.1.0.060307-jch
client-type 14
client-ip 10.17.64.142
user 0 mboxadmin:Mr Normal:Mr Minion root 0
signon-status 655
Since Mr Normal doesn't have mboxadmin capability, the IMAP server doesn't even look at the special syntax for the login name and we'll get a login failure that corresponds to an unknown user (Mr Normal will just get the usual "your username or password is wrong" message).
One possible use for mboxadmin is not so much for Mr Superman to keep an eye on Mr Minion, but for Mr Superman to have, for example, a script to dump the contents of Mr Minion's junk mail folder so that he can use it to teach spamassassin. This is quite easy using a Scalix program called authnc:
Code: Select all
authnc --authid "mboxadmin:Mr Superman:Mr Minion" \
--secret "superpassword" \
scalix-server.example.com imap <<@@@@
1 select "Junk"
2 fetch 1:* rfc822.peek
3 logout
@@@@
I like authnc a lot (though I'm biased, I wrote it). It's a useful program for signing on to IMAP without having to go through the tedious business of typing a login line, or, as in this example, reading base64 encoded DIGEST-MD5 challenges and typing base64 encoded responses. I'm afraid I didn't write a manual page for authnc, but "authnc --help" will tell you pretty much all you need to know.
There is a more serious use for authnc though. If you're set up to use Kerberos then you can modify your script so that it doesn't include a password, instead it uses your Kerberos credentials to authenticate. However, since having a Kerberos principal called "mboxadmin:Mr Superman:Mr Minion" is going to be a little tedious, not to mention impractical for reading everyone else's junk mail folder, there's an alternative mechanism:
Code: Select all
authnc --mechanism gssapi \
--authzid "mboxadmin:Mr Minion" \
scalix-server.example.com imap <<@@@@
1 select "Junk"
2 fetch 1:* rfc822.peek
3 logout
@@@@
The audit record for this type of access is exactly the same as before. When Mr Normal tries this form of authentiation he is going to be in for a surprise when he tries this command. The surprise is that he logs in, but because he doesn't have mboxadmin capability, the IMAP server completely ignores the authorization identity (provided by the "--authzid" option) and just uses Mr Normal's own identity to log in. The reason for this apparently differing behaviour is that the IMAP server wants to remain consistent: random login names cause login failure and authorization identities are normally ignored.
There's just two more thing to cover: account locking and IMAP referrals. These are both affected by the difference between establishing an identity and allowing someone access to the server. I know it can be confusing, so pay attention:
Account locking is easy: the check to see if a user's account is locked occurs
after the user's identity has been confirmed. For mboxadmin logins, the users identity is asserted by the mboxadmin user so the normal account locking checks happen with the victim's account so if an account is locked (eg with "ommodu -K") or his password has expired then the Mr Superman will not be able to log in. On the other hand, password locking ("ommodu --lock-password") prevents a user asserting his identity and so that won't stop Mr Superman logging in.
Referrals are slightly more complex: when you're logging in as an mboxadmin user there are two possibilities for a referral: the mboxadmin user name and the "victim" user name. For the first form of mboxadmin login, where you use a modified username, you'll get a referral for a non-local user if you have mboxadmin capabilities on the server you're connecting to. If you're using the second form of mboxadmin login then you have the possibility of two referrals -- one for the mboxadmin user and then, when you connect to the right host for the mboxadmin user, another referral for the victim. This is a bit circular, but the practical upshot is that you must have the mboxadmin capability on the machine you want to connect to: the mboxadmin capability doesn't transfer from machine to machine.
Any questions?
jch