Email Delivery Configuration — Direct Delivery
When it comes to Direct Email delivery, from a LiquidFiles configuration perspective, there really isn't a lot to it.
The only thing you really need to configure on the LiquidFiles system itself is the Email Sender Adress. Please see the Email Overview page for more information about the email sender address.
The rest of the configuration happens outside of LiquidFiles. First, lets look at a simple diagram:
For direct delivery, lets say that we're sending a message to homer@simpsons.com. The following steps will be taken.
- Query the DNS server for the MX record for simpsons.com (in english the query would be: which is the email server that I should deliver emails to for the domain simpsons.com?)
- The DNS server responds with an IP address (both a name, like mail.simpsons.com, and the ip address for mail.simpsons.com to be precise).
- The LiquidFiles Appliance connects to the ip address in the DNS response and tries to deliver the email to the corresponding mail server using SMTP (TCP Port 25).
From an overview perspective, could not be any simpler.
Outside Configuration — Firewall
In your firewall, you will need to make sure that the LiquidFiles system can lookup DNS so that it knows where to send the emails, and to allow outgoing SMTP (TCP Port 25) anywhere.
Outside Configuration — DNS
Reverse IP Lookup
For any outside SMTP delivery, you will need to make sure that you have configured your DNS, or your ISP's DNS with a reverse lookup name that matches the hostname of the LiquidFiles system. Lets say that your LiquidFiles system is called, liquidfiles.company.com and has the public IP address of 192.1.2.30. That means that when a receiving mail server receives a connection from the LiquidFiles system, it will come from IP address 192.1.2.30 and it will identify itself as liquidfiles.company.com. The first thing that the receiving mail server is going to do is to do a reverse lookup and see, what name does the IP address 192.1.2.30 belongs to. If it doesn't say liquidfiles.company.com there's a big chance all your emails will be marked as spam.
The easiest way to do a reverse IP lookup is to use Reverse Lookup Tool from MX Tool Box.
As an Example, lets lookup the IP address 1.1.1.1.
And it will display the result:
In your case, when you enter your external IP address for your LiquidFiles system, you will need to configure your DNS so that it displays the name of your LiquidFiles system, similar to how 1.1.1.1 is looked up as one.one.one.one above.
If you don't know how to configure your DNS server to do this, please consult either your Network Administrator, the documentation or the support of your DNS server or provider.
Sender Policy Framework — SPF
On the topic of DNS configuration, while reverse IP lookup is an absolute must these days, SPF is only a must if you already have SPF configured.
What SPF does is that through DNS, you can tell the world which email servers they should expect emails to be delivered from. For instance, you can say that you should only accept emails for the domain @example.com from the IP 20.30.40.50.
If your email servers public IP address is 20.30.40.50 and your LiquidFiles system is 20.30.40.51, you would need to update your SPF records to say that for the domain @example.com you should expect connections from both 20.30.40.50 and 20.30.40.51.
We can use MX Tool Box SPF Lookup to see the result of your current SPF configuration:
And if you dont' know how to configure SPF, you can do a web search for SPF Generator.
Outside Configuration — IP Addressing
The next thing you will need to consider when trying to send emails is your IP address reputation.
One of the first lines of defense for spam/malware protection for email servers is IP black lists. If a lot of spam or malware has been detected as being delivered from an IP address, it will likely be added to one or more IP black lists.
Please note that this might not even have been you. We have seen instances where an ISP reassigned a previous company's IP address range to a new company and the new company will get stuck, or at least started, with the previous company's IP reputation.
Let's use MX Tool Box Blacklist tool to see how it looks:
Gives the following result:
As you can see in this list, there are many IP black lists. Not every email server is going to use all or even most of them. And likely if your listed on one, you're going to be listed on a few.
There's almost no chance that a mail server that is listed on the black lists above is going to have any success delivering emails to any but the most loosely configured email servers.
If your result looks like that, depending on exactly why you're listed, you may be able to fix the issue and update the black list services to have your IP address removed. It is definitely something you will need to examine if you experience any form of email delivery issues with LiquidFiles or any other Mail Transfer Agent (mail server).
Troubleshooting Direct Email Delivery issues
As you can see with the configuration options above, there's almost nothing that can be done within LiquidFiles itself, as there's almost no actual configuration in LiquidFiles when it comes to Direct Email Delivery.
If you experience issues, there's two good places to look at. The Admin → System → Email Queue, and the Admin → System Log, filtering on Email.
The Email Queue
In the Admin → System → Email Queue, you will see something like this:
If you see any emails in the Email Queue, that means that they haven't been able to be delivered. You will also see an explanation in the Info field why this particular email hasn't been able to be delivered.
Often these errors are pretty self-explanatory if you have experience troubleshooting Internet network related issues. Typically the errors will be something along the lines of:
- Connection Timed Out — meaning that a firewall or similar has blocked the connection.
- Connection Refused — meaning that the connection was permitted by any firewall but blocked by the server it was trying to connect to. Best guess would be incorrect hostname or IP address for the email relay server.
- Lookup Error — meaning that the LiquidFiles system could not lookup the hostname using the DNS server you've configured.
- Permission Denied — meaning that the Email server in the other and did respond but refused the email. This means that there's something wrong in either the configuration in the LiquidFiles end (most email relay servers require that you use the same Email Sender Address as the Email Relay username), or in the other end (you need to enable email relay from the LiquidFiles system).
Also, please note that SMTP or Internet Based Email systems have builtin resiliency and just because an Email is listed in the Email Queue it doesn't always because of a problem. There could just as well be a temporary routing issue, connection issue, power outtage, reboot of some network equipemnt or the recipient email server that is causing the connection to fail temporarily. If it does, the email will be queued for a while and then a redelivery will be attempted.
When there is an issue though, it will be listed here with the email it's trying to deliver. In the example in this screenshot, there's a timeout issue so the first guess would be that there's a firewall blocking the connection to 10.0.0.4.
The Email Log
In the Admin → System Log, filtering on Email, is the Email Log. Every email delivered or with a temporary and permanent failure will be logged here.
When we look at the Email Log, we're basically looking at response messages and response codes for each email.
Responses
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 recipient 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 homer@simpsons.com in the simpsons.com domain).
In all of these cases, the Email Log is your friend.
The Email Log details
In the Admin → System Log, and filter on "Mail", we can see all emails and all their response codes. An easy way is to search on the recipient email address to see what's happened with a specific email. If you search for "home@simpsons.com" and see the following:
Aug 31 03:20:36 liquidfiles postfix/smtp[3110]: 77424110EA2E: to=<homer@simpsons.com>, relay=mail.simpsons.com[53.11.22.33]: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)
You can see the important thing: 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 mail.simpsons.com 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=<28@huash.com>, 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 name=huash.com 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[206.72.127.113]: 450 4.1.8 <PureNaturalHealth-ttmhhk1pldkkglj1r@createsend3.com>: Sender address rejected: Domain not found; from=<PureNaturalHealth-ttmhhk1pldkkglj1r@createsend3.com> to =<test@liquidfiles.com> proto=ESMTP helo=<mo113.createsend.com>
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.
Connection problems
If you see log lines similar to the following:
C539144A9: to=<joe@company.com>, relay=none, delay=3.1, delays=0.02/0.07/3/0, dsn=4.4.1, status=deferred (connect to 172.16.5.101[172.16.5.101]: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.
Mail server configuration incompatibilities
In some cases you can see a log entry like the following:
CC79325EE20: to=<joe@company.com>, relay=172.16.5.1[172.16.5.1]:25, delay=5963, delays=5963/0/0/0,
dsn=4.7.0, status=deferred (SASL authentication failed: server 172.16.5.1[172.16.5.1] 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 joe@company.com and send an email from bob@company.com. 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.