theory14

Dovecot IMAPS Proxy with OpenBSD 4.8

theory14 — Fri, 24 Dec 2010 16:19:15 +0000

In a previous article, I discussed setting up an IMAP proxy to get mail remotely from my iPhone using Doevcot. The one part of the set up I never really liked is that the link from my bastion host acting as a proxy and my actual mail server had to go un-encrypted. Granted this was inside my network and if someone was sniffing the transaction off the wire I had bigger problems, but it still bothered me as less than perfect. While I could have grabbed a Dovecot RC source tarball and had the feature, I preferred to stay with what was packaged with OpenBSD and have lived with the lack of encryption inside my network. Well I finally (OK, just a month and a half since release) updated my inbound proxy to OpenBSD 4.8. and one of the prominent notes on the upgrade is a move to Dovecot 1.2.x. This upgrade allows encryption of the proxied connection and resolves that long-standing concern I’ve had.

Assuming your internal mail server is already listening for IMAPS connections, you only need to modify the “extra-fields” in your /etc/dovecot.passwd file to get encryption of the proxied connection. For example:

bubba:{PLAIN-MD5}31337::::::proxy=y host=192.168.5.6 ssl=any-cert port=993

Before and After

Is Twitter really something new?

theory14 — Sat, 11 Dec 2010 19:01:51 +0000

While I’m on the topic of poorly re-invented applications, I’ll take a quick shot at Twitter (in a tweet-length post). Is this really anything more than finger and keeping your .plan up to date?

ChromeOS: nothing new, just a re-hash of what was done better before

theory14 — Sat, 11 Dec 2010 18:42:13 +0000

I was just reading a few articles and watching a couple of videos about Chrome OS and the Cr-48 laptop. From what I’ve seen this is pretty much a netbook that boots and loads a browser as your UI. You do everything from within the browser including additional “applications” that you install in the browser.

As I watched this I immediately thought of Emacs and the jokes about Emacs being a nice operating system. Let’s see, Emacs has been ported to many different operating systems (many more than the Chrome browser and not tying you to ChromeOS), has many different forks incase you would like something a little bit different than the GNU version, has a rich library of extensions and packages (like the Chrome Web Apps), contains a scripting language to customize or further extend it, and some people even use it as a text editor. This sounds a lot like what Google is trying to do with Chrome without the added “benefit” of making sure your eyeballs land on Google web properties (ad placement, user tracking, etc).

The other big hype about Chrome OS seems to be that you can get to your data from anywhere. You just fire up any copy of the Chrome browser on a regular computer or your ChromeOS laptop, log into your Google account and everything is there. All of your applications and all of your data available anywhere. All of it tucked away on Google’s servers for them to mine, use to target you with advertisements, better track you, and if they ever need a bunch of cash, to sell. The universal access to your data is, like Emacs, nothing new; though, selling your soul and identity for it is. Before the Internet was prevalent (or existed) you could use a modem to connect to your computer from anywhere that had a phone line and fire up your copy of Emacs and run all of those great applications and extensions in it. Today, this is just as easily accomplished with an SSH client and internet connection instead of a modem and phone line. SSH clients are available on a far larger number of platforms than is ChromeOS. It’s a default part of Mac OS X, pretty much every Linux distro (don’t know about ChromeOS or if it is even considered a Linux distro), all of the BSDs, and with a copy of PuTTY (a single file) on a USB stick, it’s available on any Windows machine you encounter. The best part is that all of your information is on your own computer safe from any data mining.

So far all of the hype about this revolution that Google has created, all they have done is re-invented what has been around since the mid-1970s. I’m sure there are many examples other than the ones I chose, but it all comes down to a quote ”Those who don’t know history are destined to repeat it, poorly”.

P.S. I’m a vi user.

Moving the Blog

theory14 — Sun, 05 Dec 2010 03:25:23 +0000

I’m just finishing up moving this blog from Blogger to WordPress. I can see that some of the word wrapping didn’t translate so well in some of the posts (code snippets in particular). I’ll try to go back and fix then, but I apologize in advance if something is hard to read.

Disk Drives for Mac Video Editing

theory14 — Sun, 01 Aug 2010 17:24:00 +0000

Following a number of video editing forums, the question of what kind of disk should be used, often comes up. I’ve seen this general question come up a lot on the forums — “Is my disk OK? What kind of disk do I need?” There are a lot of good answers to these questions that get people working quickly, but I thought I’d take a little bit and explain a bit more of the “why” and “how” this all works. I’m going to keep this at somewhat of a high level and limited to what we would typically put in our Macs.

