Difference between revisions of "Email policy"

From Strugglers
Jump to: navigation, search
(protocol violations, unreplyable email, dynamic IPs)
m (SMTP synchronisation: typo)
Line 41: Line 41:
  
 
===SMTP synchronisation===
 
===SMTP synchronisation===
SMTP is a request-response protocol in that when a mail server connections to another mail server it is expected to issue certain commands, wait for a response and then issue other commands.
+
SMTP is a request-response protocol in that when a mail server connects to another mail server it is expected to issue certain commands, wait for a response and then issue other commands.
  
Spammers are in the business of sending out as much email as possible in as short a time as possible and do not care for standards or graceful handling of any possible problems.  Therefore they tend to connect, send all their commands and then quit without trying to deal with any possible error condition.
+
Spammers are in the business of sending out as much email as possible in as short a time as possible and do not care for standards or graceful handling of any possible problems.  Therefore they tend to connect, send all their commands/data and then quit without trying to deal with any possible error condition.
  
 
In order to deal with the worst such spammers my mail servers will disconnect you for sending commands in the wrong order, or before they are expected.
 
In order to deal with the worst such spammers my mail servers will disconnect you for sending commands in the wrong order, or before they are expected.

Revision as of 11:25, 13 December 2005

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

I enforce fairly strict adherence to protocols where it makes sense, because there is very rarely any excuse for not complying with the relevant standards. Anyone who does not is either compromised and spewing spam, or has a terribly misconfigured system and needs to be made aware of it.

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.

SMTP synchronisation

SMTP is a request-response protocol in that when a mail server connects to another mail server it is expected to issue certain commands, wait for a response and then issue other commands.

Spammers are in the business of sending out as much email as possible in as short a time as possible and do not care for standards or graceful handling of any possible problems. Therefore they tend to connect, send all their commands/data and then quit without trying to deal with any possible error condition.

In order to deal with the worst such spammers my mail servers will disconnect you for sending commands in the wrong order, or before they are expected.

Serious MIME defects

MIME is a standard used for the encapsulation of multiple types of media into a single message stream, commonly used when one wants to include file attachments into an email. Many viruses and other malware have hastily-written MIME support that produces incorrectly formatted messages. They may also be attempts to confuse or bypass antispam and antivirus systems. Since there is no good reason for generating such emails, messages containing serious defects will be rejected at SMTP time.

Unreplyable emails

If it's clear that it will be impossible to respond to an email then my mail servers will not accept it, since such emails are often sent by spammers and even if they aren't they are of questionable usefulness. There are several different reasons why a particular email may be unreplyable.

Nonexistent domain in From: address

If the domain of the address in the From: header does not exist in DNS then it will not be possible to reply to the email. At best this is a configuration mistake which may lead to someone composing a reply only to find it cannot be delivered. At worst this will be the result of spammers and viruses randomly generating addresses for their From: headers. The best course of action is to reject at SMTP time.

All MX records missing or invalid

In DNS the MX record is used to specify where to connect to in order to send email to users at a given domain. If a domain has no MX records or all MX records are invalid (they resolve to IP addresses that are not publically routed on the Internet) then it will not be possible to reply to the email. This is often done with domains that are intended to never appear in email addresses, which is even more reason not to accept email that purports to come from them.

Serious syntax errors in email headers

If the format of the message's headers is sufficiently incorrect as to cause problems with delivery or reply then the email will not be accepted.

DNSBLs

My mail servers use several different DNS-based block lists and connecting hosts found in these lists will have their messages rejected at SMTP time.

Dynamic IP addresses

Mail directly from known dynamic IP addresses will not be accepted due to the masses of compromised machines sitting on domestic Internet connections spewing spam. If you're on a dynamic IP address and you need to run your own mail server then use your ISP as a smarthost, or get the means to relay via a mail server that is not in a ghetto netblock.

Currently dul.dnsbl.sorbs.net is used for this purpose.

more to come