Mail Forwarder allows you to receive mail from a domain that you own, and forward that mail (with optional spam and virus scanning) to email address(es) in other domains.
This is useful in many different circumstances:
If you host your DNS with KisoLabs (using Dynamo Advanced, Serv Advanced or Serv Pro), configuring your DNS is easy: Edit your zone and click on the button Add KisoLabs MX Records. The appropriate MX records will be added in the zone editor. Then save your zone configuration.
If you host your DNS with another provider, you must edit your DNS configuration using their tools. Add the MX records as described above under DNS Configuration, above.
Mail Forwarder allows you to add up to 250 email aliases to your domain. The alias is the part of the email address before the @ symbol, and any mail sent to that address at your domain will be forwarded to the destination provided.
For example, to have mail for hostmaster@yourdomain.com forwarded to me@example.com, set the alias to hostmaster and the destination to me@example.com.
The destination can consist of multiple email addresses seperated by semicolons. (For example, me@example.com;you@forinstance.net). Any email sent to the alias specified will be forwarded to the email address(es) listed in the destination field. There is no limit on the number of destination addresses per alias, but the total length of the field must be 255 characters or less.
For each alias, you have the option to turn on anti-spam and anti-virus. If your email host already has good spam and/or virus protection in place, there is usually no need to turn these features on.
When spam scanning is enabled, it will only prevent very obvious spam from being forwarded. All other spam (or possible spam) messages will be flagged as spam in the message headers, and will have *[SPAM]* added to the beginning of the subject line. This is done so that you will still receive messages that may be incorrectly marked as being spam, and so that you can set up your own filters or rules in your mailbox to quarantine spam messages.
If a message is flagged as spam, the sender will not receive a "bounce back" notifying them that their message was flagged as spam.
When virus scanning is enabled, messages in which a virus is found will not be forwarded. The intended recipient of the virus will instead receive an email notifying them of the infected message. The notification will include information about the original sender.
Once you have configured your DNS to point to the KisoLabs MX servers, it is recommended that you test your configuration. Make sure that you have given your DNS changes enough time to propagate, which could take as long as 24 hours (though likely your changes will propagate in under an hour).
Add a new alias to your configuration, and set the destination to an email address that is acessible to you. Leave the Anti-Spam and Anti-Virus boxes unchecked. If you are running your own email server, it's advisable to use a mailbox at a third-party email provider (e.g. GMail) for testing. This will rule out any problems with your mail server's configuration. Save your new alias and wait 5 minutes (at most) for your configuration to propagate to all the KisoLabs mail exchangers.
Send a test email to your new alias. Again, it is advisable that you send your message from a third-party email provider. The test message can be sent from the same account you used in the Destination field, but for complete end-to-end testing you should send it from another email account, if possible.
If you receive your test message at your destination mailbox then congratulations, your Mail Forwarder service is configured correctly.
If you did not receive your test message to the email address listed in the Destination field, check the mailbox from which you sent the test message: You may have received a "bounce" notification that will give you more information. If the bounce notification contains something to the effect of " Host or domain name not found" then your DNS changes have probably not propagated. If the bounce notification contains "Recipient address rejected" then your Mail Forwarder configuration may not yet have propagated to all of the KisoLabs mail exchangers. Wait a few minutes and try sending another test email. If the bounce notification containing "Recipient address rejected" persists, contact KisoLabs support.
If you did not receive your test message at your destination mailbox and you did not receive a bounce notification, check the spam/junk folders on both your sending and destination mailbox. If the messages are not there, send a test email directly to the email address listed in the Destination field. If that message gets through, but your original test message still has not, double check your DNS configuration and try again. If the problem persists, contact KisoLabs support.
Full text logs for your services are available here.
Mail logs are formatted as space-delimited files with quotes enclosing any field that contains a space as content. The general format of the log is as follows:
Each of the fields is described below:
| Field | Type | Description |
|---|---|---|
| Date Queued | date | The UTC date and time that the message was queued. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds |
| Date Last Processed | date | The UTC date and time that the message was last processed. If delivery could not be made
this date/time will be updated at every following delivery attempt. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds |
| Queue Id | hexadecimal (string) | The queue id assigned by the KisoLabs mail server. This value does not have any real meaning for the purposes of log analysis, but can be useful when working with KisoLabs' support team to resolve email delivery issues. |
| Message Size | integer | The size of the message in bytes. |
| Client IP | IP address (string) | The IP address of the SMTP client that relayed the message to the KisoLabs mail server. |
| Client Host | string | The host name of the SMTP client that relayed the message to the KisoLabs mail server. This is the host name reported by the client with the HELO (or EHLO) command, and does not necessarily represent the DNS entry that resolves to the Client IP field. |
| Message Id | string | The message identifier (this is usually generated by the first SMTP server to relay the message). The
message identifier should be globally unique, and therefore may assist you in debugging mail delivery issues. The KisoLabs mail servers will not alter the message identifier, but in rare cases it may be modified in transit by an upstream or downstream server. |
| From Address | string | The email address of the sender of the message. |
| To Address | string | The email address to which the message will be delivered. For services that forward messages, such as Forwarder and Instance Mail, this field contains the ultimate destination address (in other words, the address to which the message was forwarded). |
| Original To Address | string | The email address to which the message was sent, if different than the To Address field. For services that forward messages, such as Forwarder and Instance Mail, this field contains the alias address defined in your service's configuration. For all other types of service, this field will contain a single dash (-) to indicate that it is unused. |
| Status Text | string | The textual description of the status code representing the delivery status of the message. This field may not be populated until
the message is delivered to, rejected by, or a timeout is reached for the destination mail exchanger. If the field is unpopulated it will be represented by a single dash (-). |
| Status Code | integer | The status code representing the delivery status of the message. This field may not be populated until
the message is delivered to, rejected by, or a timeout is reached for the destination mail exchanger. If the field is unpopulated it will be represented by a zero (0). |
| Spam (Virus) Status | string | The status reported by the spam and virus filter. If spam and virus filtering are disabled on your service, or if
spam and virus filtering were not completed for a message, this field will not be populated. If the field is unpopulated it will be represented by a single dash (-). |
| Spam Hits | decimal | A number representing the strength of the assertion by the spam filter that the message is spam. The number is qualitative, so the general rule is that a higher number will indicate that the message is more likely to be spam. |
| Last Delivery IP | IP address (string) | The IP address of the host to which the message was last delivered. This will be the address of the next-hop SMTP server
when delivery is successful. Important: If the address shown is 127.0.0.1 that indicates that it was not delivered externally, and was re-queued by the KisoLabs SMTP server. This is not an error condition, and will always occur when a message is blocked as spam, or blocked because it contains a virus. It may also occur when a message could not be delivered and is awaiting redelivery, however in that case this field may also contain a dash (-). |
It is important to remember that the mail logs represent the transactional nature of the SMTP message workflow.
In other words, when a message is received by the KisoLabs MX servers, the receipt of that message is logged. The message is then (if your service is so configured) scanned by our spam and/or virus filters, which is also logged. When delivery is attempted, that attempt is logged (and may be logged multiple times). When delivery succeeds, that is logged as well.
The logs for your MX service are generated by aggregating all of those log messages into one line. As such, a log line (or log file) may be updated retroactively when a new event occurs. For example, the following may take place:
In that example, a log line will be written into your service's log file for 2012-03-15 showing that the email was received by KisoLabs' server, but will not show delivery having been made. Approximately 24 hours later, your services log file for 2012-03-16 will be generated, but that log file will contain no information about the email in the example. Instead, the log file for 2012-03-15 will have been retroactively updated to include the final delivery status.
For most KisoLabs MX services, email messages can be queued for up to 30 days. Therefore it is possible that a log file that is 30 days old may be updated with the status of a message.
In some cases, an ill-formatted email message will not be locatable across transactional steps. This is particularly common when the message is spam and does not contain a message id (or the message id is not unique, or is too short to be globally unique). In that case, the message may cause more than one line to appear in your service's logs.
For the sake of example, five log lines are shown below for the imaginary recipient domain example.com.
The meanings of each of the sample lines are discussed below:
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 10:56:28 PM UTC from bob@sample.com to matt@example.com. The message size was 1,292 bytes, and was relayed from 10.203.80.101 (having the host name of mx01.sample.com). It was relayed to 172.16.54.92 with status code 250 ("sent") on March 15, 2012 at 10:56:30 PM UTC. It passed spam filtering, and was not considered to be spam ("Passed" 0.2781).
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 10:58:14 PM UTC from fred@flintstones.org to barney@example.com. The message size was 2,173 bytes, and was relayed from 192.168.78.22 (with an unknown host name). It was relayed to 10.88.22.11 with status code 250 ("sent") on March 15, 2012 at 10:58:15 PM UTC. It passed spam filtering, but was considered to have some characteristics of a spam message ("Passed SPAMMY" 10.2032).
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:01:45 PM UTC from homer@evergreent.com to sales@example.com. The message size was 2,159 bytes, and was relayed from 172.16.250.33 (having the host name of mail.simpsons.net). It was relayed to 10.3.1.87 with status code 250 ("sent") on March 20, 2012 at 9:32:18 AM UTC. It passed spam filtering, but was considered to have some characteristics of a spam message ("Passed SPAMMY" 18.3999).
This line shows a case where a message could not be delivered to the next mail exchanger for almost 5 days (the difference between the Last Processed and Queued dates). This would usually represent an issue with your mail server where it was inaccessible when the KisoLabs mail exchanger attempted delivery.
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:02:25 PM UTC from wentworth@uwnto.de to gesundheit@example.com. The message size was 2,181 bytes, and was relayed from 10.58.244.148 (with an unknown host name). The next mail exchanger (e.g. your mail server) responded on March 15, 2012 at 11:02:25 PM UTC with the status code 550 ("rejected"), most likely because the recipient ("gesundheit@example.com") did not exist. It passed spam filtering, and was not considered to be spam ("Passed" 1.4420). Note that the last delivery IP address is shown as 127.0.0.1 because the message was not relayed.
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:03:01 PM UTC from lannister@westeros.net to tyrion@example.com. The message size was 5,129 bytes, and was relayed from 10.105.99.152 (having the host name of www.somesite.org). The message has just entered the system, and so there is no delivery status nor spam status.