Establish a FreeBSD Server and install the Delegate port.

In my case to do this I created a new VMWare Fusion FreeBSD Virtual Machine.

To install Deletate use FreeBSD Ports to download, compile and install the required software:

OpenSSL - to provide SSL/TLS support

Delegate - provide the proxy gateway

NOTE: I am sure there are equivalent Linux packages to allow a Linux variant to be created

Configure the delegate server by editing the startup file in /usr/local/etc/rc.d/delegated.sh

Delegate is a highly configurable proxy, so it is hard to now how it should be configured. In my example network, all external access requests should go the the Delegate Access Server and then they need to get redirected to the "Firewall Router".

In the next few steps I provide the sample Delegate configurations used to allow Delegate to take over from the "Mobile Access Gateway"

Delegate startup for IMAPS proxy.

This establishes IMAPS (IMAP via SSL) application proxy on Port 993 (the standard port for IMAP SSL) and forward this to the "Firewall Router" port 993 which in turn port forwards it to IMAPS on Port 993 on "Mail Server" which is within private network.

# /usr/local/sbin/delegated -P993 \
# SERVER=imap MOUNT="* imaps://firewall.your-domain.com/*" \
# STLS="fcl,fsv" \
# ADMIN=postmaster@your-domain.com \
# RELIABLE="*"

The important items are:

• -P993 - which establishes the listening port
• SERVER=imap - which indicates that the proxy should use imap protocol
• MOUNT="* imaps://firewall.your-domain.com/*" - forward requests to address firewall.your-domain.com using IMAPS protocol and starndard port (993)
• STLS="fcl,fsv" - means that SSL/TLS should be used for both Client (fcl -the remote device connecting) and Server (fsv - the mail server we are connecting to).
• RELIABLE="*" - allow any one to connect (ie service is open, so use your Internet facing to ensure that you do not get DoS and other attacks)

