Note that this version of our web site is now obsolete. Instead, please bookmark https://hd.islandnet.com
Welcome to Islandnet.com  
Locally owned and operated since 1993  
Create an Account   •   Pricing & Features   •   Domain Registration   •   Customer Sites   •   Help & Info
Sunday February 12 2012  
Live Chat
LOG IN:  Username:    Password:    

E-Mail Server Practices & Policies

Return to the help index

Table of Contents

Introduction
Filtering and Blocking
Penalty Box
Greylisting
Spam Assassin
Relaying
Alternate SMTP Ports
SSL/TLS Encryption
Retries
SPF Support
Logging


Introduction

This document explains our practices and policies with regard to how our mail servers behave, as well as how they expect other mail servers to behave. It is somewhat technical in places. If you have any questions or concerns about anything in this document, please email us at support@islandnet.com.

The policies outlined here are not necessarily written in stone. If you are having trouble sending or receiving mail due to our policies, talk to us and we'll see what we can do. It may be possible to make exceptions in some cases, or it may even result in a change of policy.

[Back to top]


Filtering and Blocking

We believe that e-mail filtering (blocking mail based on content) is generally best left to the end users, as one person's trash is often another's treasure. With thousands of customers it is impossible to come up with a set of rules that would satisfy everyone and still do an effective job at blocking the junk.

We estimate that at least 80% of all e-mail sent to our servers is junk mail and/or viruses, and that amounts to a lot of wasted resources that cost real money! It simply isn't practical to do no system wide tests at all.

So we do a minimal amount of content filtering (for example, we do scan for viruses). However, we do expect mail servers that talk to us to behave properly according to the official SMTP specifications and common best practices. This does not generally involve content filtering, it's mainly just enforcing proper protocol.

We have implemented four distinct levels of e-mail testing:

1. System Wide Tests

