SpamOnion is a spam and virus filtering service. It works by accepting all email on behalf of a domain (by updating the domain's MX DNS record) where each incoming message passes through a series of filters, or layers. If the message passes all of the tests, it is passed on to the domain's mail server for final delivery.

See the answer in the DNS FAQ.

It is best to only have equally weighted MX records that point to the SpamOnion server(s). For example:

10 mx1.spamonion.net.
10 mx2.spamonion.net.

First, we want all email for the domain to only go to the SpamOnion servers. Second, we want the priority to be equal so the email load will be shared among all of the SpamOnion servers.

It is not recommend that you put your mail server as a lower priority (higher numbered) MX record. For example, continuing the example above:

10 mx1.spamonion.net.
10 mx2.spamonion.net.
30 mail.example.com.

Spammers know that most 'backup' MX servers do not filter spam as well as the primary servers (or at all). Thus they will specifically target backup MX servers and bypass the primaries. This defeats the purpose of using SpamOnion. :-)

You need to contact the person or organization that controls the zone for your domain. This could be someone within your organization but it is more likely a third party such as the registrar for your domain or an ISP (Internet Service Provider).

If you do not know who controls the zone for your domain, you can find out using the tools at DNSstuff.com. Use the whois tool on the left hand side by entering in your domain name and clicking the WHOIS button. The results show the registrar for your domain, contact information for the domain and finally the nameservers. These nameservers contain the authorative information for your domain.

If the domain of the nameservers is the same as the domain for the registrar, then odds are your zone is being handled by the registrar. For example, if the registrar is Register.com and the nameservers are DNS23.register.com and DNS24.register.com; then Register.com controls the zone for the domain.

If the nameservers do not match the registrar, then an ISP is probably controlling the domain. It is probably the same ISP that hosts the domain's website and possibly email. In that case you need to contact the ISP to have your MX records changed.

If this is still confusing, feel free to contact the Support group for SpamOnion and we can help you in the search.

Quite simple, actually. SpamOnion will be the primary MX server for your domain and thus all email addressed to your domain on the Internet must come to the SpamOnion servers. In most cases, there will be no reason for other servers on the Internet to contact your email server directly. All of your email will be coming from the SpamOnion server. Thus, you can adjust your firewall to only allow incoming connections on port 25/tcp (the SMTP port) from the SpamOnion servers.

The IP address and hostname of the current SpamOnion server is:

204.193.156.32
mx1.spamonion.net

Please note, there is an exception to the above scenario. If you have remote users and they use your mail server as their outgoing mail server (most likely by requiring SMTP authentication), then they may require port 25/tcp to be open so they can send outgoing messages.

First off, there should be no interruption in email during the transition to the SpamOnion service. For a short time, email for you domain will come both directly to your server and also to the SpamOnion servers. But after that time, email should only come from the SpamOnion servers.

Once the service is fully in place you will not technically lose any email. We say technically because part of the answer involves how the sending mail server behaves and since SaNE does not have control of these servers, we cannot predict how they will react. Explaining our reasoning completely is beyond the scope of this document, but we will try to summarize.

Depending on the layers activated for the domain, an incoming message may get rejected by a layer. When a message is rejected, the SpamOnion server sends a code and the reason for rejection to the sending the server. If the sending server is following the SMTP protocol, it will generate a Delivery Status Notification message (or DSN) to the sender which will tell the sender why the message was rejected. A DSN is commonly called a bounce message. The problem is that not all email servers follow the SMTP protocol correctly and therefore the sender may not be notified that the message was rejected and/or the reason why it was rejected.

If the sender is a spammer, then we really do not care if he/she receives a bounce message. In fact, we almost guarentee that they do not. The spammers also do not care if they receive one. If the sender is legimate, however, then we have a false positive. In this case, we do want the sender to know that their message was rejected.

If the sender knows the message was rejected and the reaon why then the recipient technically did not lose any email. Please see the false positive section of the FAQ for more insight on that topic. However, losing email is all in the eye of the beholder so SaNE will be completely honest and say that yes, there is a chance you will lose messages. But please allow us to elaborate further.

