If you are in the field and just need to get SMTP forwarding working as quickly as possible, first try the step below. If your SMTP forwarding still fails, or you simply would like to understand SMTP forwarding and DNS more deeply, continue on to the rest of this article.

1) Make sure the mail domain name set in AltiAdmin is different from the client's Windows domain. If it's the same the server will assume that it is sending to itself, and will not try to forward the VM. You can set it to any valid domain that's different form the client's domain.

A common question is, “why am I not able to forward voicemail to email?” The most common reason for this is that DNS is not set up correctly. Often times in addition to multiple records needing to be created, there are several places that DNS records need to be set. I’d also like to note that rarely is the SMTP service on the AltiServ not functioning properly. Although it is certainly possible that this service is having a problem, it is very simple in nature, well over 95% of the time the problems are due to the aforementioned DNS settings and/or spam filtration. This document is not intended to give instructions on how to configure a DNS server. Rather it is intended to give examples of what to look for to determine if DNS is set up properly. The examples I use here are for the BIND DNS server, simply because that is what I use. Also be aware that I’m generalizing some of the DNS overview. There is a wealth of information about this that can be obtained easily online. Much of this is outside the scope, and requirements of this document. This document uses real examples from my own internet domain, please treat it with respect. Thank you.

First, a bit of background on DNS. DNS stands for Domain Naming System, and is the way that computer names (such as altigen.com) are converted to IP addresses. It can also be used for converting IP addresses to names. There are several “types” of DNS records that are exist. We are concerned with three different types of record: A, PTR, and MX.

An “A” record is the simplest to understand. It is simply a record that matches a name to an IP address. To test this open a command shell and type the following:

nslookup yahoo.com

Your results should look something like this:

There are several things to note here. The first two lines returned give information about the DNS server that you are receiving the information from. First it gives the name of the server (in this example homer.whosgonna.local), as well as the DNS server’s IP address. This will be followed by a blank line, then the results of the query. The “Non-Authoritative” line indicates that my name server is not the nameserver on which yahoo registers it’s records. This is not surprising. The name line is the server that we’re looking for (sometimes you’ll see a more complete name here than the one you entered). The Address line gives the matching address(es) for the name. Yahoo is a very big company, it’s not surprising to see multiple addresses. For most small businesses, there will be only a single match. So lets look at a “small business” type environment.

This is the A record for my domain. Here’s the A record for my AltiGen:

Notice that the domain ends in .local, rather than .com. I do this because I use NAT, and don’t want my hosts resolving out the .com domain name. This may not be the way that your particular network is set up. There are many valid ways to do this.

PTR records
PTR records are commonly called reverse records. They are used to convert an IP address to a name:

Or:

*Above my local DNS server timed out- I don’t maintain records for public IP addresses, not even my own, on my local server. However the last line still shows the correct result. This is because it is retrieved like any other internet address.*

MX record

An MX record is a “Mail eXchanger” record. Please do not confuse this with Microsoft’s Exchange server. Quite often you will see mail handled by a server such as mail.domain.com, but the user will have @domain.com as their mail suffix. MX records are the way that the sending server knows to send mail for domain.com to the mail.domain.com server. Sometimes this resolves to the same public host, but different machines behind a NAT firewall. Other times this may resolve to remote servers for the purpose of spam filtering before they are sent to the local mail server.

*My MX record here shows that my mail server is homer.whosgonna.local. The last three lines refrence where the results came from.*

The examples that I have been giving are when using the DNS server on my LAN. I will have different results if I use a DNS server that is on the internet. I will get the same record for my domain. My AltiGen server will not show up (it has the .local suffix), and my MX record will then point to my public IP address.

This is how it resolves on the public internet.

Putting this together.
So now that we’ve covered these three types of records, we should now be able to understand how where the mail gets sent. If a host needs to send an smtp message, it first looks for the MX record, then resolves that name to the IP address. Depending on the host that is sending, and where on the network or internet it is located, these results can (and should) vary. If I’m sending something to whosgonna.com on my LAN, then the message should be routed to homer.whosgonna.local, which resolves to 10.9.8.9. If I’m sending from somewhere else on the internet, then the message should be sent to whosgonna.com, which resolves to 63.231.250.54.

Since the server that is sending this needs to be able to resolve the name properly, it needs to be verified from the sending server. This is very important to rememeber when troubleshooting.

Applying this to the AltiGen server.

First, be sure to that you have enabled SMTP/POP3 services in AltiAdmin:

