Grant Full Control to a user’s mailbox in Exchange 2010

To grant full control to a diffrent user’s mailbox in Exchange 2010, you will need to use the Microsoft Exchange Management Console.  After this change has been made, have the user close Outlook and reopen it, the mailbox should show in the left hand side, without you having to manually add it to Outlook.

Below will allow another user to ‘Send As’ the first user and read/modify the their mail.

  1. Open the Exchange Management Console
  2. Expand “Recipient Configuration
  3. Right mouse click on “Mailbox” and choose find from the list.
  4. Find the user you would like to grant permissions for (ie: the mailbox of the user who will have the messages sent at).
  5. Right mouse click on the user and choose “Manage Full Access Permissions
  6. Add the user who will be able to send as the first user to this list.
The mailbox should automatically now show in Outlook after it has been restarted.

Dovecot v2.1+ Statistics

There are different “zoom levels” you may use to view the following statistics:

  • command: Per-IMAP command
  • session: Per IMAP/POP3 connection
  • user: Per user (all of user’s sessions summed up)
  • domain: Per domain (all of domain’s users summed up)
  • ip: Per IP address (all sessions from the IP summed up)

Basic Configuration

mail_plugins = $mail_plugins stats
protocol imap {
  mail_plugins = $mail_plugins imap_stats
plugin {
  # how often to session statistics
  stats_refresh = 30 secs
  # track per-IMAP command statistics
  stats_track_cmds = yes

You’ll also need to give enough permissions for mail processes to be able to write to stats-mail fifo. For example if you use a single “vmail” user for mail access:

service stats {
  fifo_listener stats-mail {
    user = vmail
    mode = 0600

Statistics gathered

Statistics gathered using the getrusage() system call:

  • user_cpu: User CPU (seconds.microseconds)
  • sys_cpu: System CPU (seconds.microseconds)
  • min_faults: Minor page faults (page reclaims)
  • maj_faults: Major page faults
  • vol_cs: Voluntary context switches
  • invol_cs: Involuntary context switches
  • disk_input: Number of bytes read from disk
  • disk_output: Number of bytes written to disk

The disk_input and disk_output attempt to count the actual read/write bytes to physical disk, so e.g. reads from OS’s cache aren’t counted. Note that not all operating systems and filesystem support this, instead they simply show these values always as 0.

Statistics gathered by Dovecot’s lib-storage internally:

  • lookup_path: Number of open() and stat() calls (i.e. “path lookups”)
  • lookup_attr: Number of stat() and fstat() calls
  • read_count: Number of read() calls for message data (e.g. index files not counted)
  • read_bytes: Number of message bytes read()
  • cache_hits: Number of cache hits from dovecot.index.cache file

Outlook crashes when printing

Outlook keeps its printing style settings in a file called OutlPrnt. You can run into several issues like these hangs and crashes when the file gets corrupted. On multiple occasions I’ve also seen messages been printed in right-to-left format instead of left-to-right due to OutlPrnt corruptions.

You can recover from this by renaming the OutlPrnt file to .old when Outlook is closed. You can find the file here;
Windows Vista and Windows 7


Windows XP

C:\Documents and Settings\%username%\Application Data\Microsoft\Outlook\

Active Directory Saved Queries

Locked Out Users


Dial In Access


Disabled User Accounts


No Expiring Accounts


Active Accounts


Hidden Mailboxes


Configuring Spamassassin (MySQL & Virtual Users)

With this setup you will be saving the user preferences and bayes tokens in a MySQL data source. But, while scanning a message if spamd is unable to connect to the server specified in user_scores_dsn (below) or an error occurs when querying the SQL server then spam checking will not be performed on that message.

First we need to build the database table. You may download mine below.

Then import the file into the spamassassin table on your MySQL server.

mysql -h localhost -u postfix -ppostfix spamassassin < Spamassassin.sql
mysql -h localhost -u postfix -ppostfix spamassassin < Spamassassin_userpref.sql

To set the version number in the database, run the following.

echo "INSERT INTO bayes_global_vars VALUES ('VERSION','3');" |mysql -u postfix -ppostfix spamassassin
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'required_score', '5.0', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'rewrite_header Subject', '[SPAM]', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'rewrite_header Subject', '1', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'report_safe', '1', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'trusted_networks', '', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'use_bayes', '1', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'bayes_auto_learn', '1', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'skip_rbl_checks', '0', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'use_razor2', '1', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'use_pyzor', '1', NULL);
INSERT INTO userpref (username, preference, value, prefid) VALUES ('@GLOBAL',  'ok_locales', '1', NULL);

Now setup the configuration.

  • /etc/mail/spamassassin/
required_score                  5.0
rewrite_header Subject          [SPAM]
report_safe                     1
use_bayes                       1
bayes_auto_learn                1
skip_rbl_checks                 0
use_razor2                      1
use_pyzor                       1
ok_languages                    enrewrite_header Subject
user_scores_dsn                 DBI:mysql:spamassassin:localhost
user_scores_sql_username        postfix
user_scores_sql_password        postfix
auto_whitelist_factory          Mail::SpamAssassin::SQLBasedAddrList
user_awl_dsn                    DBI:mysql:spamassassin:localhost
user_awl_sql_table              awl
user_awl_sql_username           postfix
user_awl_sql_password           postfix
bayes_store_module              Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn                   DBI:mysql:spamassassin:localhost
bayes_sql_username              postfix
bayes_sql_password              postfix

The spamd server will not pay attention to SQL preferences by default, even with user_scores_dsn set in the config files. You must startup spamd with the proper options (ie -q or -Q). If the user_scores_dsn option does not exist, SpamAssassin will not attempt to use SQL for retrieving users’ preferences.

SpamAssassin needs to be ran with the options similar to this:

/usr/bin/spamd -d -x -q -Q -u nobody -r /var/run/

I believe the best way of doing this is modify your /etc/init.d/spamassassin init file and change SPAMDOPTIONS to:

SPAMDOPTIONS="-d -m5 -x -q -Q -u nobody"

make sure /etc/sysconfig/spamassassin dosn’t override your settings run the below command to confirm spamassassin is running correctly

ps -eaf |grep spamd

Run a Secure git Repository on FreeNAS

Running a secure git repository on FreeNAS is pretty straight forward, once you understand what your trying to do.  If you have looked over my previous post “Creating a secure Git repository server” you understand that all you really need to do is connect to the git repository via ssh/ssl and copy back what you need.  The hardest part of using FreeNAS is creating the keys.

To start out, you need to create a user account on the FreeNAS system.  This will be a generic account that everyone who has write access will use.  You may also create a account for each person, and grant each of them access to the central repository.

After you have your account, follow my post on “Enable SSH Key Authorization on FreeNAS” to copy over the SSL key and setup the account.  Once you are able to log in as your FreeNAS git user, you may follow my previous post “Creating a secure Git repository server” to setup the git repository.

Enable SSH Key Authorization on FreeNAS

FreeNAS is a powerful tools for archive data and other long-term storage requirements. Recently I have started backing up this and other off-site servers to one of my local FreeNAS boxes. Since these systems are only connected via the insecure internet (no VPN), I decided to transmit the backup files via SSH using SCP.  In order to do this without having to enter my password in for each and every backup (most of which happen while I’m hopeful sleeping), I needed to implement SSH Key Authorization on the receiving FreeNAS box.

To do this first I needed to create a DSA key pair on a different system.  On my Fedora 12 laptop I ran

ssh-keygen -t dsa

The trick here is to not create your new key pair in the default directory of “~/.ssh/” but in a temporary directory instead. So when it asks you.

Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):

Enter a different file in witch to save the key in. Note this is asking for the name of a file, not the name of the directory, it will also create a .pub file, this is the public key for the above private key.

Now that you have a public/private key for the FreeNAS box, if you don’t already you need to create one for the user that you plan on sending the file from.  Just follow the above command, but this time, you may just hit enter all the way threw leaving all options as default.

Next, go to your FreeNAS web-page control panel, If you don’t already have one, you will need to create a user on your FreeNAS box for you to connect to.  You may do this via “Access -> User and Groups” from the black bar on the top of the page.

Now from the top (black) bar go to “Services -> SSH”

On your Services|SSH page, first make sure the service is enabled (top right hand corner). Once it is you will be able to change the below options.

  • TCP Port: The default (port 22) is fine in most cases, but note if you change it, you must use the new port for all connections.
  • Permit root login: My option is that the root account should never be allowed to log in via a remote process.  You should set your system up correctly where this is not needed.
  • Password authentication: For now this must be enabled (checked), once you have set “Key Authorization” up, you may disable this option.
  • TCP forwarding: Disabled (unchecked)
  • Compression: Enabled (checked)
  • Private Key: This will be were we put the private key created above.  All you need to do is copy and paste.
  • Extra options: Blank

After you have made your changes, “Save and Restart” the service.

On your local system, you need to copy the content of the local users public (~/.ssh/ key file to a new file named “authorized_keys” (Note: this is not the file we created for FreeNAS but the file we created for your local account).  This is the file that will need to be copied to your FreeNAS box.

Now that you have all the needed bits, we need to log into your FreeNAS server and create a “.ssh” directory to store the “authorized_keys” file.  To log in to the FreeNAS box interactively run a command similar too.

ssh freenasuser@freenasaddress

Or if you changed the “TCP Port” above, your command will look like this:

ssh -P freenasport freenasuser@freenasaddress

Once your logged in, you need to create the directory, by doing.

mkdir ~/.ssh

After you have successfully created your directory, you may exit out of your FreeNAS box for the next step.
Back on your local system you need to copy the “authorized_keys” file created before to the FreeNAS box. Using SCP you can do this by running a command like:

scp -P freenasport authorized_keys freenasuser@freenasaddress:~/.ssh/

This will copy the file to the FreeNAS box. Next, reconnect to the FreeNAS box as you did before and run.

cd ~/.ssh/
chmod 600 authorized_keys

Once your done, you should be able to connect to your FreeNAS box using the private key in the authorized_keys with out a password.

Creating a secure Git repository server

Creating a secure git repository server is a pretty simple process.  Basically we will be using SSH to transmit the data over an encrypted channel.  SSH will handle all the authentication and data encryption.  So the first set is creating a user for git to use and creating the git users ssh key.

On your server, from a privileged account, create a user (were going to use git).

adduser git
passwd git

The configuration we will be setting up will store the actual repositories in the git users home directory.  If you don’t like it’s current location, you may modify the /etc/passwd file for your user.

Once we have the user setup, in it’s home directory we need to create our first repository.  Start out by creating the folder, then well go into it and create the git repository files.

mkdir new-project.git
cd new-project.git
git init --bare

With the repository now setup go back to your desktop/laptop system (linux/unix).

From your desktop system, create a empty repository or go to an existing git repo. If you are going to be adding an existing repo, it may not be connected to any other remote repository. if you clone it from a remote source (a directory on the same system counts as a remote source) you will need to modify the repository’s config file and remove those entry’s, look in the config file under the .git (note the ‘dot’) directory.

To create an empty repository, create a directory for the repository, go into it and init the repo.

mkdir new-project.git
cd new-project.git
git init

Since you need something in your repo, and git likes having a readme file (or gitweb dose) let’s create a readme file and commit it.

touch README
git add README
git commit -m 'Added README file, first commit'

Now that we have a commit in our repo, we can add the newly created git repo server and push our new repo to it.

We will start by adding the server to the repo’s configuration.

git remote add origin

The above example assumes you’re server’s name is “” and your using a project named “new-project.git” for the user “git”. But it also assumes that your repo is directly in the user git’s home directory. If you store your repo’s in a different directory, you will need to add the list folders after the colon.

After you have successfully added the server, push your new repository to the server.

git push origin master

You may now be asked for the git user’s password, enter it, and your repository should be transferred.

Also check out how to setup a ssh public/private key where no password is required, only the private key on your client system.

The above may look like a lot, but it’s really pretty simple to setup. If you have any problems or questions abut this How-To, please leave a comment or contact me.