Thunderbird, Apache, Filelink
If you are sending an email with a large file attachment, the chances are that it will bounce back with a message saying that the email exceeds the maximum allowed.
Emailing large documents, presentations, images and other multimedia content is the norm these days. This means that bounced emails are a regular plague.
Thunderbird has solved this problem by implementing "Filelink" technology. This works by uploading the attachment to a server and converting the attachment into an embedded link in the email.
Several services are presently included in the Thunderbird offering, including Ubuntu One, YouSendIt and Box. The Mozilla page for filelink is here: Filelink.
However, most users are unlikely to want to trust their attachments to a third party service. There is a way to host your own solution, using Apache and turning on WebDav.
First, you need to install the Thunderbird addon, Webdav for filelink.
- Go to Webdav for filelink and install the add-on in Thunderbird (alternatively, Tools->Addons in Thunderbird and search for it in there and install it).
- After you have configured your webdav service in Apache, you will need to configure Webdav for filelink so that it knows which server to log in to and how to authenticate.
These days, Apache on Linux usually has the directory /etc/httpd/conf.d. So in this directory, create the file webdav.conf with this content:
Otherwise, if you don't have the directory, then put that content into your httpd.conf file. httpd.conf is often found in the conf directory.
LimitXMLRequestBody 50000000
Alias /webdav "/home/httpd/webdav"
Dav On
Options +Indexes
IndexOptions FancyIndexing
AddDefaultCharset UTF-8
AuthType Basic
AuthName "WebDAV Server"
AuthUserFile /etc/httpd/webdav.users.pwd
Require valid-user
Order allow,deny
Allow from all
Note that you may choose to have your webdav directory something other than our setting (/home/httpd/webdav). You will need to create this directory:
- mkdir /home/httpd/webdav
- chown apache /home/httpd/webdav
- chgrp apache /home/httpd/webdav
- chmod 700 /home/httpd/webdav
Now you need to create the password file for authentication to the webdav service:
- htpasswd -c /etc/httpd/webdav.users.pwd myuser
- Repeat (1) for all the users that you which to grant access to, without the "-c" flag.
Open your httpd.conf. Check that it has these items in it:
- LoadModule dav_module modules/mod_dav.so
- LoadModule dav_fs_module modules/mod_dav_fs.so
# Location of the WebDAV lock database.
DAVLockDB /var/lib/dav/lockdb
- /etc/init.d/httpd configtest
- if all is okay: /etc/init.d/httpd restart
http://mydomain.com/webdav(of course you substitute your own domain name for "mydomain.com"!).
You should be prompted to for a username and password, enter the credentials that you created above (in the htpasswd bit).
If that works, then you are nearly there:
- Open up Thunderbird
- Edit->Preferences->Attachments->Add
- Choose "Webdav"
- In location enter: http://mydomain.com/webdav
- Enter your authentication and choose "remember password" when prompted.
- Click OK and you're done
- You entered the wrong username/password or the server entry isn't correct. This will generate authentication or server error messages in Thunderbird.
- The URL is recognised by Apache but it isn't the proper webdav URL. When this happens, Thunderbird tries and tries again for a long time, ultimately failing to authenticate.
From now on, when you create an email and put in one of more large attachments, Thunderbird will ask you if you wish to convert them into a link instead. You can also right-click on an attachment, choose "covert to" and then choose link.
NOTE: If, when you are composing your first email using a large attachment, your Thunderbird filelink keeps failing with "Webdav failed authentication", the chances are that your permissions are not correct for apache to write to the webdav directory on the server that you specified. Check your permissions! Thunderbird has already verified the logging in, so this is actually the wrong message being reported. Unfortunately, you probably won't see these permissions failures in the log files on the server either.