We would say that there is a slight chance that legitimate email will be delayed rather than lost. If a legitimate message becomes a false positive, the situation can usually be fixed by the SpamOnion user interface (UI) either by the recipient or the domain administrator. If that fails, then SaNE staff are avalable to correct the situation. So technically, the message was not lost, just delayed.

The full SpamOnion documentation will explain how to correct situations such as the one described here.

A false positive occurs when a legitmate email message is erroneously classified as spam by one of the SpamOnion layers. There are several reasons why a legitimate message could be misclassified, but the exact reason depends on the SpamOnion layer that made the mistake. But we can divide the reasons into these general categories:

1) SMTP violation:
The sending server is somehow grossly violating the SMTP protocol. This can occur when the sending server is, to be polite, mis-managed.

2) The sending server is on one or more Realtime Black Lists (RBLs):
SpamOnion checks various Realtime Black Lists in one or more layers. If this turns out to be the issue, the sending server can be whitelisted until the sending server admins get it off the Realtime Black Lists.

3) The sender or the sender's domain is on your SpamOnion blacklist:
The domain administrator may have added the sender's address or the sender's domain to the the domain blacklist. To remedy, either remove the blacklist entry or add the sender's address to the domain whitelist. Whitelists overrule blacklists.


4) The sender could not be verified:
See the sender verification portion of the FAQ for a description. This situation can be remedied by adding the sender or the sender's domain to the domain whitelist. SaNE highly recommends that you notify the sender of the situation so their system administrators can fix the problem on the sending server.

5) The sender's message is corrupted:
The sender's email client could be broken and not send attachments correctly. Attachments that are not sent correctly are a potential security problem and therefore could be blocked by SpamOnion. This can be remedied by adding the sender or the sender's domain to the domain's whitelist. SaNE highly recommends that you notify the sender of the situation so their system administrators can fix the problem on the sending server.

6) The sender could have attached a banned file:
Certain file extensions are considered unsafe for security reasons. The most common example are .exe files which are executable files on the Windows operating system. By default SpamOnion will block such attachments. See the banned file extention section of the FAQ on how to get around this layer.

7) SpamAssassin could have misclassified the message:
SpamAssassin is one of the layers of SpamOnion. It is a very popular spam filtering tool. But like any spam filtering tool, it can make mistakes. If it does, the immediate remedy is to add the sender or the sender's domain to the domain whitelist.

8) DSPAM could have misclassified the message:
The final layer of SpamOnion, DSPAM, may misclassify a message as spam and so the message will end up in your quarantine box. In these rare cases, you can tell the software to learn from its mistake via the SpamOnion user interface. The SpamOnion documentation explains how to do this.

A false negative occurs when a spam message is misclassified as a legitimate message. That is, the spam message somehow passes all of the SpamOnion layers. It takes a crafty spammer for this to happen, but it can happen.

In this case, you want to tell SpamOnion to learn from its mistake. This is done by forwarding the false negative to spam-FIRSTPART#DOMAIN@spamonion.net. Here FIRSTPART is the part of your email address before the @ sign and DOMAIN is the part of your email address after the @ sign. In short, by forwarding the message back to SpamOnion, you are telling it to learn from its mistake.

As an example, if my email address is user@example.com and I received a false negative, I would forward it to:

spam-user#example.com@spamonion.net

Please be sure the DSPAM tag is included in the forwarded message. This tag uniquely indentifies the message so SpamOnion and DSPAM can learn from its mistake. We also recommend that you setup an addressbook entry for this address so it is easy to forward a false negative back to SpamOnion.

A false negative can also be fixed via the SpamOnion user interface.

An sample DSPAM tag looks like this:

!DSPAM:43264f0178699431216215!

DSPAM, the final layer of SpamOnion, tags each message it scans. This way if a false positive or a false negative occurs, the message can be sent back to DSPAM so it can learn from its mistake. Without the tag, DSPAM would not be able to uniquely identify each message it scans.

It is possible to remove the DSPAM tag from the body of the message and place it in the header section of the message instead via setting your DSPAM options in the SpamOnion user interface. However, we do not recommend this unless your email client can bounce a message (important note: the term bounce is not the same term used to describe a message that could not be delivered. See the Email FAQ for more info).

