How do Community Edition users find out about mboxadmin

[cjwilber]

I guess the Subject says it all really.
In order to have some scripts learn spam and ham overnight, I really want to be able to iterate through every users mailbox and learn from spam and ham folders.
I have modified a simple perl script (posted elsewhere on this forum) that allows me to do this for a single user, but I would like to be able to run it for all users. I think the way to do this is with an mboxadmin account, but the details appear to be a closely guarded secret.
Can anyone provide advise on how to achieve this?

[mephisto]

I second that question.

[kanderson]

There is some documentation on how it's done in the Exchange migration guide. You use that mechanism so you can sign in once and log in as any user on the system.

Historically, it's been a bit hush hush because it allows for a violation of European Privacy laws, if I remember correctly.

Kev.

[mephisto]

I can't find anything about the specific mechanism you mentioned, just how to assign mboadmin permissions to a user.

[cjwilber]

I can see how to give a user mboxadmin privileges from the guide, but not how to use them from command line.
so I know that I give mbox admin rights using ommodu.
The only guide I can find shows the use of tools for migrating users from Exchange but nothing on how one actually uses the user with mboxadmin rights from a unix command line (and hence scriptable) to access various users mailboxes.
Maybe it is as simple as specifying the folder name somehow using the various users' userids too when logged in to an imap session using the mboxadmin user e.g. for user bill then look for folder bill.INBOX
I am still stuck ;-)

[cjwilber]

I can't find anything about the specific mechanism you mentioned, just how to assign mboadmin permissions to a user.

Glad it's not just me :?

[cjwilber]

There are some interesting fields in the capability response:
X-DELEGATE
X-SCALIX-1
X-SCALIX-2
X-SCALIX-3
X-SCALIX-4
I am guessing that X-DELEGATE is something to do with this.

Can anyone from Scalix give advise?

[aniewels]

Would like to have that info too :)

[cjwilber]

Can someone from Scalix at least make a definitive statement one way or the other i.e. if we aren't allowed to have this information unless we are licensed users, then just say so.
Thanks in advance.

[ScalixSupport]

A reply will be made shortly. We needed to make certain that product management were OK with us passing on the information. There are some caveats to using the login that we need to make sure we've documented correctly.

Cheers

Dave

[isyseng]

Any progress on this documentation?

Thanks so much.

[jch]

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

[cjwilber]

Excellent. Thanks very much for this. I now have all my mailboxes being scanned.
I found the following command option to get a list of mailbox login ids.
omshowu -m all -i
The -i option isn't well documented - it is shown in the omshowu man page as an option but with no description of what it does. it seems to do what I want here, which is to provide a list of login id's which can then be fed to a script.

On another thread:
http://www.scalix.com/community/viewtop ... t=bayesian
I modified a perl script for running against Ham and Spam boxes. I call it spamlearner.pl, so calling that with as follows runs through all spam and ham and feeds it to bayes:

for user in `omshowu -m all -i`; do /usr/local/bin/spamlearner.pl localhost mboxadmin:sxadmin:$user Spam INBOX password; done

Hope this helps some other people

[mephisto]

for user in `omshowu -m all -i`; do /usr/local/bin/spamlearner.pl localhost mboxadmin:sxadmin:$user Spam INBOX password; done

I have a similar solution but chose to include the password into the perl script. If you have it in the command line, then you have a security risk, because it shows up in your task list.

[cjwilber]

Thanks for catching that oversight. I'll modify the perl script to include this cycling through the users.

If anyone wants a copy of the script, let me know and I'll post the updated version here.