Email Policy

SysteMajik.com actively discourages Spam and email sent from incorrectly configured servers. A legitimate email from correctly configured servers should have little problem being delivered. We believe we are relatively compliant with  RFC 2505 – Anti-Spam Recommendations for SMTP MTAs and other RFCs mentioned at the end of this document.

This article covers our policy implementation for incoming and outgoing email.  These policies apply to all email destined to or originating from systemajik.com,  toucantango.com, and other domains for which we may handle email.

Our e-mail rules are separated into four categories:

• Incoming Internet Mail – Internet-connected MTAs to our MX MTA on port 25.
• Outgoing Internet Mail – Our MTA to other MX MTAs on port 25.
• Message Submission Agents – Mobile users as an MSA to our MX MTA using port 587.
• Internal Mail Exchange – MSA or MTA to MTA or MDA (not discussed here).

Incoming Internet Email

These policy implementations help ensure that incoming mail is from legitimate senders. Legitimate email content sent by systems compliant with the RFCs and standard practices should never be blocked. Bulk email systems tend to be are non-compliant and their email may be unintentionally dropped. Mail from systems attempting to obscure their identity is highly likely to have their email refused.

Incoming Email Policies

Our systems implement a number of policies. These are all intended to enable legitimate mail while discouraging SPAM. We implement whitelists and blacklists to override the automated policies as required.

• Servers must accept reasonable response delays as specified in RFC 5321 (section 4.5.3.2). Processing delays may be applied to suspected spam. 🙂 This has proven to be a very effective method of reducing spam volume.
• Servers must retry following temporary errors as specified RFC 5321 (4.2.1, 4.5.4).
• Mail from servers listed in selected DNS blacklists will be refused. An attempt will be made to accept mail to the postmaster or abuse.
• The mail server should pass rDNS verification. This requires an IP address PTR record returning a name for which an A record yields the IP address. Servers without the necessary DNS records will trigger spam avoidance processes. :! Some domains will refuse your email in this case.
• The identity provided in the EHLO (or HELO) command must be the fully qualified domain name of the server (mail.example.com) as per RFC 5321 (4.1.1.1). The connection will be refused if the identity is an unqualified hostname (mail), an IP address (192.0.2.15), or belongs to us. The connection will be deferred until whitelisted if the identity is a domain literal ([192.0.2.15]) or a second-level domain name (example.com).
• There should be an SPF record for the provided identity. If provided, the host must be permitted by the policy. In most cases, this policy should be definitive  (terminated with -all).
• There should be an SPF record for the envelope sender address provided in the MAIL command. This will be used to refuse senders who are not allowed by the specified SPF policy.
• The envelope sender address, unless null, must have a domain listed in DNS.
• The envelope sender domain must not be local. Exceptions may be made by a whitelist.
• The addresses specified in RECIPIENT commands must be active local addresses. As recommended in RFC 2505 (2.1) we do not allow message relaying.
• The message headers provided following the DATA command must contain a valid email address to which replies can be sent.
• The message headers provided following the DATA command must contain the minimal required headers. RFC 5322 (3.6, 3.6.2) states these are the origination date (Date) and originator address (From/Sender). We may require a  message-id and subject headers.
• Messages containing malware or classified as spam by our spam filter will be refused.
• Messages that exceed our maximum message size will be refused. Our limit is quite generous, and most messages are rejected for size before reaching us.

Backscatter Spam

One mechanism used by Spam senders is to fake the envelope sender address.  This results in a bounce notification being sent to another server.  This occurs when email validations are done after accepting the message, or when the email has been relayed through an intermediate server.

Our servers perform all validations before accepting email. In most cases, the sending server should belong to the sending domain. This should prevent any backscatter. Some unpreventable backscatter from mail sent through open or semi-open relays may occur when we refuse SPAM.

DNS Blackists

The Spamhaus Project maintains a set of lists aimed at blocking Spam. Its policies provide for easy removal from the list for legitimate mailers using a fixed address. A link to the Spamhaus entry used is included in our bounce message. Use this link to determine why your address is blocked.

The majority of the email we block with this list is from the exploits list. Almost all the rest is from the non-MTA addresses list. Analysis of the email being blocked indicates that the blocked email is Spam. Mail from a Spamhaus listed IP address is highly unlikely to be delivered here.  🙂 This blacklist is our most effective method of blocking spam.

