LiquidFiles Documentation

When it comes to email delivery, there are two basic methods of delivering emails, either we send emails through a email relay, or we send direct. Please see the following diagram.


Direct Delivery

For direct delivery, lets say that we're sending a message to The following steps will be taken

  1. Query the DNS server for the MX record for (in english the query would be: which is the email server that I should deliver emails to for the domain
  2. The DNS server responds with an IP address (both a name, like, and the ip address for to be precise).
  3. The LiquidFiles Appliance connects to the ip address in the DNS response and tries to deliver the email.

Mail Relay Delivery

In the case of Mail Relay Delivery, sending a message to, the following steps will be taken:

  1. The LiquidFiles Appliance delivers the email to the configured email relay server.
  2. The email relay server will lookup DNS and send the email to the recipient.


When we're delivering the email, there are only three types of responses:

  • 2xx Ok – Message has been delivered successfully
  • 4xx Deferred – Message has not been delivered with a temporary failure
  • 4xx Rejected – Message has not been delivered with a permanent failure

All we're aiming for is to get a 2xx (200-299) Ok message. This means that the mail server has accepted the email for delivery. Now, this doesn't actually mean that the email will be delivered. The email server could at this point apply spam filtering, or other types of filtering, and decide to discard the email silently or not. If it's silent, we will never know what happened and why. If it's not silent, it means that a mail bounce message will be sent back to the sender. This is usually from "Mailer Daemon".

A 4xx temporary (Deferred) failure could be anything from the recipients mailbox is full to be part a spam catching technique called greylisting. What happens with temporary failure is that the LiquidFiles appliance will queue the message and try to deliver again. After retrying for a couple of days, the LiquidFiles appliance will delete the message and send a bounce message (from Mailer Daemon) that the message could not be delivered.

A 4xx permanent (Reject) failure means that the receiving mail server is not accepting the message at all. This could be anything from that our sending ip address is in a list of addresses that the receiving mail server things is from a known spammer (or home network), to that the email FROM address is invalid, or that we're trying to send to an non-existent email address (there's no email address in the domain).

In all of these cases, the mail log is your friend.

The Mail Log

The by far best way to troubleshoot mail delivery problems is by looking at the maillog. In the LiquidFiles appliance, this can be done in the Admin → System Log, and filter on "Mail". Then we can search on the recipient, to see what's going on. Please see the following:

Aug 31 03:20:36 liquidfiles postfix/smtp[3110]: 77424110EA2E: to=,[]:25, delay=1.3, delays=0.07/0.04/0.64/0.52, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 8A798694DF5)

In this example, the important thing to notice is the status=sent followed by the code 250 2.0.0 Ok. Any code with 2xx means that everything went as expected.

At this point, there's nothing more that can be done from the LiquidFiles appliance point of view. It should now be delivered to the end user. But if it isn't, it's because a receiving mail server up the path is not delivering it. If the message does not appear, it would have to be troubleshooted, first in the email server.

Warnings and Errors

An Example warning (temporary failure would look something like this):

Aug 31 08:05:32 mail postfix/smtp[15549]: 3BC7F31A2E1: to=<>, relay=none, delay=191801, delays=191726/0.19/75/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for type=MX: Host not found, try again)

And example reject something like this:

Aug 31 08:03:01 mail postfix/smtpd[20893]: NOQUEUE: reject: RCPT from unknown[]: 450 4.1.8 <>: Sender address rejected: Domain not found; from=<> to =<> proto=ESMTP helo=<>

In the warning (status=deferred), the domain seems to exist but not the actual host. In the error, the message is being rejected because the domain does not exist.

The important thing here though is that by looking at the log, it's possible to see why the message was rejected. By searching on the recipient in the System Log, we're able to see what's going on for that specific email address.

Typical problems

Invalid Sender Email Address

In the LiquidFiles Appliance, messages from a user will either have the Email From Address the users email address, or all emails will use the Email Sender Adress if configured as in the following screenshot.

System generated emails (password resets, signups, ...) will always use the Email Sender Address in the Admin → Configuration → Email Settings.


