A MailExtension for Thunderbird (68+) that uploads large attachments to your Cloud and generates a link you can send by mail instead of the file.
Thunderbird: 68.2.1 or newer
An account on a server running a supported version of Nextcloud or ownCloud, more specifically:
If you can't or don't want to run your own server, there are many offers for hosted Nextcloud and ownCloud services.
*cloud is also available via Thunderbird's Add-on repository: *cloud - FileLink for Nextcloud and ownCloud.
After you have configured at least one Nextcloud or ownCloud server there are three ways to start the upload:
Many users would like to change the text that is inserted into the message along with the download url, eg add the expiration date, change the cloud service link, remove some of the text or style the HTML less prominently. Addons like *cloud have no chance to do that, because the template text surrounding the url is part of Thunderbird. The Addon only supplies the url, Thunderbird wraps its template around it and inserts the whole thing into your message (technical details here and here).
There is a feature suggestion for Thunderbird, to make this template editable. You might consider backing this suggestion with your vote or a helpful comment.
There was a bug in Thunderbird: If you attached a file from a network share, it was uploaded to the cloud and the share link was inserted into your mail, but the file was also attached to the message. This was fixed in Thunderbird 68.11.0 and 78.0.1. If you're still experiencing this issue, update Thunderbird.
In some situations the url you use to access your Nextcloud/ownCloud account in the browser doesn't work as the server URL in *cloud.
If your access url is redirected to the actual cloud location (plus some technicality), *cloud can't find the actual url.
If this happens to you, point *cloud to the actual cloud location:
When you save the settings, *cloud will remove unnecessary parts.
If the admin of your cloud used something called a "self signed certificate", Thunderbird (not *cloud) refuses to connect to the server. There are two solutions:
The download password has to comply with all the rules for passwords on your cloud, otherwise the upload will fail. There are default rules of Nextcloud and ownCloud, and your admin might have configured some different rules.
This is usually caused by a misconfiguration of your cloud server. Please point your cloud admin to the section on Apache and mod_rewrite below.
If things still don't work, I'd appreciate a problem report by email. Thanks.
Every new *cloud account you confire is called "*cloud" by Thunderbird. It's easy to give it a more useful name like "My Nextcloud":
Now the name is editable.
In some older versions of Thunderbird it's also possible to right-click the account name and choose "Rename" from the context menu.
If you use download passwords, never put them into an email, but give them to the recipient via a separate, secure channel eg a messenger or a telephone call.
Why? As a security measure the generated download links contain a long, almost random part. So an attacker (let's call her Eve) can't guess the link for a file or scan all possible links to find a file. The only reasonable way for Eve to gain access to your file is to intercept the mail. (If you are interested in technical details, read this posting).
So the links are fairly secure by themselves and quite comfortable for the recipient, because she only has to click the link.
If you use download passwords, never put them into the same email as the link. Because if Eve can read the link, she can also read the password. So a download password in the same email doesn't make the transfer more secure, but only more complicated for the recipient. The same goes for a separate email with the password: If Eve can intercept the first email with the link, she is very probably also able to intercept the second email.
Instead of storing your password it's more secure to use an "App Token" with *cloud. There are two ways to get such a token:
If you are using Nextcloud or ownCloud: Open your account in the browser and go to Settings -> Security -> App Token and at the bottom of the page generate a new token. Copy&paste it into the "App token" field of the Attachments preferences page in Thunderbird.
Only if you are using Nextcloud: Type your user password into the
Attachments/Outgoing preferences page in Thunderbird. Upon saving, the Add-On will
try to get a token from your Nextcloud and use it instead of your password.
You will notice the change, because afterwards the password field is filled
with dots completely (app tokens are quite long).
BUT! if getting the token fails for any reason (e.g. your Nextcloud is not
reachable, timeout, wrong username, ...), the Add-On will store your password
unencrypted.
If you attach a file that's already in the attachments folder in your cloud with identical contents, that file is not uploaded again. Instead the existing file is shared.
To make this possible, *cloud never deletes files in your cloud. Over time your attachments folder may grow to considerable size. It's safe to delete old attachments. Your admin may automate that, using "Flows" in Nextcloud or ownCloud.
You can use this behavior if you want to share large (or many) files: Sync your attachments folder to a folder on your computer using the desktop client. If you then attach a synced file from your computer to a message, *cloud will notice that it's already uploaded.
If you attach a file with the same name but different contents as a cloud
file, the cloud file will not be overwritten. Instead *cloud moves the
existing file to a subfolder of the attachments folder; the original share
link will remain valid and point to the old content.
Then the new file is uploaded and shared with a new share link.
*cloud uses the same method as the Nextcloud/ownCloud desktop clients to decide if the local and remote files are identical.
Some settings in Nextcloud/ownCloud are relevant for this Add-On:
Nextcloud and ownCloud both require mod_rewrite to be active in the Apache http server. Without mod_rewrite *cloud fails with different error scenarios depending on other details of the configuration.
In some configurations a start url like https://cloud.example.com
is
redirected to the actual url of the cloud eg https://example.com/cloud
.
*cloud has to access many different paths below this url, eg. status.php
.
If these are not also redirected (https://cloud.example.com/status.php
->
https://example.com/cloud/status.php
), *cloud can't access them and
doesn't work. There is no way for the extension to find the actual base url with
some certainty.
There is a workaround: Users can find out the actual url and configure it in *cloud. But it's easier for users if all urls are redirected. So it would be greatly appreciated if you would do that in your cloud instance (if you have to use redirects at all). Thanks.
By default Thunderbird (not *cloud) refuses https connections using self-signed certificates. It's a lot easier for your users, if you install a Let's encrypt certificate. There are great How-tos on their site.
The project lives on GitLab: https://gitlab.com/joendres/filelink-nextcloud.
If you find a bug or have an idea for a feature:
There usually are two development versions of *cloud:
These versions usually are more or less functional. They have corresponding branches in the repository.
All other branches are work in progress and guaranteed not to work
If you'd like to help with testing, first install one of the development versions:
If you find a bug please use one of the options above to report it.
Localization of *cloud happens on Crowdin. If you'd like to help translate *cloud into your language, just click on the link and go ahead.
If Crowdin seems too complicated or if you are more familiar with another method of translation, just send me an email or open an issue.
If you'd like to fix a bug or implement a feature
firefox
config option to your thunderbird binary.