Fundamentally, you are concerned with two basic properties of the system:

How fast you can get data to/from the disk
How fast the disk itself can read/write that data

First, how fast can we get data to/from the disk. This is governed by the interconnect technology used to connect the CPU/Memory to the disk. On a typical Mac, you have a few options:

SATA (Serial ATA): This is what your internal hard drives are connected with. This can nominally push data at 3 Gbits/s (3072 Mbits/sec). SATA was designed for hard drives.
eSATA: Simply SATA with special connectors to support external disk enclosures.
USB: This will nominally push data at 480 Mbits/sec. Due to the way USB works, it can have performance issues keeping up performance transferring large amounts of data — expect to see half or less of the nominal rate. USB was designed as a general peripheral connection technology — not necessarily optimized for disks storage.
Firewire (IEEE 1394): Comes in two versions, FW 400 (nominally 400 MBits/s) and FW 800 (800 MBits/s). Firewire was designed to support disk storage along with other audio/visual connectivity protocols.

The disks themselves… So what are the important parameters to look for in the disk itself:

Rotational Speed: This is how fast the drive spins. You will typically see two different speeds 5400 rpm and 7200 rpm. There are increasingly “green” drives appearing on the market which I’ll discuss briefly later. Hard drives have spinning platters (disks) and a set of read/write heads inside them. This isn’t much different than a phonograph with the disks being the vinyl record and the read/write heads being the needle. To access a bit of data, the heads have to move to a specific radial position and then wait until the write spot is spun underneath them. Remember that data (your files) is, to various degrees spread all over the disks. When you read or write a lot of data the heads are constantly repositioning and waiting as right data passes under them. Think of trying to listen to several songs at the same time on a vinyl record and you get the idea.
Cache: Disks have cache on them that can speed up read and write operations. Bigger is generally better, but cache is only so good.
Data Transfer Rate: This is fundamentally a function of the rotational speed, but it tells you how fast the disk can actually read/write. Each disk has different specs, so you have to check the disk you’re considering. Also be very careful as to exactly what performance is being reported by the manufacturer and make sure you are doing apples to apples comparisons.

Now to tie it all together. You’re speed is going to be limited by the slowest part of the chain. If you put a slow disk with a fast interconnect, you’re limited by the slow disk and vice versa. In practice, the slowest options of the above are USB and 5400 rpm drives. Either SATA or Firewire has a higher data rate than the 7200 rpm disk can sustain. The other thing to consider is how many concurrent IO operations you are sending to the disk. Your system disk (Macintosh HD) has to service all of the other IO needs of your system. If you add your video editing demands to this, you could overwhelm the drive.

I think there are a few common problems that people run into:

The MacBook Pro’s standard drive is a 5400 rpm disk. This is probably going to be too slow for most video editing demands, especially when you add additional IO demands. It will “work” but you probably won’t be happy.
Disk is too full. You need to leave 10% – 20% of your disk free. The OS needs this free space to easily organize the data it’s writing to disk.
Just sending too much IO to a single disk. A single disk can only handle so much IO. Once you go over that, you wait (or drop frames).

The most common solution is to use a 7200 rpm disk connected by Firewire. 7200 rpm because it’s the fastest you’re going to reasonably afford and Firewire because it’s fast enough and every Mac (maybe not the MacBook) has it. If you have a MacPro, you can look at adding more internal SATA drives (consider RAID’ing them for more performance) or look at eSATA (need to buy a controller in addition to disks).

If you’re in a bigger setting with shared storage arrays, you have even more options and things get even more complicated. I’ll not going into that here, but am happy to discuss in more detail if anyone is curious.

P.S. What about those “Green” disks — I want to be nice to the environment. The Green drives that are becoming popular work by dynamically changing speeds based on demands, with their primary goal to save power and thus run at slower speeds. When you start sending data to these disks, they typically have to spin up from some nominal lower speed to something faster to support your IO. You pay a penalty (wait) for the spin up and are at the mercy of the drive to decide if it wants to spin up to full speed. These are great for longer term storage for data infrequently used (say a Time Machine disk, Aperture Vaults, iTunes music collection, or just online archive storage of files (vidoe or otherwise)) but not for something needing consistent, fast throughput, say Video Editing.

Automating SSH Tunnels on Mac OS X

theory14 — Sat, 24 Apr 2010 16:24:00 +0000

