Typically email attachment sizes are limited. Users complain when attempting to email huge spread sheets or media content if they are denied due to size restrictions.

Typically the solution has been FTP. However FTP generally leaves much to be desired for the average user. It requires the maintenance of accounts. Some people are restricted by local policy and firewalls. Browser support for FTP is weak. FTP servers must generally be maintained or entropy sets in and they become an administrative and security nightmare.

Enter Allard Software’s Filetransfer Appliance.

It works like this: When a user has the need to send a large attachment they point their web browser to the File Transfer server. They get a page with a form to send an email. They fill in To:, Subject:, and their message. They then browse the file and click upload. Then they can send the email. The recipient gets the email which contains a link to download the file. The file expires after a set period of time. The recipient receives a notification when the file is downloaded. That’s it! Beautifully efficient and simple!

Filetransfer Appliance is a piece of cake to set up. It installs as a VMWare appliance – meaning the software is already installed and configured. All you need to do is boot the VM, give it a hostname and set your IP address. There are a few configuration options including your mail server and Active Directory integration so users can authenticate with their AD credentials.

The device can use SSL with your own certificate or a self signed certificate if you choose.

Support is highly responsive from the developer himself.

The device is incredibly inexpensive, licensing starts under $100 for 10 users and their is a FREE 3 user demo.

http://www.allardsoft.com/filetransfer

I work in linux a lot as well these days. I’m just finding after years of Microsoft that I really like linux. It is my base OS and I run VMWare or RDP sessions to manage my Microsoft shop.

I’ve been wanting to use a simple POP or IMAP client to check my mail when I’m traveling, have poor connectivity, etc. My company has many people overseas on very slow and highly contended VSAT connections. I don’t like passing my credentials in plain text.

I applied a secure certificate to the virtual POP3, IMAP, and SMTP servers on our Exchange 2003 front ends. I opened the appropriate firewall ports, and voila we had secure IMAP and POP3. SMTP was a little weird.

Exchange does not use a separate port for secure SMTP. It uses port 25 for everything. This works out fine. When you configure your client, choose TLS and not SSL. Make sure it is port 25. You can confirm your email was sent encrypted by looking at the header (send yourself a test). It will say the email was received by your smtp server in an encrypted session.

One last gotcha – the secure SMTP worked inside the firewall and not outside. When using telnet into the mail server on port 25 from the inside, an EHLO issued a full string of options, including STARTTLS. Outside the firewall, these options were only a string of XXXX’s. Cisco firewalls using inspect ESMTP statements filter out the STARTTLS option. This also causes the client to fail with an error stating the STARTLS is not offered. Remove the ip inspect esmtp statement and all will be well.

Outlook and Outlook Express use SMTP 25 and the SSL option, not TLS. Any other client, choose TLS.

Clients tested: Thunderbird, Evolution, Outlook Express

Note: if you are using Outlook or Evolution you might consider using the rpc/https built into these two clients.