NOTE: The digital certificates that will be used by the Proxy server should be stored in the ${DGROOT}/etc/certs directory, with ${DGROOT} == /var/spool/delegate-nobody on FreeBSD (see item 3 below for more information on digtial certificates.

TESTED: Tested and works with: OS X 10.7.4 Mail Client, iPhone/iPad iOS 5.1.1

Delegate startup for SMTP proxy.

This establishes an SMTPS (SMTP via SSL) application proxy on Port 993 (the standard port for SMTP SSL) and forward this to the "Firewall Router" port 857 which in turn port forwards it to SMTPS on Port 857 on "Mail Server" which is within private network.

# /usr/local/sbin/delegated -P587 \
# SERVER="smtp://firewall.your-domain.com:587" \
# STLS="fcl,fsv" \
# ADMIN=postmaster@your-domain.com \
# RELIABLE="*"

The important items are:

• -P587 - which establishes the listening port
• SERVER="smtp:://firewall.your-domain.com:587" - sent all request forward to "Firewall Router" port 587

NOTE: that originally I used the MOUNT syntax as per IMAP example above, but found that this did not appear to work, so I used the SERVER="smtp://<to>:<port>" configuration, which resulted in successful forwarding of SMTP traffic.

TESTED: Tested and works with: OS X 10.7.4 Mail Client

Experimental Delegate startup for SMTP proxy with iOS SMTP (for email submission)

Due to problems with the (2b) configuraiton above and iOS I have been experimenting with alternative configuration via the old SMTPS SSL port 465. I have been trying various options including using: tcprelay, going from SMTPS to SMTP (within and without STARTTLS) to see if I can get iOS email Submission to work. I will update once I have managed to get SMTP email submission working.

At this stage I cannot understand why OS X Lion Mail client works but iOS does not.

# /usr/local/sbin/delegated -P465 \
# SERVER=smtp MOUNT="* smtp://firewall.your-domain.com/*" \
# STLS="fcl,fsv" \
# ADMIN=postmaster@your-domain.com \
# RELIABLE="*"

The important items are:

• -P587 - which establishes the listening port
• SERVER=smtp MOUNT="* smtp:://firewall.your-domain.com/*" - sents all request forward to "Firewall Router" port standard SMTP port (25)
• STLS="fcl,fsv" - used SSL with client (fcl) and SSL with server (fsv), however as server is standard SMTP, this must be via STARTTLS

NOTE: This configuration is still being tested to try to address problems with the SMTPS proxy configuration above (2b) and iOS devices.

TESTED: Testing with: iPhone/iPad iOS 5.1.1 to try to fix problem with SMTP email submission, but still not working. See item (6) below for alternate work around

Delegate startup for CalDav (Calendar Server) tcprelay proxy.

This establishes an CalDAV (Calendar via SSL) tcprelay proxy on Port 8443 (the standard port for Apple Calendar SSL server) and forwards this to "Firewall Router" port 8008 which in turn port forwards it to the non-SSL Calendar server Port 8008 on "Mail Server" which is within private network.

# /usr/local/sbin/delegated -P8443 \
# SERVER="tcprelay://firewall.your-domain.com:8008" \
# STLS="fcl" \
# ADMIN=postmaster@your-domain.com \
# RELIABLE="*"

The important items are:

• -P8443 - which establishes the listening port
• SERVER="tcprelay:://firewall.your-domain.com:8008" - sent all request forward to "Firewall Router" port 8008
• STLS="fcl" - means that SSL/TLS should be used for Client (-fcl) but standard TCP socket (non-SSL) is used for connection back to server

NOTE: The reason for going from SSL/TLS based port is due to problems with the original Mobile Access Gateway, where I was not able to get the proxy to correctly authenticate when either the Calendar or Address requests where proxied through to SSL based services

TESTED: Tested and works with: OS X 10.7.4 Mail Client, iPhone/iPad iOS 5.1.1

Delegate startup for CardDav (Calendar Server) tcprelay proxy.

This establishes an CardDAV (Address via SSL) tcprelay proxy on Port 8443 (the standard port for Apple Address SSL server) and forwards this to "Firewall Router" port 8800 which in turn port forwards it to the non-SSL Address server Port 8800 on "Mail Server" which is within private network.

# /usr/local/sbin/delegated -P8843 \
# SERVER="tcprelay://firewall.your-domain.com:8800" \
# STLS="fcl" \
# ADMIN=postmaster@your-domain.com \
# RELIABLE="*"

The important items are:

• -P8843 - which establishes the listening port
• SERVER="tcprelay:://firewall.your-domain.com:8800" - sent all request forward to "Firewall Router" port 8800
• STLS="fcl" - means that SSL/TLS should be used for Client (-fcl) but standard TCP socket (non-SSL) is used for connection back to server

NOTE: Note that both CalDAV and CardDav use HTTP/HTTPS as communications protocol, so these should also be configurable via HTTP proxy.

TESTED: Tested and works with: OS X 10.7.4 Mail Client, iPhone/iPad iOS 5.1.1

You will need to configure your Delegate proxy SSL certificates, if you want to use a certificate from a Trusted provider.

This requires that you place two certificates into the ${DGROOT}/etc/certs.

On FreeBSD ${DGROOT} == /var/spool/delegate-nobody

The certificates required are:

• me-key.pem - the private key
• me.pem - the public certificate

It is that simple...

The final step is to configure the startup file, so Delegate starts automatically on reboot.

The file on FreeBSD is in: /etc/rc.conf

Simply add the line:

deletegate_enable="YES"

Here is the standard Delegate startup script, which is in /ustr/local/etc/rc.d/delegated.sh

As per notes on Items: 2b & 2c getting SMTP submission proxy up and running has with iOS devices 5.1.1 Devices has proved very frustrating and so far not meet with success.

I have since realised that there is a simple work around solution to this problem and that is to simple configure the devices so its used standard public SMTP service (on Port 25).

As per diagram above for iOS Device SMTP submission I have simply uses the "SMTP - Direct SMTP Submission" path for the device configuration. The public SMTP Port 25, which is used for all communications between SMTP Mail Transfer Agents (MTU) and is required to receive general email, is configured as a port on the "Firewall Router" which then forward SMTP traffic to port 25 on the internal "Mail Server".

The disadvantage of using this solution is that it means that your email will traverse the internet in clear text and if you do not use one of the private password transmission mechanisms then even your password could be transmittted in clear text.

To avoid clear text password submission, you should use MD5 Challenge/Response, using the "Outgoing Mail Server" SMTP mail server screen with "Mail, Contacts , Calendars" Settings option. See below for example:

NOTE: To configure MD5 Challenge-Response as an Authentication option requires you to have set up you Mail server with this option.