Email Filtering Policy
At Trade Web Solutions it is our policy to protect our email users from spam. We have invested in sophisticated technology that will block at least 90% of junk mail messages, and usually upwards of 99%.
Whilst we take great care that legitimate email is not affected by these systems it should be noted that there is an error margin of about 1 in 10,000, and so very occasionally a message may be misclassified.
We publish this policy to help our users and other ISPs understand the restrictions we apply and how mail is affected by those restrictions.
SMTP Level Access Controls
Messages are transferred between mail servers using a protocol named SMTP. When we discuss SMTP level controls we are referring to controls that are applied when the mail server delivering the message connects to our mail server. We apply the following restrictions at the SMTP level:
Static IP Address
SMTP clients must connect from a static IP address. Mail from SMTP clients that connect from dynamic or residential IP address will be rejected. If you wish to operate a mail server on a residential connection please arrange for your outgoing mail to be relayed out through your ISP.
DNS Blacklists
SMTP clients must connect from an IP address that is not listed on a blacklist. Mail from SMTP clients that are blacklisted will be rejected. If you find your mail server has become blacklisted please investigate and resolve the cause and then apply to the administrators to be de-listed.
Reverse DNS
SMTP clients must connect from an IP address with a properly configured PTR record and a corresponding A record. Mail from clients without reverse DNS or with improperly configured reverse DNS will be rejected. Your connectivity supplier can configure reverse DNS for you.
Hostname
SMTP clients must announce their fully qualified and resolvable hostname in an HELO or EHLO command at the start of the SMTP transaction. Mail from clients that do not announce their hostname or with an unresolvable hostname will be rejected.
Sender Address
SMTP clients must specify a fully qualified sender address with a resolvable DNS name. Mail from SMTP clients that specify an unqualified sender address or a sender address on an unresolvable domain will be rejected.
Recipient Address
SMTP clients must specify a fully qualified recipient address that is local to the server. Mail addressed to unqualified recipient addresses or to non-local recipients will be rejected.
SMTP Pipelining
SMTP clients must wait for the proper SMTP response to their command before sending their next command. Mail from clients that attempt to pipe-line SMTP commands will be rejected.
Retry if Temporarily Deferred
SMTP clients must retry the delivery of messages that are temporarily deferred with a 400 series code. SMTP clients that attempt delivery only once will not be able to deliver messages.
How are messages affected?
The SMTP level is the ideal time to apply restrictions such as those described above because messages that are rejected at this point remain the responsibility of the SMTP client attempting to deliver the message.
This means that where spam is rejected we do not need to generate a bounce to the sender address. Bounced spam is a known as "backscatter" and is a nuisance because the sender address is invariably faked.
In the event a legitimate email is blocked the server attempting to deliver the message will immediately return it to its sender as undeliverable. Messages that are returned to sender are not considered lost.
Message Checks
Messages that pass the SMTP level checks described above are accepted by the mail server before being subjected to a second phase of detailed analysis. This phase involves checks on the message itself (as opposed to its source) as described below:
Virus Scanning
Messages are scanned for known viruses and if found to be infected are deleted. This is the only stage in the process where a message can actually be irretrievably lost, but virus scanners are highly accurate and are not prone to false-positives. It should also be noted that accessing a virus infected message from a quarantine would be ill advisable in most cases.
Content Analysis
Finally the message content is checked to see if it appears to be spam. This process involves a complex statistical analysis of the message content as well as the use of optical character recognition techniques. Where messages appear to be spam they are tagged in the message header and subject, but are then delivered to the mailbox as normal.
What About a Quarantine?
A fundamental principle of SMTP is that messages should never be lost, yet when you quarantine a message this is effectively what happens. The message neither arrives in the recipients mailbox nor is it returned to sender; until someone investigates manually the message is missing.
Remember, with the single exception of viruses, messages are never deleted by our systems. A message will only ever be delivered or returned to its sender. We make an exception for viruses because they are dangrous are rarely misclassified.
Another problem with message quarantines is that they do not scale well. Daily, manual review of a spam quarantine is time consuming and does not fit well with the benefits of automated spam filtering. Bear in mind that we currently reject upwards of 50,000 spam messages per day.
What About Outgoing Email?
The above restrictions apply only to incoming email. Outgoing email messages are exempt and will never be tagged as spam.
Summary
Since the introduction of this policy in 2006 these restrictions have proven effective at preventing spam from becoming a problem for our users. Feedback from our customers has been overwhelmingly positive with only a very small number of false positives reported to date.
ISPs wishing to deliver mail to our users should have no problem doing so where their systems are properly configured and where those systems are not used to send spam. If you are having problems delivering mail to our users please contact the Support Team and we will arrange to temporarily white-list you while the cause of the problem is resolved.