System wide tests apply to all e-mail that passes through our servers regardless of the source or destination. There is no option to avoid these tests, they apply to everyone. When a message is rejected due to one of these tests an error code is returned to the sender's mail server, which means they will know their mail was refused.

  • Recipient verification: obviously incoming mail for non-existant recipients is rejected. This includes addresses at customer domains that are blackholed or bounced within a map file.

    If have your own domain and you haven't done so already, please add a default rule to your map file that rejects all addresses that aren't specifically permitted.

  • Virus scanning: depending on the message size and the current mail server load, all messages are scanned for viruses with at least one and as many as three different virus scanners. The virus databases for these scanners are updated at least twice a day. Note however that it may take hours (or even days, although this is not common) before a new virus is identified and added to the database by the vendor.

    We strongly recommend that you install anti-virus software on your computers and keep it up to date as e-mail is only one way that viruses spread.

  • Proxy servers: some proxy web servers can be abused to send spam. Since they have no legitimate business connecting to a mail server, those that identify themselves as proxies (eg: Squid, CacheFlow, etc.) are rejected.

  • Sender domain verification: the sender's domain must exist and resolve correctly.

  • Forged sender checks: a variety of tests are performed to ensure that the sender address is legitimate. For example, certain mail providers like Hotmail do not allow accounts that start with a digit, so any incoming mail from such an address is rejected as a forgery.

  • EHLO/HELO is required: when a remote server connects the first thing it must do is introduce itself via the EHLO or HELO command.

  • EHLO/HELO is our IP: an attempt to identify itself as one of our IP addresses is always a forgery.

  • EHLO/HELO is our domain: if a remote site introduces itself as one of our domains (or a customer domain) then it's most likely a forgery, although it could also indicate an off-site customer who forgot to use authorization or POP before SMTP.

  • Forged HELO: for certain commonly forged domains, we check to ensure that the remote system's IP address really does belong to the domain mentioned in HELO.

  • Excessive failures: if a server attempts to deliver the same message to several non-existant local addresses in a row then it is considered to be a spam run.

  • Remote relaying: attempts by a non-local user to relay mail through our server to a non-local recipient will be rejected. This check does not apply to customers that use POP before SMTP and/or SMTP authentication.

  • CLSID attachments: it is possible to send a file attachment and hide the filename extension by encoding it with a "CLSID" (it's a Microsoft thing). This can be used to send harmful files that look innocent and legitimate mail will never contain these.

  • Fragmented attachments: another technique used to try and get around virus scanners is to break a file into multiple MIME parts within the same message.

  • Invalid MIME boundaries: a message with attachments must use valid MIME boundary markers or the recipient won't be able to open and read it. While this is never a problem for legitimate mail, certain viruses and spam software often get this wrong.

  • Null sender check: as required by the SMTP standards, we do accept e-mail from the null sender "<>". However, such messages should never have more than one recipient and we will reject those that do.

  • Mandatory header checks: the SMTP protocol requires that certain headers must be present and certain others must have a very specific format. We require that incoming messages have at least a Date: and From: header, and if a Message-ID: header is present it must be formatted correctly.

  • Message size: the maximum size of a single mail message including the headers and all attachments is 30 megabytes. Messages larger than this will be rejected. Note that you can choose to reject messages smaller than this with an appropriate PEP rule.

    E-mail was never designed for sending large files. If you really need to exchange large files with someone, please use FTP or the web.

  • Spam traps: we have reserved a large number of addresses on our servers that have never belonged to real customers, so any email sent to them is definitely spam (they are not common words that could simply be mispelled). If any incoming message includes one or more of these special addresses as a recipient, the message is rejected.

2. Opt-Out Tests

These are also system wide checks like those above, but customers can "opt out". At your request we will add your domain(s) and/or individual e-mail addresses to a list and the following checks will not be applied to messages that arrive addressed to you. Note that you cannot turn these checks on or off individually, you either permit us to apply all of them them to your e-mail or none of them. When a message is rejected due to one of these checks an error code is returned to the sender's mail server, which means they will know their mail was refused.

These checks are enabled by default. If you do not want these to apply to you, send e-mail to support@islandnet.com and tell us which of your local domains and/or addresses you want to exempt.

Be aware that opting out of these tests may result in dozens, or in some cases even hundreds of additional spam messages getting through to you each day!

  • Reverse DNS: for certain foreign countries that produce a high volume of spam we will refuse mail from hosts that do not have reverse DNS properly configured (ie: they have no PTR record for their IP address). When a message is rejected for this reason, the error message includes a link to http://helpdesk.islandnet.com/smtp/noptr.php

  • Sender address verification: a "callout" or "callback" test is performed to see if the sender's email address is valid. If mail can't be sent to the sender's address, then mail won't be acepted from that address either. When a message is rejected for this reason, the error message includes a link to http://helpdesk.islandnet.com/smtp/callout.php

  • IP address as HELO: a remote system must never introduce itself with a plain IP number (if it must use an IP then the SMTP specs state that it must be enclosed in square brackets).

  • Banned attachment types: certain types of files are commonly used to transmit "malware" (viruses, trojans, spyware, etc.) and for security reasons we do not allow them to pass through our servers. If you need to send or receive one of these file types it must be archived first with something like ZIP, TAR, SIT, RAR, etc. This also has a positive side effect in that archived binary files are typically much smaller than raw binary files, which means they take less space in your mailbox and use up less bandwidth. The current list of banned attachment types is:

    ade adp bas bat chm cmd cpl crt hlp hta inf ins isp js jse lnk mdb mde msc msi msp mst pcd pif reg scr sct shs shb url vb vbe vbs wsc wsf wsh

  • Blacklisted hosts: we maintain our own databases of IP addresses and domain names that we won't accept mail from. These are typically either abusive servers or open mail relays.

  • DNSbls: we consult with various DNS based blacklists and reject mail that comes from listed sites. The blacklists we consult are non-aggressive and very low risk. The DNSbls we currently consult are:

    http.dnsbl.sorbs.net lists open HTTP proxy servers.

    socks.dnsbl.sorbs.net lists open SOCKS proxy servers.

    misc.dnsbl.sorbs.net lists additional proxy servers not listed in the above databases.

    zombie.dnsbl.sorbs.net lists hijacked networks.

    dul.dnsbl.sorbs.net lists dynamic IP ranges.

    xbl.spamhaus.org lists IPs of compromised machines with open proxies, viruses, worms, trojans, etc.

We maintain a whitelist of IP addresses that we will accept mail from, even if they are listed in a DNSbl. If you are having trouble receiving mail from someone because their server is blacklisted, let us know their IP(s) and we'll consider adding them to this list (depending, of course, on the reason they are blacklisted in the first place).

3. Map File Processing

If an incoming message makes it past the tests described above, and if (and only if) the message is destined for an address at a customer's domain, it is passed to the map file processor. The map file processor allows customers to map addresses within their domain to specific destinations. The map file system also lets you to do some very basic domain-wide filtering. Please refer to the map file documentation for more details.

4. Individual (PEP) Mail Rules

When a message finally gets to the point where it will be delivered to a local mailbox, it is passed to the PEP program. By creating a set of rules for PEP to follow, you can apply additional customizable e-mail filtering (among other things). Please refer to the PEP documentation for more details.

[Back to top]


The Penalty Box

Under certain circumstances, the IP address of a sending host and/or the email address of the sender may be placed in the "penalty box". The incoming message (and any subsequent messages from the same host or sender) will be deferred until the penalty is over (which usually lasts 5 to 10 minutes). Basically this means that the server will say "I won't accept the message now, but try again in a few minutes".

Because much of the spam sent today comes from specialized spamming software or viruses that won't bother to try again later, and all properly configured legitimate mail servers must retry, this technique actually eliminates a large amount of spam with no false positives.

Basically this is a sort of automated short-term blacklisting system. A host and/or sender might be placed in the penalty box for things such as sending a virus, sending mail to one of our spam traps, etc.

[Back to top]


Greylisting

Greylisting is similar to the penalty box in that it defers messages and assumes that the sending computer is a properly configured mail host instead of a virus or specialized spam software. With greylisting, however, the first time a unique key consisting of the host's IP address, the sender's email address, and the recipient's email address is encountered, the message is deferred. If the same message is tried again, it is accepted and the server's IP address is whitelisted so subsequent messages from the same server will not be deferred (even if they are for different recipients). Like the penalty box, this is a very effective technique for stopping spam and viruses without disrupting legitimate mail.

In the very rare case that a real mail server is misconfigured and treats a deferrment as an error, the bounce message will contain a reference to http://helpdesk.islandnet.com/smtp/greylist.php

[Back to top]


Spam Assassin

All email under a certain size is passed through Spam Assassin to get a spam score. This is a decimal point number and the higher it is the more likely the message is to be spam. This score is added to each message as the "X-Spam-Score:" header. You can test this value with filtering software, including PEP. Since some filtering programs cannot perform numerical tests, a bar graph is also included in this header. Here are some examples:

X-Spam-Score: 12.0 (++++++++++++)
X-Spam-Score: 4.5 (++++)

If the spam score is 5.0 or higher, a second header containing more details (it will span multiple lines) is added to the message. It explains which Spam Assassin rules contributed to the overall score and how much. It looks like this:

X-Spam-Report: Spam Assassin details:   (12.0 points, 5.0 required)
        pts rule name              description
        ---- ---------------------- --------------------------------------------------
        0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high
        0.5 X_PRIORITY_HIGH        Sent with 'X-Priority' set to high
        4.4 DATE_SPAMWARE_Y2K      Date header uses unusual Y2K formatting
        1.6 RAZOR2_CF_RANGE_51_100 BODY: Razor2 gives confidence between 51 and 100
        [cf: 100]
        0.9 RAZOR2_CHECK           Listed in Razor2 (http://razor.sf.net/)
        1.4 DNS_FROM_RFCI_DSN      RBL: From: sender listed in dsn.rfc-ignorant.org
        1.2 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-MimeOLE
        1.6 FORGED_MUA_OUTLOOK     Forged mail pretending to be from MS Outlook

Note that We do not reject mail based on the spam score, this is entirely up to the end user.

[Back to top]


Relaying

Relaying occurs when a non-local sender delivers e-mail through our server to a non-local recipient. Due to the potential for abuse, no properly managed mail server will allow anonymous users to relay through it. A server that is misconfigured in this manner is called an "open relay".

It is desirable, however, to permit our own customers to relay through our servers while they are not directly connected to our network (eg: on the road, or at the office, etc.) To allow this while preventing anonymous relaying we support two different options:

  • SMTP Authentication: most mail programs these days support a feature called authentication. That is, it logs into the mail server first with your username and password before trying to send through it. If your software supports authentication and you have it enabled, you will be able to send mail through our server no matter where you connect from.

    Our mail servers currently support two types of SMTP authentication. The "LOGIN" type is commonly used by Microsoft Outlook, and the "PLAIN" type is supported by most other programs. The "CRAM" and "SPA" types are not currently supported.

  • POP before SMTP: when your mail software connects to our POP server to check for new mail, the IP address you connect from is granted temporary permission to relay through our mail server. This permission lasts for at least an hour (usually longer). As long as you check for new mail periodically (even if you don't have any new mail waiting) you will also be able to send mail through our server.

Note that dialup customers that connect via our modems are treated as local connections and do not need to rely on either of the above techniques to send through our servers.

[Back to top]


Alternate SMTP Ports

In an effort to curb outgoing spam and viruses from their own users, some ISPs have begun to block outbound connections on port 25, which is the SMTP (email) port. In other words, customers of such ISPs are forced to use that ISP's mail server for sending and are unable to use another mail server. Due to reliability issues, many people prefer to use our mail servers for sending mail, so to get around this problem all our mail servers will accept connections on ports 587 and 2525 as well as the standard port 25. Since these ISPs do not usually block these ports you should be able to continue using our mail servers.

If you use such an ISP for connectivity (Telus or Shaw, for example) and you wish to continue using our mail servers instead of theirs, you simply need to change your mail program settings to connect to us on port 587 or 2525 instead of port 25.

We do not currently block our local customers from accessing external SMTP servers.

[Back to top]


SSL/TLS Encryption

Normally all SMTP transactions occur over a plain text (unencrypted) connection, which is fine in most cases, but those who are concerned about security may prefer to connect to our mail servers using an encrypted connection. Our POP and SMTP servers support two common methods:

  • STARTTLS: this is the preferred method but certain older programs may not support it. Normally this requires nothing more than turning on a "starttls" option in your mail program's settings.

  • Alternate port: if your mail program does not support STARTTLS, then you can connect to our mail servers on a special port that automatically encrypts everything. This port is 465 for SMTP and 995 for POP. Of course, your mail program must support this too (most do).

If you use SMTP Authentication we strongly encourage you to also use an encrypted connection to protect your account password!

[Back to top]


Retries

When an outgoing message cannot be delivered due to temporary errors (like DNS problems, network errors, unavailable servers, fulle mailboxes, etc.) it remains in our mail server's queue and is periodically retried until it is either successful or a maximum retry period is reached. Currently we will keep trying to deliver a message for 24 hours, at which point it will bounce back to you with an error.

A warning message will be sent to you at certain intervals to let you know if a message is delayed. Currently one warning is sent after 4 hours and another after 12 hours.

[Back to top]


SPF Support

SPF (Sender Policy Framework) is a way for domain owners to restrict which servers are allowed to send mail that claims to be from their domains. While it seems like a great idea on the surface, it has a few nasty side effects, which is why we do not use it for rejecting mail. However, we do perform an SPF lookup and add a Received-SPF: header that you can use with PEP or other filtering systems. Here is a sample header:

Received-SPF: none (lenz.eggo.org: domain of esj@harvee.org does not designate permitted sender hosts)

The first word after the Received-SPF: header will be one of the following (the rest of the text on the line is a comment):

  • pass: the SPF check passed, the sending host is positively verified by SPF.

  • fail: the SPF check failed, the sending host is NOT allowed to send mail for the domain in the envelope-from address.

  • softfail: the SPF check failed, but the queried domain can't absolutely confirm that this is a forgery.

  • none: the queried domain does not publish SPF records.

  • neutral: the SPF check returned a "neutral" state. This means the queried domain has published a SPF record, but wants to allow outside servers to send mail under its domain as well.

If we handle DNS for your domain and you would like to publish an SPF record, just let us know and we'll help you set it up.

[Back to top]


Logging

All SMTP and POP transactions involving our servers are logged.

The information recorded includes such things as IP addresses and host names of the machines, the sender and recipient addresses, error conditions, routing information, etc. With certain error conditions some or all of a message's headers are logged as well (but never the message contents). These logs are confidential and are only visible to the server administrators.

Upon a reasonable request we may extract portions of log files for a customer's use (please keep in mind that these logs exceed several hundred megabytes per day so it's not always something we can do on the spot.

We keep logs for at least 30 days, and often for 60 days or more depending on disk space availability.

[Back to top]



Home  •  About Us  •  Contact Us  •  Terms of Use  •  Privacy Policy  •  Help Documents

© 2012 Islandnet.com, all rights reserved. 

Page generation time: 0.05 seconds