If you set this address to something like noreply@mydomain.local, we can pretty much guarantee that no mail server on the Internet is going to accept any emails from you. Please set this address to a valid email address and these messages will have a much higher chance of being delivered.

Incorrect Network Settings

In this area falls everything from an incorrect default gateway, incorrect DNS server, incorrect firewall permissions. Please make sure that you have the correct settings for your configuration, and that the firewall allows the connections through. The firewall logs is also a good place to look when troubleshooting connection problems.

Incorrect Email Relay parameters

When it comes to troubleshooting email relay, again the mail log is your friend. Please go to Admin → System Log and Filter on Mail.

When everything has gone correctly, you'll see log entries similar to the following:

F1CDD3F8D: to=<>, relay=[]:1025, delay=326, delays=325/0.04/0/0.16, dsn=2.0.0, status=sent (250 OK)

In this log, there's two important things in regards to relaying, first you can see the relay= section which is where the email relay server that the email has been delivered through. And the other is in the end, where you can see status=sent, meaning that the email was delivered correctly.

Connection problems

If you see log lines similar to the following:

C539144A9: to=<>, relay=none, delay=3.1, delays=0.02/0.07/3/0, dsn=4.4.1, status=deferred (connect to[]:1025: No route to host)

The two things to note here is the status=deferred, meaning that the message could not be delivered but that LiquidFiles will try to redeliver this email again. The other thing to note is in the end where No route to host, meaning in this case that the LiquidFiles system could not find a way on the ip network to connect to the specified system.

Authentication problems

Authentication problem between the LiquidFiles system and the email relay host looks like the following:

A0AB78009A: to=<>, relay=none, delay=10, delays=0.03/9.9/0/0.01, dsn=4.7.3, status=deferred (delivery temporarily suspended: SASL authentication failed; server[] said: 535 5.7.3 Authentication unsuccessful)

In this case, the username or password entered was not correct. The log section to focus on is first that status=deferred again and the last section which says Authentication unsuccessful. This should just be a matter of making sure that the username and password is entered correctly in the admin → Email configuration.

Mail server configuration incompatibilities

In some cases you can see a log entry like the following:

CC79325EE20: to=<>, relay=[]:25, delay=5963, delays=5963/0/0/0,
dsn=4.7.0, status=deferred (SASL authentication failed: server[] offered no compatible authentication mechanisms for this type of connection security)

Most of the time the problem in this case is that the email relay host refuses to authenticate connections without TLS. So if LiquidFiles has been configured with an Delivery Security Level of None you won't be able to use authentication.

In the email relay delivery scenario, the LiquidFiles system is the client and the email relay host is the server. Often the server will only give a very generic error and you will have to look in the email relay servers log to find the real reason, in which case you may see something like "Authentication attempted without TLS enabled" and similar. This troubleshooting needs to be done on the server.

The easiest solution is often to permit the LiquidFiles system ip address to relay emails without any authentication. And on the LiquidFiles system you can try to enable TLS if it's disabled, and also disable it (Delivery Security Level None) if it is currently enabled. On the client side, there's always going to be a bit of guesswork and we have to look in the server to find the real problem and consequently the real solution.

Most modern mail servers won't allow you to connect to it as and send an email from The LiquidFiles Appliance needs to be able to send an email from anyone, since anyone could have a remote account and send an email to an internal user. This means that with a email relay, we need to configure it to allow us to send messages with any From address. The easiest configuration is to specify that the ip address of the LiquidFiles Appliance shouldn't have any restrictions. Internal firewalls and similar will take care of the necessary internal security for this not to be a problem anyway.

For Microsoft Exchange, please see this FAQ article: Relay Outgoing Emails with Microsoft Exchange.

A different approach all together is to get a dedicated SMTP relay service. This would be the best option if you're LiquidFiles Appliance is reciding on what's considered to be a "home" ADSL service, or if you're running the Amazon EC2 version of the LiquidFiles Appliance. Please see this FAQ article for more details around that: Relay Outgoing Emails with ElasticEmail.