Sending Email to a network other than your own is considered a privilege, not a right, so we perform several checks to see if
you're worthy of letting in...
- Authorised Senders
- Checks include SPF, DKIM, and DMARC.
- These tests are where networks specify in DNS, who is allowed to send Email using their domain name,
and tell us how to deal with unauthorised connections, such as hard-fail (reject), soft-fail (accept but warn),
- IP Anti-Spoofing
- Testing to make sure the presented IP address and Hostname are not spoofed or forged.
- Valid Addresses
- You need to use a valid and resolving Email Address in the "From" and "To" fields when sending Email in or out of the network.
- DNS Blacklist Checks
- RFC1912 Enforcement
- Connecting Email Servers must have both a forward and matching reverse DNS record.
The rule and enforcement applies to both IPv4 and IPv6.
- RFC 1912, Section 2.1, para 1 and 2 states "Every Internet-reachable host should have a name"
and "Make sure your PTR and A records match" and "For every IP address, there should be
a matching PTR record in the in-addr.arpa domain", and although this document makes no direct mention of ip6.arpa, it has long been widely accepted as implied.
- It is also possible that your DNS Server has a broken configuration, or even not configured at all
and returning SERVFAIL, in which case please contact your Internet helpdesk as your provider has much bigger issues to resolve.
You can perform some tests from https://zonecheck.org to assist you and your provider resolving the problem.
- In very rare instances, there may have been a problem with our DNS servers getting a timely answer from your DNS servers, if the above checks verify
your DNS is configured OK, we suggest waiting a few minutes and retrying.
- With IPv6 gaining momentum due to IPv4 address depletion, it is important that you allocate a static IPv6 address (non-auto conf'd) to your mail servers,
and, ensure it too has matching AAAA (forward) and PTR (reverse) records.
- Residential IP Checks.
- This checks via DNS to see if the connecting host is in a known "home user" (the old Dial Up) Listing.
- In addition, there are checks on your hostname for such things that infer it is a home user, such as
but not limited to, terms like cable, DSL, ppp, dial or DHCP etc,
- In most cases, there is little need for a home user to send Email directly, by using your ISP's SMTP server
you greatly reduce the risk of your mail being blocked.
- 99% of spam is sent by spam bots, which are 99% comprised of compromised Microsoft Windows based PC's,
this type of blocking eliminates the vast majority of spam entering the network.
- We refined these rules many years ago, but like everything in the anti-spam world, it is, albeit very rare, a possible
chance our rules may false trigger on a legitimate host, if you consider your blocking based on residential checking is in error, please contact us ASAP.
- For Home users, this can be overcome by configuring your SMTP server's setting for smarthost/relayhost to that of your ISP's SMTP server,
some examples of doing this are -
- Sendmail, add to /etc/mail/sendmail.mc
define(`SMART_HOST',`smtp.your.isp')dnl (then remake sendmail.cf).
- Postfix, add to /etc/postfix/main.cf
relayhost = smtp.your.isp (then issue 'postfix reload')
- Microsoft Exchange, in exchange system manager, connectors
add new, SMTP-Connector add your smtp.your.isp
- For Business users on a static IP running your own mail server, have your ISP move you out of the
residential IP pool and change your rDNS to reflect your own domain.
- Generic IP Checks
- Mail servers tend to have specific names, that's if their admins are competent and not lazy, eg: mail.example.com or somename.example.com, etc.
- Using generic DNS, such as 1-1-12-123.example.com is very rare for a real mail server, it makes you appear to the rest of the world as a home user
and you will be treated as such.
- If you are unable to have your ISP fix this, firstly consider changing to an ISP that gives a damn, or, if that's not practicable, follow the advice above to resolve.
- Bad MX Checks
- Tests for illegal content in DNS MX resource records.
- Bad HELO/EHLO
- Connecting machines must issue a HELO or EHLO statement.
- They must also present this as a valid hostname in DNS..
- Senders of Backscatter
- This occurs when you send an Email to a network where the address actually does not exist, but the receiving network accepts the Email and then when
the two mail servers finish communicating, checks to see if the user exists, and upon finding no user, then generates a brand new reject message back to
the sender saying so.
- This is very wrong, the rejection should be done at the initial connection to the recipients server from the senders server,
rejecting at the "Mail From" stage where the look up is done (on compliant mail servers) and does not have to generate a brand new DSN (Delivery Status
Notification) message to the sender with a bounce message.
- This is a serious problem when addresses are forged and is exploited by spammers all of the time. Networks generating useless bounce/DSN messages,
such as Google Groups, and ill-configured Qmail and Microsoft Mail Servers are very typical of this problem, there are also some ill-configured anti-virus
and anti-spam systems that do the same, those should be avoided at all costs!
- Internal Blacklist (non-DNSBL)
- The blocking of IP's, hosts, domains, and in some cases full netblocks, and in rare cases entire TLD's and associated netblocks may occur if-
- Multiple hack/script attacks are attempted to be carried out against this network.
- Multiple hosts/IP's are found to be source of phishing scams.
- We deem traffic from host/IP should never be accepted for activities being detrimental to our services.
We do not provide a public list of permanently blocked hosts, but local users may request if a specific hostmark is blocked.
- Mailing/Mail-out lists
- Lists that are not full "opt-in" lists will be blocked when brought to our attention, regardless of if they have a working opt-out or not.
- Lists that do not honor or offer unsubscribe options will also be blocked if brought to our attention by our members.
- Email Virus Scanning
- All inbound and non authenticated outbound messages are checked by multiple Anti-virus Scanners - their definition databases are updated hourly.
- Detected virus and malware messages are silently discarded.
- Anti-Spam Checks
- Newly Registered Domains
- Newly registered domains will automatically have a spam score set to moderate, this reduces over time and becomes neutral after 14 days.
The reason for this is that many spammers register a domain, spam everyone a few days later, and are gone after a week or so.
- Phishing Checks
- This test attempts to determine if a link in an Email is genuine or fraudulent, phishing is very
common for those involved in identity theft and financial scams.
- This test also checks against several databases of known phishing sites URLs.
- Because false positives are likely, the messages are marked as spam, rather than blocked.
- Email Bad File Type Checks
- Checks attachments against a list of administratively prohibited file types.
- This means for example, but not limited to .com or .bat files, to avoid this limit, you can zip up the file, this action is taken
to help windows users not accidentally run a Trojan or any other form of malicious script or program.
- These tests are not based on filename, for example, a trojan.dll file may be called readme.txt, the tests will still see this as
a .dll file and reject.
Important: You should never solely rely on your Email Service Provider to protect you
from spam, fraudulent phishing scams, malware, viruses, or other malicious content, you also need
to take all necessary steps and precautions to protect yourself from these nasties, although our
anti-virus definitions are updated hourly, in most cases, it is near impossible to defend against
0 day (or just released) viruses and malware.
Members who believe their senders are consistently being incorrectly tagged as spam, should contact support.