Home users blocked by this list should use their ISP’s mail relay to send the email. Other mailers should follow the steps outlined on the Spamhaus site.  Follow the link provided in the bounce message to find out why your email server is blocked.

We also use a blacklist from spamcop.net. Getting listed on this list will trigger some spam evasion measures. These will delay messages sent from legitimate servers.

We filter all incoming emails through a spam filter which uses a number of DNS blacklists. Sending domains which get listed on multiple blacklists are likely to have their email classified as SPAM.

Greylisting

For new senders, we may temporarily defer the delivery of email using a greylist.  We attempt to avoid using the greylist if the mail is unlikely to be SPAM. Your email server should automatically retry the message after a reasonable delay, at which time it will be accepted.  Some systems forward deferred emails to separate servers tuned for redelivery. Depending on the IP addresses of these servers additional delays be imposed.

Greylisted email should never be bounced. If you receive a message indicating that the email has bounced and will not be delivered contact your email provider. To get the message delivered, resend it a few minutes after it was originally sent. Some servers send a message reporting the message has been delayed soon after it is sent. This notification should indicate that the message will be retried.

Used as a primary filter greylisting can drop over 9o% of SPAM while imposing minimal penalties on legitimate email.  🙂 We have adopted other approaches that significantly reduce the amount of email filtered using the greylist.

Outgoing Email

We apply the available mechanisms to allow the origin of our email to be verified. The two current mechanisms available are Sender Policy Framework (SPF) and Domain Key Identified Mail (DKIM). Both mechanisms rely on DNS to publish validation data. We have implemented both mechanisms.

The two mechanisms perform disjoint validations.  SPF verifies the sender’s address but provides no validation of the content.  DKIM verifies the content but provides no validation of the envelope.   Doing an SPF lookup on the signing domain does provide some assurance that both factors match.

All our DNS names have SPF data both as TXT and SPF records. SPF rules ending ‘-all’ exist for all our domains and hosts. Only domains and hosts which are expected to send email have published  sender addresses. More information on SPF is available from  http://www.openspf.org/.

All outgoing mail is now signed using a DKIM signature. Any unsigned email sent from our server without a valid DKIM signature is likely SPAM. Please notify our postmaster if you receive SPAM from us. More information on DKIM is available from http://www.dkim.org/.

Email to and from Administrative Addresses

Administrative addresses, such as postmaster and abuse are privileged addressed. We skip some checks to increased the likelihood of delivery. Email sent to these addresses by legitimate servers should be delivered. Other servers may be able to deliver email to these addresses. The SPAM filter will reject email at a lower threshold than normal. Email from an incorrectly configured server may be rejected as SPAM. Please examine your bounce message and correct any misconfiguration.

If necessary, try routing the email via your ISP’s email relay. If all else fails, send the email from another domain. This should only be required if you have discovered a problem with our configuration or if your server is on several public blacklists. You should be able to use an email address from a service like Gmail, Yahoo, or Microsoft Live.

Abuse of an administrative address may get all mail from your site blacklisted. Almost all email sent to our administrative addresses has been Spam.  This has been verified by several factors.

Notifications

Mailing systems may send automated notifications.  The null address (<>)  is used to prevent message loops.  We sign the sender address for all outgoing emails.  Notifications to signed addresses are accepted.  Use of the null address for non-notification traffic is blocked.

Relaying and Mobile Users

This site only accepts incoming emails for local domains. Incoming email for all other domains is refused.

All outgoing mail must originate from authorized hosts on our network or using authentication on the submission port. Mobile users must authenticate on the submission port to send an email. This port works from the Internet and on the LAN.

Relevant Documentation

This document is a revision of our original policy which was originally released May 5, 2010.   We drew on the following standards and documents in preparing our policies.

• http://tools.ietf.org/html/rfc2505 – Anti-Spam Recommendations for SMTP MTAs
• http://tools.ietf.org/html/rfc2822 – Internet Message Format
• http://tools.ietf.org/html/rfc4408 – Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail
• http://tools.ietf.org/html/rfc5321 – Simple Mail Transfer Protocol
• http://tools.ietf.org/html/rfc5322 – Internet Message Format
• http://www.maawg.org/sites/maawg/files/news/MAAWG_Port25rec0511.pdf – Managing Port 25 for Residential or Dynamic IP Space
  Benefits of Adoption and Risks of Inaction