Email policy

This page describes the email policy of strugglers.net. You may well be reading this because of an email bounce message you have received.

Introduction

Because I get so much spam I have to be fairly fascist about my willingness to accept any kind of deviation from email best practice. Here follows a description of what my policy is on accepting email, and why.

SMTP-time rejections

The SMTP conversation is the information exchanged between a sending mail server and one of my mail servers. Until the point where one of my mail servers gives the correct response to indicate that it has accepted the email for delivery the fate of the email is in the hands of the sending server.

Why reject at SMTP-time

If for some reason my mail servers accepted an email and then later discovered that it could not be delivered or it was undesirable to do so then my servers would have to generate another email to send to the supposed sender of the original email to let them know that their mail could not be delivered. Simply from a resources point of view it is therefore in my interest to reject email at SMTP time if it is known that it will not be delivered.

Most spam and malware-generated emails have spoofed sender addresses. If my servers were to accept the email and only later discover that it should be rejected then it is highly likely that any bounce message I would generate will be going to an invalid address or an innocent third party. I would have to generate the bounce because spam checking does produce the very occasional false positive and without such a bounce the sender would not have any way to know that the email had not been delivered.

Finally if I were to accept mail and then check its content for spam later, moving any high-scoring items to a separate folder for later perusal, any false positive would have to wait an indeterminate amount of time before being discovered by the recipient. By doing the spam check at SMTP time and rejecting there if deemed necessary, any real human sender immediately gets a bounce message with instructions on what to do next (that may be why you are reading this page in fact). I personally got 68 spam emails on Wednesday 23rd November and I rarely find time to check such emails to see if there are false positives. If I used this strategy for dealing with spam then false positives would likely never be discovered by either me or the people sending them.

Problems

Rejecting unwanted mail at SMTP-time is not totally without downsides. Some mailing list providers for one reason or another are unable to prevent spam and viruses from being distributed through their lists, and their automated bounce management will remove users from the list if deliveries to them bounce a couple of times. Hosts that accept mail and then forward it to remote addresses may also get upset if the next hop rejects a lot of email.

Therefore I do maintain a list of hosts for which rejection at SMTP time is not considered acceptable, and any such mails will instead be accepted and silently discarded. This list is maintained by the postmaster. If my rejection of your spam and malware is causing your system a problem that you believe should not be fixed locally, please contact postmaster.

Viruses

All email goes through a virus checker and any that includes a known virus will be rejected.

Mail for postmaster and abuse

All mail addressed to postmaster or abuse at any domain I host will be accepted. The only exception is email with viruses or malware.

Protocol violations

HELO

“HELO” (or more commonly, “EHLO”) is the SMTP command to identify the sender to the receiver. It is required by RFC 2821, and should be either "the fully-qualified domain name of the sender" or "an address literal" (i.e., an IP address).

Hosts that:

• do not send a HELO/EHLO
• send a malformed HELO that cannot be either a fully-qualified domain name or an IP literal, e.g. MYCOMPUTER178356; or
• send a HELO that describes one of my servers or its IP addresses, i.e. pretend to be me

will be rejected. Almost all such connections are from broken spamware or hosts infected with malware.

Note that hosts which specify a correctly-formatted HELO will be allowed to continue, even if that HELO string does not correspond to a real host in the DNS or an actual IP address. I consider it unwise to be as strict as the RFC allows, because later on the RFC states that it is not acceptable to block email based on HELO data.