Here bouncing a message means you resend it to another address but keep the body and header section completely intact. This is different than forwarding a message. Forwarding means to compose a brand new message, but include the contents of the original message in the body of the new message.

The most popular email clients, Outlook Express and Outlook, do not support bouncing. The SaNE recommended email client, Thunderbird does support bouncing.

See the full SpamOnion documentation for instructions on how to adjust your DSPAM settings.

Both blacklists and whitelists are simply a list of domains or individual email addresses. Therefore there are 2 blacklists and 2 whitelists for each SpamOnion domain:

o 1 x domain blacklist
o 1 x email address blacklist
o 1 x domain whitelist
o 1 x email address blacklist

As you can probably surmize, a domain list affects any incoming message from a certain domain, i.e. example.com. An email address list affects any incoming message from a certain email address, i.e. user@example.com.

A blacklist entry will cause a message from that domain or email address to be immediately rejected. That is, your domain does not want to receive any email from that domain or email address.

A whitelist entry will cause a message from that domain or email address to be immediately accepted. That is, your domain wishes to recieve email from that domain or email address. In essense, the message will bypass most of the SpamOnion layers.

Whitelists overrule blacklists. Thus it is possible to blacklist an entire domain, but accept messages from individuals in that domain.

Blacklist example.com but whitelist user@example.com. Any message from example.com will be rejected except messages from user@example.com.

One word of warning. Blacklists and whitelists rely on the envelope sender which can easily be forged. It is quite possible for a spammer to send you spam by forging the sender to be someone on your whitelist. This should generally be rare, but try to avoid whitelisting well known domains such as yahoo.com, hotmail.com, aol.com, msn.com, etc. It is okay to whitelist individual addresses within those domains.

The current SpamOnion server(s) are:

hostname = mx1.spamonion.net
IP = 204.193.156.32

For purposes of setting an MX record, it should point to mx1.spamonion.net at the lowest preference.

The answer is yes and no. :-)

To make use of just the domain level portion of SpamOnion, the only requirement is to point your domain's MX records to the SpamOnion servers.

To make use of the user level portion of SpamOnion, you will need to configure a login to the SpamOnion user interface for each of your email users. Usually this is done via the SpamOnion user interface by the domain administrator. If you have a large number of users, SaNE staff should be able to assist you. Just contact our Support group.

Yes indeed. We filter each message that is smaller than 10MB in size through the open source virus filter called ClamAV. Virus files tend to be that size or smaller and we limit the size in order to save wear and tear on our servers and deliver email as quickly as possible (filtering takes time). But we constantly monitor the virus situation and we will adjust this figure as necessary.

Yes, some phishing attempts are blocked. The ClamAV virus filter has experimental support for phishing attempts. So far it has proven very effective and we can only expect support to get better over time.

If your mail server is not available (your Internet connection is down, the server is down for maintenance, etc) then email addressed for your domain will temporarily spool on the SpamOnion servers. That is, if our servers cannot deliver the messages immediately, it will be spooled and tried again later.

We will keep attempting to send the messages for up to two days. After two days if your server is still not available, then the messages will be returned to the original sender as undeliverable. If you expect your server to be unavailable for greater than two days, please contact our Support group and we will gladly make arrangements to spool longer; based on your needs.

There is one exception to the above policy. If the registration of your domain expires, then the SpamOnion servers will not be able to lookup any DNS information for your domain and will be forced to not accept any messages for your domain. The most common reason a domain expires is because of lack of payment to the registrar. Therefore it is very important that an organization be aware of the status of its domain and make sure all contact information is accurate.

No, SpamOnion can only work on whole domains. However, if you have an email address within your organization that eventually forwards to your free email account, then those messages will get filtered.

Please see the answer to this question in the Email FAQ.

One of the layers of SpamOnion is called sender verfication. In this layer we try to make sure the sender actually exists. There are several ways of doing this but here is the most common and the way SpamOnion does it.

While processing an incoming message, we eventually know who the supposed sender. We try to verify this address is 2 stages. Stage 1 is to simply make sure the sender's domain exists. For example, if the sender is user@example.com, we make sure that DNS information exists for example.com. If not, the sender could never receive email and therefore cannot be verified so the original incoming message is rejected.