There are a number of packages out there that put a nice GUI over creating and managing SSH tunnels on Mac OS X. While these are great if you aren’t already familiar with SSH, how to do this all from the command line and really aren’t interested in learning, if you are, they may be a bit of overkill and may be a bit restrictive in what you can do.

I finally got a Mac at work (my company’s Corp IT group is becoming a bit more enlightened and accepting that more than just Windows exists in the world) and I want a simple way to spin up SSH tunnels, close them down not have to keep a terminal window open for them. My solution is to wrap some Applescript around the SSH commands and launch my tunnels from the script menu on the menu bar.

The simple script:

do shell script "ssh -4 -A -N -L 12345:localhost:12346 host.example.com &> /dev/null & echo $!"set sshpid to the resultdisplay dialog "ssh PID is: " & sshpid buttons {"Close Tunnel"}do shell script "kill -9 " & sshpid

When the tunnel is created, a window will pop up giving you the pid of the ssh process and a button to close the tunnel. When click the “Close Tunnel” button, the tunnel is shutdown by killing (with the mean -9, chose the signal you want) the ssh process.

Now my most common need/desire for a tunnel is to listen to my music stored at home on my machine at work. At home I use Firefly Media Server to share my library so I just want to tap into that at work. A quick google search shows the steps to do this:

Use dns-sd to register a daap servers on local host
Create an ssh tunnel from localhost to the remote daap stream

The script is (my ssh tunnel bounces through a couple of different hosts):

do shell script "dns-sd -P my-music _daap._tcp local 3690 localhost.local. 127.0.0.1 Arbitrary &> /dev/null & echo $!" set dnssdpid to the result do shell script "ssh -4 -A -L 3690:localhost:9999 host1.example.net ssh -l remoteuser -A -L 9999:localhost:9998 192.168.10.3 ssh -A -N -L 9998:localhost:3689 host2.example.net &> /dev/null & echo $!" set sshpid to the result display dialog "Music Tunneldns-sd PID is: " & dnssdpid & "ssh PID is: " & sshpid buttons {"Close Tunnel"} do shell script "kill -9 " & sshpid & " " & dnssdpid
This script starts both dns-sd and the ssh tunnel and when closes them both down when the “Close Tunnel” button is clicked.

To run this easily, enable the Script Menu in the menu bar (via AppleScript Editor preferences) and put the script in~/Library/Scripts.

Snow Leopard — First Impressions

theory14 — Sun, 30 Aug 2009 14:33:00 +0000

I was planning on picking up Snow Leopard (Mac OS 10.6) next weekend, but we were by the mall yesterday, so I went ahead and picked up a copy. My initial plan was to wait a week and let any major issues be discovered before I did my upgrades. Of course, I couldn’t let it sit around for a week, and with multiple backup systems of my machines, I installed it last night. My initial experience and impressions are:

The upgrade process took 22 minutes and consisted of 3 or 4 mouse clicks and a reboot.
I have a number of SMB shares mounted from a server running Samba. I had to change the security setting to “user” where it had been “share”.
The upgrade performed by the installer overwrote my /etc/snmp/snmpd.conf file. This prevented any snmp monitoring from working until I figured out what went wrong. (The installer also re-enables the OS X firewall even if it was disabled before — probably a good decision)
It seems that Image Capture has gotten significant improvements with 10.6 — I haven’t noticed this called out by any of the other reviews. The UI is much more feature-full and even offers the option to delete images and videos from my iPhone. (If this was in the previous version, I hadn’t noticed it.)
Boot time is noticeably faster.
I ended up saving about 10GB of disk space as part of the upgrade

I’ve only played with Snow Leopard for a few hours, so I expect to find out more things as I get more time with it.

Getting mail on my iPhone

theory14 — Fri, 26 Jun 2009 16:50:00 +0000

We got our iPhones 3GS on the launch day, and I spent part of the weekend getting mail working right. I did hit a few issues, but I have everything working acceptable now. This is all based on my previous post on configuring a mail proxy.

The issues I hit were:

Can’t seem to get the phone to connect on a user specified port for either IMAP or SMTP. There are options for that, but I could never get my phone to (reliably) use them.
I could never get starttls to work with the iPhone. Other clients, mail.app, worked just fine. This is annoying, but not such a big deal. The password for the login is still encrypted and the mail itself would normally be going outside of my systems anyway.
There is no “advanced” or “expert” UI for initially setting up email accounts on the iPhone (nor on mail.app). This means that you have to wait as the phone walks through a lot of default mail options (ports to connect on, SSL or no SSL, etc) before you get a chance to adjust anything.

