https://man.liquidfiles.com
LiquidFiles Documentation

The purpose of the Filedrop is to provide an easy way for your customers to send files back to you. The Filedrop will give you a URL on your LiquidFiles appliance where users can send files without setting up an account and the files sent will be automatically delivered to a pre-defined user. Use cases for this includes:

System Filedrops

For the field report example, they could configure their Filedrop like this:

images/general/internal_external/working_with_filedrops/filedrop_1.png

This will give them a Filedrop URL of https://liquidfiles.springfield.com/filedrop/field_reports. It will look like this:

images/general/internal_external/working_with_filedrops/filedrop_2.png

Any message and file that is uploaded here will be automatically delivered to burns@springfield.com, as configured in the Filedrop configuration above. Please note a couple of things:

This type of system Filedrop is perfect for those organisation wide functions such as print jobs, for tender responses, for help desk and support issues and so on. In the next section, we'll look at user Filedrops.

User Filedrops

Many organisations wants to give their users the ability to use their LiquidFiles appliance to receive large files securely. Setting up individual Filedops for each user is a big pain, which is how the user Filedrops came to be.

User Filedrops are configured on a per Group basis, meaning that you can configure certain groups that have access to user Filedrops, and other groups that don't, or have access to user Filedrops with different configuration and so on. If you require further customization, you will have to use the system Filedrops as opposed to the user Filedrops.

This is the configuration section relating the user Filedrops in the Admin → Groups configuration screen:

images/general/internal_external/working_with_filedrops/filedrop_3.png

There are two types of user Filedrops URLs. One with a random string (each user will have their own random string), and one with their email address in the URL. The one with the email address is obviously a nicer URL, but some organisations are worried about a potential attacker being able to discover which email addresses respond with a valid URL and which one won't. Done successfully, this will give the attacker knowledge of all valid email addresses within the local domains. You can enable either random or email URL Filedrops, or both.

You can then either select accepted or blocked file types, if you select accepted filetypes, only those will be accepted. If you select blocked, everything else but the blocked ones will be accepted.

All files sent in the Filedrop will expire after 14 days and the maximum size for an individual file is 250Mb.

Since there is no way of knowing the random URL, each user will have to visit the account setting on the LiquidFiles appliance, where it will look like this:

images/general/internal_external/working_with_filedrops/filedrop_4.png

In the Filedrop section, the URL for this user is listed.

The actual screen will look identical to the system Filedrop. The only difference being that it will display who the Filedrop is for, and same as for the system Filedrop, the user will receive the notification that the files are available to download.

This setup is perfect for a lot of companies, where a lot of staff has the need to send and receive files securely. The staff can post their individual Filedrop URL in their email signature, on their business card, post in forums, or anywhere where they want to give someone the ability to send them files.

About the email notification

One thing that sometimes cause a little bit of confusion is the notification email. Lets say that burns@powerplant.com has a Filedrop, and kent.brockman@news.com send him a file. The email header that will be sent will look like this:

From: kent.brockman@news.com <support@powerplant.com>
To: burns@powerplant.com
Reply-To: kent.brockman@news.com
....

 The unexpected part of this, is that the actual from email address in this email is support@powerplant.com, which is the configured system email address for the LiquidFiles appliance at powerplant.com. The reason for this is that we want to make sure that burns@powerplant.com receives the message. We have to make sure that the receiving mail server will accept the message:

The last issue could be fixed in the mail server at powerplant.com, but probably not the first one. We will save ourselves a lot of headache if we don't trust what the sending user has entered as their email address.

Also,  if you look in the headers you can see that the Reply-To header is set to burns@powerplant.com in this example so when Burns hits reply to this message, the To address will be set to kent.brockman@news.com so in reality it's not really an issue.