Home | Antispam Software | Support | About Tiki |Contact | Admin Login | End-User Login

Step 4: Post-Setup

A. Point The MX Record To The Scora Server
B. Block spammers from your mail server (optional)
C. Enjoy less spam!

 

A. Point The MX record To The Scora Server
It is important to note that this section should be performed only *AFTER* you have completed steps 1-3. Prematurely pointing your MX record to the Scora filtering server prior to completing the configuration will cause mail sent to your domain to be delayed and possibly bounced as undeliverable. In such cases, the Scora filtering server will tell other mail servers to try sending messages again later. The number of attempts a sending mail server will make before it gives up will vary from server to server and is controlled by the sending servers's administrator, not by Scora. Please contact Tiki Technologies Support if you have any questions.

As mentioned in the pre-setup guide, it is strongly recommended that the Time To Live (TTL) value for your domain be set to a very low value such as 5 minutes at least 1-2 days prior to updating your MX record. This will help to minimize any delays due to DNS propagation issues.

1.Once you have completed sections steps 1-3 and you are ready for Scora to start processing your email, you need to update an MX record for your domain to point at the Scora service.

If you host your own domain name, then you will need to make the MX change yourself. Otherwise, you will need to forward the request to your domain hosting company. If you're not sure who hosts the DNS for your domain, you might be able to track down more information by doing a Whois query on your domain. This is one web page you can use to do a Whois query (simply type in your domain name without "www"):

http://www.geektools.com/whois.php

You or your domain hosting company needs to change the MX (Mail eXchanger) record with the smallest "preference" value (the final destination MX) to point at "scanner01.tikitechnologies.com". If the domain host is using the standard BIND file format it might look like this before the change:

example.com.  300  IN MX 5  mailbox.example.com.

and like this after the change:

example.com.  300  IN MX 5  scanner01.tikitechnologies.com.

At this time you might also wish to reset the TTL for the MX record back to the default value, or you may choose to leave it at 5 minutes until you have put the product through its paces. If you did not reduce the TTL in advance, it may take a day or two for you to see the full effects of the Scora filtering.

If filtering does not commence within 1-2 days or if email sent to your domain becomes undeliverable during this period, the change to the MX record may been done incorrectly. Please contact your DNS host first to ensure that they have the correct MX record. Should you require further assistance, please contact Tiki Technologies Support.

24 Hour Phone Support, Monday-Sunday
-Phone: (808)532-1380
-Email: support@tikitechnologies.com

B. Block spammers from your mail server (optional)
After you have changed the MX record and the DNS change has propagated, most email traffic (including spam) will be filtered through the Scora service. However, some spammers may ignore the DNS change and continue to send spam directly to your mail server. To prevent this, you may want to install a filter between your mail server and the Internet that only allows incoming connections from the Scora service, thereby blocking the dastardly spammers. There are many places where this filter could be put into place: in the configuration of your mail server software, in the software firewall configuration of your mail server, or in your organization's firewall configuration. The choice of where to put the filter depends greatly on your configuration and what software and hardware you are using, as does the exact manner in which you would configure the filter. What you wish to accomplish is to block all connections on TCP port 25 (SMTP) coming into your mail server, except connections from the IP address block 64.65.116.0/26.

Before putting such a filter into place, consider any possible side effects from blocking SMTP to your mail server. For example, if you provide authenticated SMTP service to members of their organization when they are on the road, this filter might block that. You may be able to resolve that by having the roaming users switch to sending their mail on a different port (like 587, the Message Submission port, see RFC 2476). If there are other domains which use this server that are not using Scora, than the filter should not be put in place. Most organizations do not face these complexities and can put the filter in place with no ill effects.

C. Enjoy less spam!
You have completed the initial setup steps necessary to activate Scora's filters. At this point you we recommend reviewing the administrator reports that get automatically generated and emailed to you so that you can monitor the performance of the filters. Please review the documentation on Interpreting Reports as well as Generating and Distributing Reports in the Common Tasks section of the support documents for more details. Please also review our advanced options pages to take full advantage of Scora.

The quarantine option is enabled by default (unless you've manually disabled it). Should you receive a request to release a message from quarantine, please review the documentation on Managing Quarantined Messages in the Common Tasks section of the support documents for more details. If you would like to ensure that emails sent from this source are allowed pass the filters in the future, consider adding them to the whitelist.

In certain situations it is possible for email messages to bypass the Scora filters and get delivered regardless of what filtering options you have configured. Normally mail servers determine the final destination for a message by looking at the MX record in the DNS for the domain. As mentioned in Section B, spammers sometime bypass the MX record. Another common way email messages can bypass Scora is if the person sending mail and the receiving domain use the same mail server. For example, if you maintain your own mail server onsite that is also used by office computers for sending outgoing mail, then messages between coworkers will never be processed by Scora. This is because the sending computer is connecting directly to the final destination mail server. This mail bypass can also occur if two Scora customers use the same ISP as their mail server. We prevent this from happening for customers that host their email on LavaNet's servers by forcing Scora processing for those customers, but we don't have control over other ISPs.

Please log into Scora to access the complete Admin Manual for more information or contact support if you need any assistance.

 



back to top   Home | Antispam Software | Support | About Tiki | Contact | Login | End-User Login
copyright 2003-2005 Tiki Technologies Corporation. All rights reserved. Privacy Statement.