Anti-Spam Recommendations for SMTP MTAs
RFC 2505

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                        G. Lindberg
Request for Comments: 2505             Chalmers University of Technology
BCP: 30                                                    February 1999
Category: Best Current Practice

                Anti-Spam Recommendations for SMTP MTAs

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This memo gives a number of implementation recommendations for SMTP,
   [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them
   more capable of reducing the impact of spam(*).

   The intent is that these recommendations will help clean up the spam
   situation, if applied on enough SMTP MTAs on the Internet, and that
   they should be used as guidelines for the various MTA vendors. We are
   fully aware that this is not the final solution, but if these
   recommendations were included, and used, on all Internet SMTP MTAs,
   things would improve considerably and give time to design a more long
   term solution. The Future Work section suggests some ideas that may
   be part of such a long term solution. It might, though, very well be
   the case that the ultimate solution is social, political, or legal,
   rather than technical in nature.

   The implementor should be aware of the increased risk of denial of
   service attacks that several of the proposed methods might lead to.
   For example, increased number of queries to DNS servers and increased
   size of logfiles might both lead to overloaded systems and system
   crashes during an attack.

   A brief summary of this memo is:

   o   Stop unauthorized mail relaying.
   o   Spammers then have to operate in the open; deal with them.
   o   Design a mail system that can handle spam.

Lindberg                 Best Current Practice                  [Page 1]
RFC 2505               Anti-Spam Recommendations           February 1999

1. Introduction

   This memo is a Best Current Practice (BCP) RFC.  As such it should be
   used as a guideline for SMTP MTA implementors to make their products
   more capable of preventing/handling spam.  Despite this being its
   primary goal, an intended side effect is to suggest to the
   sysadmin/Postmaster community which "anti spam knobs" an SMTP MTA is
   expected to have.

   However, this memo is not generally intended as a description on how
   to operate an SMTP MTA - which "knobs" to turn and how to configure
   the options. If suggestions are provided, they will be clearly marked
   and they should be read as such.

1.1. Background

   Mass unsolicited electronic mail, often known as spam(*), has
   increased considerably during a short period of time and has become a
   serious threat to the Internet email community as a whole. Something
   needs to be done fairly quickly.

   The problem has several components:

   o   It is high volume, i.e. people get a lot of such mail in their
       mailboxes.

   o   It is completely "blind", i.e. there is no correlation between
       the receivers' areas of interest and the actual mail sent out (at
       least if one assumes that not everybody on the Internet is
       interested in porno pictures and spam programs...).

   o   It costs real money for the receivers. Since many receivers pay
       for the time to transfer the mailbox from the (dialup) ISP to
       their computer they in reality pay real money for this.

   o   It costs real money for the ISPs. Assume one 10 Kbyte message
       sent to 10 000 users with their mailboxes at one ISP host; that
       means an unsolicited, unexpected, storage of 100 Mbytes.  State
       of the art disks, 4 Gbyte, can take 40 such message floods before
       they are filled. It is almost impossible to plan ahead for such
       "storms".

   o   Many of the senders of spam are dishonest, e.g. hide behind false
       return addresses, deliberately write messages to look like they
       were between two individuals so the spam recipient will think it
       was just misdelivered to them, say the message is "material you

Lindberg                 Best Current Practice                  [Page 2]
RFC 2505               Anti-Spam Recommendations           February 1999

       requested" when you never asked for it, and generally do
       everything they can without regard to honesty or ethics, to try
       to get a few more people to look at their message.

       In fact some of the spam-programs take a pride in adding false
       info that will "make the ISPs scratch their heads".

       It is usually the case that people who send in protests (often
       according to the instructions in the mail) find their mail
       addresses added to more lists and sold to other parties.