Automatic Networking Solutions ^{Pty. Ltd.}
Standards required for email acceptance

0. Introduction

0.0 As a provider of mail services, it's in the best interests of ourselves and our clients to not accept email which comes from compromised sources or which refuses to identify itself correctly. This policy sets down in writing the types of email which we accept and that which we don't.

0.1 In general, our mail server will provide feedback if any incoming mail is rejected.

0.2 This document was last modified on 2008-04-19.

1. Standards

1.0 For email to be accepted by our mail servers, the connecting system must:

1. Identify itself properly (produce a valid HELO/EHLO) which is correctly formatted, is a full domain name and may be resolved.
2. Have reverse-lookups (PTR record) assigned which is also correctly formatted.
3. Not attempt to pipeline its email.
4. Not be an open relay, open proxy, open router, or any other system determined to be available for unauthorized use. We currently use the following to assist us to identify these suspect systems: bl.spamcop.net, dnsbl.sorbs.net, sbl-xbl.spamhaus.org, cbl.abuseat.org.
5. Not be from a region known for its spam and unlikely to be a source of valid mail. We currently use the following to assist us to identify these systems: cn-kr.blackholes.us, nigeria.blackholes.us, russia.blackholes.us, taiwan.blackholes.us, thailand.blackholes.us.
6. Not contain anything which is determined to be a virus or trojan by our mail server's Antivirus Software.

Our MX clients can opt out of using our mail DNS backlists on a per domain basis, but, it would be unwise to rely on this.

In exceptional circumstances our MX clients may request by email for us to add a particular domain to a "white list", however, we discourage this. It is always in a mail server administrator's best interests to resolve any spam issues with DNS blacklist providers rather than to force their existing customers to opt out of spam protection.

1.1 Additionally:

1. The sender and recipient domains must be correctly formatted, be resolved, is a full domain name.
2. With the amount of attachment viruses and worms targetting MS Windows, we do not accept incoming mail containing executable files including: *.lnk, *.asd, *.hlp, *.ocx, *.reg, *.bat, *.chm, *.com, *.cmd, *.exe, *.dll, *.vxd, *.pif, *.scr, *.hta, *.jse?, *.shm, *.shb, *.shs, *.vbe, *.vbs, *.vbx, *.wsf, *.wsh, *.wav, *.mov, *.wmf, *.xl. Instead, you should use compressed files (eg, gz, bz2, zip, arj, rar, cab, or lha/lzh) if you need to transfer such things.
3. Mail must have hopped through no more than 50 other mail systems before reaching us.
4. Complaints submitted by our staff or clients may be used as a basis for refusing connections from systems.
5. Systems attempting to deliver mail will have have their connection dropped if they trigger more than four errors.
6. Email with Korean and Chinese encoding is not accepted. We had to weigh up the deluge of spam from these regions with the fairly small chance a client might wish to send Korean and Chinese language email.
7. The recipient address must be either ourselves or a client domain. MX is a one-way service. We will automatically reject any attempts to relay your outgoing email through our systems.
8. The maximum message size accepted by our systems is 1,280,000 bytes per email (in practice, an attachment of 1M, due to MIME).
9. Incoming mail from unknown senders is automatically 'greylisted' (a properly configured mail server will retry after receiving a 400-level response, spam scripts generally don't).

1.2 Systems must pass Sections 1.0 and 1.1 before being able to send email to our systems. Any systems that cannot pass these tests may alternatively use our Contact Form to contact us, or our clients' mail forms where they have provided one on their own web sites.