Stage 2 is more elaborate. Here we pretend to send a DSN or bounce message to the sender. That is, we look up the MX record(s) for the sender's domain, connect to one of the MX servers and start to send a DSN message. If the sending server accepts the DSN, then we abort the message so no actual DSN is sent. If the sending server does not accept the DSN message, the sender cannot be verified and the original incoming message is rejected.

There are 2 main reasons why a sending server would not accept a DSN. First, the sender is a spammer. Spammers do not care about DSNs and generally do not accept them. Second, the sending server rejects all DSNs. Some sites do this because they believe it will reduce incoming spam to their site (which is not true).

If the latter is the case, the sending domain or email address should be added to the domain whitelist via the SpamOnion user interface; at least temporarily. SaNE recommends that you notify the sender of the situation so the domain's system administrators can remedy the situation.

Recipeint works just like sender verification except we are trying make sure the recipient address really works and not the sender. Like sender verification there are 2 stages.

Stage 1 is to simply make sure the recipient's domain exists. For example, if the recipient is user@example.com, we make sure that DNS information exists for example.com. If not, the recipient could never receive email and therefore cannot be verified so the original incoming message is rejected.

If this occurs then there is a major problem with your domain. For whatever reason, SpamOnion cannot get DNS information. The most common cause is that the domain has expired, usually due to lack of payment. The next most common cause is that the main DNS servers for the domain are unreachable. This should never happen. If it does, we recommend that you reconsider who hosts your domain and/or adjust your DNS strategy so that at least one nameserver with authoritative information for your domain is always reachable.

Stage 2 is more elaborate. Here we pretend to send a DSN or bounce message to the recipient. Since SpamOnion already knows where to send email for your domain, we connect to your mail server and start to send a DSN message.. If your server accepts the DSN, then we abort the message so no actual DSN is sent. If your server does not accept the DSN message, the recipient cannot be verified and the original incoming message is rejected.

This is generally a good thing. If the recipient does not exist, the original incoming message should be rejected.

However it is possible that your mail server does not accept DSN messages. As explained in our email FAQ, SaNE does not recommend this as it causes more problems than it solves. Also, it is unnecessary since you are using SpamOnion :-) (see our FAQ entry on security). If your organization's policy insists that your mail server not accept DSN messages, then recipient verification can be turned off via the SpamOnion user interface.

Also, SaNE does not recommend that you employ a catchall address. A catchall address will accept any mesage that is not directed to a real mailbox on your mail server. This seems very helpful because your domain will never miss any email messages. For example, if a sender misspelled an email address to your domain, someone would still receive it; though probably not the intended recipient. The message could be forwarded to the correct recipient and the sender informed of his/her error.

But in practice, catchall addresses just tend to attract spam. Spammers will attempt what is known as a dictionary attack. They will send the same message to common names within your domain. Thus your catchall address will recieve ALL of these messages (assuming they get through other layers of SpamOnion).

In today's Internet, a catchall address does not make much sense. It is SaNE's opinion it is better to reject a misspelled address than accept it. The sender will realize his/her mistake and resend. Otherwise a spammer will take advantage of the situation and attempt to send hundreds or even thousands of spam messages to your catchall address.

Certain file attachments are banned because they are considered a security risk. You can find out how you still receive these files via email in the next FAQ entry. Here is a list of the currently banned filename extensions:

ade, adp, app, asd, asf, asx, bas, bat, chm, cmd, com, cpl, crt, dll, exe, fxp, hlp, hta, hto, inf, ini, ins, isp, js, jse, lib, lnk, mdb, mde, msc, msi, msp, mst, ocx, pcd, pif, prg, reg, scr, sct, sh, shb, shs, sys, url, vb, vbe, vbs, vcs, vxd, wmd, wms, wmz, wsc, wsf and wsh

If you need to receive a banned file as an email attachment there are two ways you can get it. First, the sender could zip or tar the file and email the zip or tar file to you. These types of files are not banned. Second, the sender could rename the file to not have a banned file extension. The recipient would then need to rename the file back to its original file extension in order make use of it.