Now, is it important what name you have as the mail domain? Technically it isn’t, but in practice it is. Long ago, mail servers would openly accept mail from any server, and didn’t bother to check if it was being received from a valid mail server. Spammers have since ruined that system, and any mail server that will accept mail from just any old server should not be considered secure. With that said, this name should have an MX record that is resolvable on any server that it will be sending mail to. More on that in a bit.

One more very important note here: The “Mail Domain Name” cannot be the same as the domain of an email address that you are forwarding mail to. In the example above, the Mail Domain name is max1000.whosgonna.com. This means that if my email address were user @ max1000.whosgonna.com that the mail would never reach me. Why? Because it will try to deliver the mail LOCALLY. There will also be no record of this in the smtplog. This is because mail transferred between extensions is not handled by the smtp service.

We covered the basics of how to check this above. If I want to forward mail to my own @whosgonna.com domain, then I need to make sure that the AltiGen server is able to properly identify the mail server that it is sending to. Here are the results when running nslookup commands on my AltiGen:

The line “whosgonna.com MX preference = 10 mail exchanger = homer.whosgonna.local” tells me that mail that is addressed to @whosgonna.com addresses should be delivered to homer.whosgonna.local.

Once I know this I can then lookup homer.whosgonna.local:

One note about these examples. homer.whosgonna.local is also my DNS server . The first two lines indicate which server is the DNS server. The lower two lines are the output giving me the IP address of the server I’m looking up.

So, you’ve got this set up, and all is good to go, right? Again, technically that is correct, but VERY few mail servers will accept mail from servers that don’t have an MX record as well. This record shou ld match the sending domain field. This is the “Mail Domain Name” field we entered in AltiAdmin, in our case, max1000.whosgonna.com. We can use the same checks, but this time running the commands on the mail server.

The MX record for max1000.whosgonna.com is max1000.whosgonna.local

And:

max1000.whosgonna.local resolves to 10.9.8.53.

The mail server can tell what IP address it is receiving the SMTP message from. Usually the server will check to make sure that the name in the MX record resolves to the IP address that is sending the mail.

If all this is good, the message has a very high likelihood of being delivered properly. I say very high, because there are MANY anti-spam measures that may still be preventing this, and configuring all of them is outside the scope of this document, and AltiGen tech su pport in general.

One of the more common anti-spam measures that can easily be checked for, and addressed through DNS is a reverse DNS check. In this scenario, the mail server also checks to make sure that the IP address of the sending server has a PTR that points to the same name that the MX record resolves too, so you should be careful to make sure that this resolves properly.

Yes, 10.9.8.9 has a PTR record that points to homer.whosgonna.local. This matches the MX record.

Many times, the spam filter will also check against lists (such as spamhaus.org) to see what the sending address is. If it is a private address, such as this one, the spam filter may discard the message. Recently yahoo has stopped accepting mail from all addresses that are listed as being dynamically assigned by the ISP. This will make it increasingly hard to forward mail if your customer is using a dynamic public IP address.

Testing
Ok. How do we start checking the ACTUAL delivery? Lets start by making sure that the extension is set up properly. On the mail management tab of the extension configuration be sure that you have the “Enable Mail Forwarding” box checked. In the example below I am deleting messages on forward. You may wish to do this diffently. Enter the desired email address in the “Forward E-mail Address” box.

Make a test call, and see what happens. Mine was successful, and I now have a .wav file of the message in my email:

Lets look at the log file to see what we can learn. I had turned on trace before I left this message. After leaving the message wait a few minutes then press the “VM & SP Log Dump” button on trace window to write the trace to C:\AltiServ\Log\VM\smtpserver\smtpserver.log. Here are my results:

At 16:26:45 we can see the AltiGen query the DNS server. At 16:26:50 it connects to the mail server. We can then see the actual SMTP transaction take place. This transaction ends six seconds later with a status of “SUCCESS”.

So what happens if the server can’t find an MX record for the domain that it’s sending mail to. Here’s when I send to user@office1g.whosgonna.local. This is another host on my network, so DNS will find the server, but there is no MX record for it. You can see below that the AltiGen keeps trying to send it, but never resolves the address, and therefore doesn’t know where to send it.

We can verify this by using an MX lookup for office1g.whosgonna.local. We can see that the DNS server has a record for the domain, but that it does not contain an MX record for the server.

If you run this command on the AltiGen, and are unable to detect the MX record of the domain that you are trying to send mail to, then your voicemail forwarding to email will fail.

Here’s an example of what you could see if the sending domain cannot be found by the receiving server: