Editing Anti-spam techniques (section)

==Automated techniques for email senders==

There are a variety of techniques that email senders use to try to make sure that they do not send spam.  Failure to control the amount of spam sent, as judged by email receivers, can often cause even legitimate email to be blocked and for the sender to be put on [[DNSBL]]s.

===Background checks on new users and customers===

Since spammer's accounts are frequently disabled due to violations of abuse policies, they are constantly trying to create new accounts.  Due to the damage done to an ISP's reputation when it is the source of spam, many ISPs and web email providers use [[CAPTCHA]]s on new accounts to verify that it is a real human registering the account, and not an automated spamming system.  They can also verify that credit cards are not stolen before accepting new customers, check [[the Spamhaus Project]] ROKSO list, and do other background checks.

===Confirmed opt-in for mailing lists===
{{Main|Opt-in email}}
A malicious person can easily attempt to subscribe another user to a [[mailing list]] — to harass them, or to make the company or organisation appear to be spamming. To prevent this, all modern mailing list management programs (such as [[GNU Mailman]], [[LISTSERV]], [[Majordomo (software)|Majordomo]], and [[qmail]]'s ezmlm) support "confirmed opt-in" by default. Whenever an email address is presented for subscription to the list, the software will send a confirmation message to that address. The confirmation message contains no advertising content, so it is not construed to be spam itself, and the address is not added to the live mail list unless the recipient responds to the confirmation message.

===Egress spam filtering===
{{Main|Egress filtering}}

Email senders typically now do the same type of anti-spam checks on email coming from their users and customers as for inward email coming from the rest of the Internet. This protects their reputation, which could otherwise be harmed in the case of infection by spam-sending malware.

===Limit email backscatter===
{{Main|Backscatter (email)}}

If a receiving server initially fully accepts an email, and only later determines that the message is spam or to a non-existent recipient, it will generate a [[bounce message]] back to the supposed sender. However, if (as is often the case with spam), the sender information on the incoming email was forged to be that of an unrelated third party then this bounce message is [[Backscatter (email)|backscatter spam]]. For this reason it is generally preferable for most rejection of incoming email to happen during the SMTP connection stage, with a 5xx error code, while the sending server is still connected. In this case then the ''sending'' server will report the problem to the real sender cleanly.

===Port 25 blocking===
[[Firewall (networking)|Firewall]]s and [[router (computing)|router]]s can be programmed to not allow [[SMTP]] traffic (TCP port 25) from machines on the network that are not supposed to run [[Mail Transfer Agent]]s or send email.<ref>{{cite web|url=http://www.eweek.com/c/a/Security/Shutting-Down-the-Highway-to-Internet-Hell/2/|title=Shutting Down the Highway to Internet Hell|publisher=eWeek|date=2005-04-08|access-date=2008-05-31}}</ref>  This practice is somewhat controversial when ISPs block home users, especially if the ISPs do not allow the blocking to be turned off upon request.  Email can still be sent from these computers to designated [[smart host]]s via port 25 and to other smart hosts via the email submission port 587.

===Port 25 interception===
[[Network address translation]] can be used to intercept all port 25 (SMTP) traffic and direct it to a mail server that enforces rate limiting and egress spam filtering.  This is commonly done in hotels,<ref>[http://ask-leo.com/why_cant_i_send_mail_from_my_hotel_room.html Why can't I send mail from my hotel room?] {{webarchive|url=https://web.archive.org/web/20060110041305/http://ask-leo.com/why_cant_i_send_mail_from_my_hotel_room.html |date=2006-01-10 }} AskLeo!, December 2005</ref> but it can cause [[email privacy]] problems, as well making it impossible to use [[Simple Mail Transfer Protocol#STARTTLS or "Opportunistic TLS"|STARTTLS]] and [[SMTP-AUTH]] if the port 587 submission port isn't used.

===Rate limiting===
Machines that suddenly start sending lots of email may well have become [[zombie computer]]s.  By limiting the rate that email can be sent around what is typical for the computer in question, legitimate email can still be sent, but large spam runs can be slowed down until manual investigation can be done.<ref>[http://www.eweek.com/article2/0,1895,1615494,00.asp Rate Limiting as an Anti-Spam Tool]{{Dead link|date=August 2024 |bot=InternetArchiveBot |fix-attempted=yes }} eWeek, June 2004</ref>

===Spam report feedback loops===
{{Main|Feedback Loop (email)}}

By monitoring spam reports from places such as [[spamcop]], [[AOL]]'s feedback loop, and Network Abuse Clearinghouse, the domain's abuse@ mailbox, etc., ISPs can often learn of problems before they seriously damage the ISP's reputation and have their mail servers blacklisted.

===FROM field control===

Both malicious software and human spam senders often use forged FROM addresses when sending spam messages. Control may be enforced on SMTP servers to ensure senders can only use their correct email address in the FROM field of outgoing messages. In an email users database each user has a record with an email address. The SMTP server must check if the email address in the FROM field of an outgoing message is the same address that belongs to the user's credentials, supplied for SMTP authentication. If the FROM field is forged, an SMTP error will be returned to the email client (e.g. "You do not own the email address you are trying to send from").

===Strong AUP and TOS agreements===
Most ISPs and [[webmail]] providers have either an [[Acceptable Use Policy]] (AUP) or a [[Terms of Service]] (TOS) agreement that discourages spammers from using their system and allows the spammer to be terminated quickly for violations.