Editing Anti-spam techniques (section)

===Strict enforcement of RFC standards===
{{Further|Simple Mail Transfer Protocol#Related Requests For Comments{{!}}SMTP RFC standards}}

Many spammers use poorly written software or are unable to comply with the standards because they do not have legitimate control of the computer they are using to send spam ([[zombie computer]]).  By setting tighter limits on the deviation from RFC standards that the [[Mail transfer agent|MTA]] will accept, a mail administrator can reduce spam significantly - but this also runs the risk of rejecting mail from older or poorly written or configured servers.

'''Greeting delay''' – A sending server is required to wait until it has received the SMTP greeting banner before it sends any data. A deliberate pause can be introduced by receiving servers to allow them to detect and deny any spam-sending applications that do not wait to receive this banner.

'''Temporary rejection''' – The [[Greylisting (email)|greylisting]] technique is built on the fact that the [[SMTP]] protocol allows for temporary rejection of incoming messages. Greylisting temporarily rejects all messages from unknown senders or mail servers – using the standard 4xx error codes.<ref>[http://tools.ietf.org/html/rfc3463 "4.XXX.XXX Persistent Transient Failure"] {{webarchive|url=https://web.archive.org/web/20160303174740/http://tools.ietf.org/html/rfc3463 |date=2016-03-03 }}, IETF.org</ref> All compliant MTAs will proceed to retry delivery later, but many spammers and spambots will not. The downside is that all legitimate messages from first-time senders will experience a delay in delivery.

'''HELO/EHLO checking''' – {{IETF RFC|5321|}} says that an SMTP server "MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis." Systems can, however, be configured to 
* Refuse connections from hosts that give an invalid HELO – for example, a HELO that is not an [[FQDN]] or is an IP address not surrounded by square brackets.
* Refusing connections from hosts that give an obviously fraudulent HELO
* Refusing to accept email whose HELO/EHLO argument does not resolve in DNS

'''Invalid pipelining''' – Several SMTP commands are allowed to be placed in one network packet and "pipelined".  For example, if an email is sent with a CC: header, several SMTP "RCPT TO" commands might be placed in a single packet instead of one packet per "RCPT TO" command.  The SMTP protocol, however, requires that errors be checked and everything is synchronized at certain points.  Many spammers will send everything in a single packet since they do not care about errors and it is more efficient.  Some MTAs will detect this invalid pipelining and reject email sent this way.

'''Nolisting''' – The email servers for any given domain are specified in a prioritized list, via the [[MX record]]s. The [[nolisting]] technique is simply the adding of an MX record pointing to a non-existent server as the "primary" (i.e. that with the lowest preference value) – which means that an initial mail contact will always fail. Many spam sources do not retry on failure, so the spammer will move on to the next victim; legitimate email servers should retry the next higher numbered MX, and normal email will be delivered with only a brief delay.

'''Quit detection''' – An SMTP connection should always be closed with a QUIT command. Many spammers skip this step because their spam has already been sent and taking the time to properly close the connection takes time and bandwidth. Some MTAs are capable of detecting whether or not the connection is closed correctly and use this as a measure of how trustworthy the other system is.