So here are the steps. There was some bit of trial and error, but I tried to record everything accurately.

Before you try to setup any mail accounts on the phone, you should import all of your self signed certs to the phone. To do this, simply upload all of the certs, renamed to something.crt to a web server and then load that site in Safari on your iPhone. That means to put the .crt files into a directory you can access from your phone (or any browser), not to use the certs to SSL encrypt the site. When you load each of those files in Safari (like going to http:///your.site.tld/file/mycert.crt), you’ll get a new application to import the cert into your profile.
Now create the accounts on the iPhone as you would otherwise. The settings for your connections are:

Connection Username Authentication SSL

Incoming username Password On

Outgoing username@domain CRAM-MD5 Off
When making the initial IMAPS connection, you will be prompted to accept the certificate. Click to continue/accept the cert. I would have thought that importing the certs to my phone’s profiles would have taken care of this, but it didn’t. Of course there is probably some nuance of PKI that I don’t grok (feel free to enlighten me if you know the details).
After much waiting as the phone tries various incarnations of SMTP connections, you’ll get prompted to attempt to proceed un-encrypted. Say NO here. If you say “yes”it seems to screw up the IMAPS connection that is actually working fine at this point.
Now go into the mail settings and fix the SMTP connection to work right. Turn off SSL and set the authentication to CRAM-MD5.
Open mail on the phone and you should mail working fine. Try reading some of your mail and try sending some to make sure it all works right.

That’s about it. This is far from perfect, but seems to be working reliably and the boss (wife) approves. If someone has details on how to make this better or more efficient, please let me know.

OpenBSD + SMTP AUTH/TLS + IMAPS Proxy

theory14 — Tue, 16 Jun 2009 00:50:00 +0000

Problem

I want to securely access my home email from my newly ordered iPhone 3GS. Since my mail repository is at home (vs on some one’s webmail/freemail platform) and I want to be able to send email from my domain, I need to connect from essentially anywhere to my home systems.

Solution

I have an existing bastion host running OpenBSD to which I added the mail functions. Documentation that I found was a bit out dated or didn’t quite put everything together, so I’m putting it all together here. This article is based on what is available with OpenBSD 4.5.

First, what are the different pieces in this puzzle?

Retrieve/view mail: I keep all of my mail on a server at home and provide access via IMAP(S). I extended this by using dovecot as an IMAP proxy on the bastion host. This allows you to view your mail.
Sending mail: Sendmail is the base MTA I’m using (it’s part of the base install of OpenBSD) and to get the secure authenticated connection for remotely sending mail, two different things are needed.
- TLS: For my purposes, this encrypts the connection via starttls(8)
- Authentication: This provides the ability to authenticate users and allow authenticated users to relay mail through the server. This is done via cyrus-sasl.

Dovecot/IMAP Configuration

The configuration for dovecot is rather simple, but I never found it explicitly called out. Acting as a proxy for a particular user is done as part of an entry in the user database. Larger installations with many users can use a database for this, but for a small handful of users, this is more easily done with a passwd-file.

Install dovecot. Either build it from source via ports or install the package. See the OpenBSD FAQ for how to do this.
In /etc/dovecot.conf, find the section specifying the password database as a passwd-file and uncomment it such that you end up with the following. See AuthDatabase/PasswdFile section of the dovecot wiki for more details.
```
# passwd-like file with specified location# passdb passwd-file {# [scheme=] [username_format=]# args = username_format=%n /etc/dovecot.passwd} 
```
Create the passwd file, /etc/dovecot.passwd, in your favorite editor filling in the fields as described in the Passwd-file documentation. You should end up with something that looks like the following:
```
fred:{PLAIN-MD5}b40ac4fe40284c9de587b992c08f167::::::proxy=y host=my.proxy.domain.tld port=143
```
The last fields, the extra fields, are the ones that make the proxy actually work. Note that the TLS/SSL options discussed in the dovecot documentation are only available in newer versions (1.2.rc4+) and not in the stable versions. That means I’m stuck with an un-encrypted connection between my bastion host/proxy and my real mail server. This isn’t the perfect solution, but I prefer using the proxy to just allowing a direct connection from anywhere on the internet to my internal servers. Create the md5 passphrase hash with the md5(1) command:
```
md5 -s password
```
Configure dovecot to start at boot (if you didn’t when you installed it) and start up dovecot. In /etc/rc.local add:
```
if [ -x /usr/local/sbin/dovecot ]; then echo -n ' dovecot';  /usr/local/sbin/dovecotfi
```

Sendmail TLS Configuration

This is the easy part to write up. Follow the steps in the starttls(8) man page. Remember, this just gives you encryption when connecting to send mail.

Sendmail Authentication

This requires installing the Cyrus-SASL libraries, configuring users and saslauthd, recompiling sendmail and configuring sendmail.

Install cyrus-sasl. Either build it from source via ports or install the package. See theOpenBSD FAQ for how to do this.

Configure the sasl auth daemon for authentication from sendmail:

echo pwcheck_method: saslauthd > /usr/local/lib/sasl2/Sendmail.conf

Create users (these are the users and passwords for sending mail) with saslpasswd2(8) with the following command (you’ll be prompted for a password). This will create /etc/sasldb2.db. You will use username@domain as the username for authentication.
```
saslpasswd2 -c -u domain username
```

Configure saslauthd to start at boot by adding the following to /etc/rc.local :

if [ -x /usr/local/sbin/saslauthd ]; then echo -n ' saslauthd'; /usr/local/sbin/saslauthd -a getpwentfi

Start saslauthd with /usr/local/sbin/saslauthd -a getpwent
Rebuild sendmail with sasl support:
- Add WANT_SMTPAUTH=YES to /etc/mk.conf
- If you don’t have the OpenBSD source code installed, install it. See the OpenBSD FAQ for details on doing so if needed.
- cd to /usr/src/gnu/usr.sbin/sendmail/ and build and install sendmail with make clean obj depend && make && make install

Configure sendmail for all of the new options. Edit /usr/share/sendmail/cf/openbsd-proto.mc as follows:

Uncomment (remove the “dnl” from the beginning of the line) the section for TSL/SSL support.

dnldnl TLS/SSL support; uncomment and read starttls(8) to use.dnldefine(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnldefine(`confCACERT_PATH', `CERT_DIR')dnldefine(`confCACERT', `CERT_DIR/mycert.pem')dnldefine(`confSERVER_CERT', `CERT_DIR/mycert.pem')dnldefine(`confSERVER_KEY', `CERT_DIR/mykey.pem')dnldefine(`confCLIENT_CERT', `CERT_DIR/mycert.pem')dnldefine(`confCLIENT_KEY', `CERT_DIR/mykey.pem')dnl

Add the following options for SMTP AUTH.

dnldnl Set SMTP AUTH optionsdnldefine(`confAUTH_MECHANISMS',`PLAIN LOGIN CRAM-MD5 DIGEST-MD5')dnlTRUST_AUTH_MECH(`PLAIN LOGIN CRAM-MD5 DIGEST-MD5')dnldefine(`confAUTH_OPTIONS',`p,y')dnldefine(`confPRIVACY_FLAGS',`authwarnings,goaway')dnl

Rebuild the cf files and install them by:
- cd /usr/share/sendmail/cf
- make distribution
Configure sendmail to listen for connections over the network (default configuration is to listen only on localhost) by adding sendmail_flags="-L sm-mta -bd -q30m" to /etc/rc.conf.local

Kill the running sendmail, source the new configuration options and restart sendmail:

kill `head -n1 /var/run/sendmail.pid`. /etc/rc.conf/usr/sbin/sendmail $sendmail_flags

That’s it! You should now have everything setup and working. In trouble shooting and testing my configuration, I found it very handy to watch traffic with tcpdump(8) with a command like tcpdump -n -s 1500 -vvvX port 25 .

Credits:

A good bit of the SMTP AUTH configuration steps where taken from http://www.dsrw.org/~dlg/sysadmin/sendmail/ which was written for OpenBSD 3.3. Some things have changed by OpenBSD 4.5 partly compelling me to write this article.

Squid Proxy for Security

theory14 — Wed, 10 Jun 2009 23:53:00 +0000

The Problem

It’s pretty standard these days for everyone connected to the Internet to sit behind some kind of firewall. These firewalls are typically configured to block/filter inbound connections, but allow any connections initiated from inside. This is great for blocking the many scans and connection attempts from the outside, but misses what is the more common risk scenario.

Some non-trivial number of exploits aren’t sourced by a connection initiated externally. Things such as spyware get introduced into a system via some means such as email attachments or, more commonly, a web browser exploit and a compromised web site. Once installed, they collect data and perform their real nastiness by sending that collected data back to its owner. All of this is done through connections allowed by the firewall policy.

Another issue is that once a nefarious soul has gained access/control of a machine, they’d like to use it to make connections to other machines to conduct various kinds of mischief. Control of the machine is often through some kind of bot that (a) must connect to some control site to get instructions and (b) must be able to make outbound connections to effect trouble on others.

A Solution

A solution to this is to block all outbound access by default and then only allow what is very specifically needed — only specific hosts can make outbound connections on specific ports to specific destinations. This can seriously limit the usefulness of your systems to a possible attacker. If they can’t call home to get commands, can’t ship your personal information back to their home base and can’t use your machine(s) to attack others, your systems just aren’t very interesting. The problem is that without the ability to connect to various places on the internet, your machine(s) become very un-interesting to you, too.

My solution to this is to proxy all of the outbound connections through one host and only allow that one host to make the out bound connections. This provides several advantages:

Regardless of hosts coming and going on my network, I don’t have to constantly update firewall rules.
With a proxy, I can log all of the outbound connections. This provides an audit source and a place to see what is really requested when outbound connections are made.
For a bot or spyware to make an outbound connection, they must understand how to use a proxy and know how to grab the proxy settings. Though this isn’t necessarily very hard, but it is another hoop that must be jumped through.
If I haven’t specifically configured my proxy for a given protocol, then outbound connections aren’t possible, stopping the exploit from being effective.

For many years, I’ve used squid as a cacheing proxy to locally cache web content. This made squid an obvious choice to extend for security purposes. The configuration comprised of three steps. First, configure squid to proxy the various protocols I needed to proxy. Second, configure my firewall to only allow the host running squid to have outbound access as needed. Third, configure various clients to use the proxy.

Squid Configuration

I’ll assume you have a working squid installation that is already proxying http(s) and ftp traffic. If not, there are a number of how-tos and other documents available on the web for configuring squid for this (and they will do a much better job than I will).

My configuration supports proxying AIM, Yahoo! IM, Google IM/Gtalk (Jabber), MSN Messenger, and rsync. Simply add the following to your squid.conf and restarting squid should allow these protocols to be proxied. I’ve collected some of these configurations from various places on the web, so I can’t claim credit for figuring it all out.

In your squid.conf file add:

################## allow AIM access#acl AIM_ports port 5190acl AIM_domains dstdomain .oscar.aol.com .blue.aol.comacl AIM_domains dstdomain .messaging.aol.com .aim.comacl AIM_hosts dstdomain login.oscar.aol.com login.glogin.messaging.aol.comacl AIM_nets dst 64.12.0.0/255.255.0.0acl AIM_methods method CONNECThttp_access allow AIM_methods AIM_ports AIM_netshttp_access allow AIM_methods AIM_ports AIM_hostshttp_access allow AIM_methods AIM_ports AIM_domains#################

################## allow Google IM (Gtalk) access#acl GTALK_ports port 5222 5050acl GTALK_domains dstdomain .google.comacl GTALK_hosts dstdomain talk.google.comacl GTALK_methods method CONNECThttp_access allow GTALK_methods GTALK_ports GTALK_hostshttp_access allow GTALK_methods GTALK_ports GTALK_domains#################

################## allow MSN Access#acl MSN_ports port 1863 443 1503acl MSN_domains dstdomain .microsoft.com .hotmail.com .live.com .msft.net .msn.com .passport.comacl MSN_hosts dstdomain messenger.hotmail.comacl MSN_nets dst 207.46.111.0/255.255.255.0acl MSN_methods method CONNECThttp_access allow MSN_methods MSN_ports MSN_hosts#################

################## allow Yahoo IM Access#acl YIM_ports port 5050acl YIM_domains dstdomain .yahoo.com .yahoo.co.jpacl YIM_hosts dstdomain scs.msg.yahoo.com cs.yahoo.co.jpacl YIM_methods method CONNECThttp_access allow YIM_methods YIM_ports YIM_hostshttp_access allow YIM_methods YIM_ports YIM_domains#################

################## allow rsync proxy#acl RSYNC_ports port 873acl RSYNC_methods method CONNECThttp_access allow RSYNC_methods RSYNC_ports################

Now the rest is up to configuring your firewall appropriately and setting your various clients to use the proxy.

Connection	Username	Authentication	SSL
Incoming	username	Password	On
Outgoing	username@domain	CRAM-MD5	Off