Emaildrops

LiquidFiles has a functions for receiving emails using SMTP to the LiquidFiles system. We call this feature Emaildrops. The way it works is that recipients send emails to a specified email address like orders@liquidfiles.company.com, and any files attached will be processed similar to the LiquidFiles Filedrops feature.

Using Emaildrops instead of standard email provides the following benefits:

• Overriding Attachment Limits — Your standard mail server has a 20MB file size limit and you wish for a specific function to allow larger attachments. Using Emaildrops you can receive up to 100MB files. Or your standard mail server refuses to allow incoming .exe files and for some specific function you need to do that. By using an Emaildrop you can have different limitations and allow .exe files for a specific Emaildrop.
• Additional logging and scanning of the incoming email and who downloaded what and when.
• Bypassing the mail server for backup purposes. We had a customer approaching us with this specific requirement. They are an insurance company with many insurance brokers across the country. Each ensurance broken would fill out a document with the customer and then use a multifunction email scanner to scan and email a PDF with the filled in application. Each application was 3-4MB in size. Their email backup policy was to keep all emails backed up for 7 years. These one-time use scanned PDF applications, which had no backup value once they got typed in to the system was consuming terabytes after terabytes for 7 years. By using an Emaildrop instead, they didn't have to backup each attachment and save a lot of money by requiring less storage capacity for their backups.

General Configuration

Emaildrops uses standard SMTP to receive incoming emails. The only system configuration you need to do is to enable incoming SMTP, TCP port 25, in your firewall to the LiquidFiles system.

What Emaildrop address can I use?

If your LiquidFiles system is called liquidfiles.company.com, it's best by far to use something@liquidfiles.compnay.com as the Emaildrop email address (where something is anything that makes sense for this specific Emaildrop).
Sometimes we see a customer that tries to use something@company.com as the Emaildrop email address and this is a terrible idea. The reason is that mail servers on the internet work with fully qualified hostnames and domains only. It's not possible to say on the global Internet that joe@company.com should be delivered to mail.company.com and jane@company.com should be delivered to liquidfiles.company.com.
What happens when you tell a mail server to accept mail for @company.com, it will assume that all emails for @company.com should be accepted. In the LiquidFiles case, if you configure an Emaildrop for something@company.com it will try to deliver any email to @company.com to itself, or rather, you won't ever be able to send any emails from the LiquidFiles system to @company.com. Future releases of LiquidFiles will likely enfore the use of the LiquidFiles FQDN for Emaildrop emails.

What about MX records? They are not needed. With LiquidFiles Emaildrop feature, we're using a feature of SMTP emails dating back to the origin of SMTP and Unix when it was common for each Unix workstation to be directly connected to the Internet. Back then, it wasn't common to have centralized mail servers like today. Instead, it was common that each Unix work station had their own Sendmail SMTP server running and you'd have an email like flastname@workstation.university.edu, where workstation was your particular UNIX workstation that was directly connected to the Internet and flastname was your UNIX login on that particular workstation.
Or in technology terms, when trying to deliver an email for someone@liquidfiles.company.com, the sending mail server will first lookup if there's an MX record for liquidfiles.company.com. If there isn't, the mail server will lookup if there's an A record for liquidfiles.company.com and when there is it will use that to deliver the email, which is exactly what we want.

Multi-domain Limitations

When using additional domains with your Liquidfiles system, the use of Emaildrops are slightly limited. The reason is that SMTP does not have the equivalent of virtual domains same as HTTP/HTTPs does. With HTTP/HTTPs, we can use multiple FQDN's on the same ip address. Each HTTP/HTTPs will request a document with the FQDN and we can use this to have different domains, with different SSL/TLS certificates on the same IP address but with different domains. In the SMTP world, there's nothing similar. When connnecting to the Email server to deliver the Emaildrop, the hostname and certificate will always use the hostname and certificate of the default domain.

This can become a problem if say the default LiquidFiles domain is liquidfiles.company.com and the second domain is filetransfer.other.com. If you want to setup an Emaildrop for support@filetransfer.other.com, when the sending mail server connects to filetransfer.other.com it will present itself as liquidfiles.company.com and with the liquidfiles.company.com SSL/TLS certificate. A workaround to this issue is to configure a MX record that states that filetransfer.other.com should be dlievered to liquidfiles.company.com.

Please note that this issue is a generic SMTP issue and not LiquidFiles specific.

Emaildrop Specific Configuration

When adding an Emaildrop, you can configure the following: