view Side-By-Side changes

INTERNET-DRAFT                                           Gunnar Lindberg
draft-lindberg-anti-spam-mta-00.txt
draft-lindberg-anti-spam-mta-01.txt                  Chalmers University
Expires April, June, 1998                                         of Technology
                                                             12 Nov
                                                             16 Dec 1997

                   Anti-Spam Requirements on an SMTP MTA

Abstract

   This memo gives a number of technical requirement on SMTP [1] MTA:s MTAs
   (Mail Transfer Agents, e.g. sendmail) to make them more capable of
   reducing the impact of Spam(*). spam(*).

   The intent is that these requirements will help clean up the spam
   situation, if applied on enough SMTP MTA:s 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 solution, but if these
   requirements were included, and used, on all Internet SMTP MTA:s, MTAs,
   things would improve considerably and give time to design a more long
   term solution. Some ideas are presented in the Addendum. Future Work section.

   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.

Status of This Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts. Comments on this draft should
   be sent to <anti-spam@chalmers.se>.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

1. Introduction

   This memo the result of discussions in an ad hoc group containing
   Swedish universities and most Swedish ISPs. Since the group consist
   of quite a number of people noone is mentioned explicitly but all
   organizations are listed under Acknowledgements below.






Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 1]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


1.1


1. Introduction

   This memo is intended to become a Best Current Practice (BCP) RFC.
   As such it should be used as a guideline for SMTP MTA vendors to make
   their products more capable of preventing/handling spam.

1.1. Background

   Mass unsolicited electronic mail, often known as Spam(*), 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   Several of the senders are anything but serious, e.g hide
       behind false addresses or mail hosts that refuse to receive.

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

       It is not uncommon 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.

   o   It is quite common practice to make use of third party hosts
       as relays to get the spam mail sent out to the receivers. This
       is almost certainly illegal in all countries, but with the
       original sender in the US, the (innocent) relay in Sweden and



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 2]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


       the list of receivers back in the US the legal aspects become
       almost overhelming.

1.2

1.2. Scope

   This memo has no intent to be the final solution to the spam problem.



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 2]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 1997

   If, however, enough Internet MTA:s MTAs did implement enough of the rules
   described below (especially the Non-Relay rules), we would get the
   spammers out in the open, where they could be taken care of. Either
   pure legal actions would help, or we can block them technically using
   other rules described below (since the Non-Relay rules now make them
   appear openly, with their own hosts and domains, we can apply various
   access filters against them). In reality, a combination of legal and
   technical methods is likely to give the best result.

   This way, the spam problem could be reduced enough to allow the
   Internet community to design and deploy a real and general solution.

1.3

1.3. Terminology

   Throughout this memo we will use the following terminology: terminology of RFC2119, [4]:

   o   "MUST"

       This word or the adjective "REQUIRED" means that the item is
       an absolute requirement.

   o   "SHOULD"

       This word or the adjective "RECOMMENDED" means that there may
       exist valid reasons in particular circumstances to ignore
       this item, but the full implications should be understood and
       the case carefully weighed before choosing a different course.

   o   "MAY"

       This word or the adjective "OPTIONAL" means that this item is
       truly optional.  One vendor may choose to include the item
       because a particular marketplace requires it or because it
       enhances the product, for example; another vendor may omit
       the same item.

2 Requirements

   Here

1.4. Using DNS information

   In the memo we first give a brief list of requirements, followed by a more
   thorough discussion of each sometimes suggest use of them.

   1)  MUST be able to control (deny) usage as Mail Relay.

   2)  MUST be able to verify "MAIL From" domain (using DNS host or using
       other means).

   3a) MUST be able domain names, FQN,
   rather than IP addresses. This is because FQN are intuitively much
   easier to refuse mail from a specific "MAIL From" user
       (user foo@domain.com). use.



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 3]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   3b) MUST be able


   However, all such usage depends heavily on DNS and .IN-ADDR.ARPA
   information. Since it is fairly easy to refuse mail from an entire "MAIL From" domain
       (entire forge that, either by false
   cache information injected in DNS servers or spammers running their
   own DNS, host and domain domain.com).

   4)  MUST names must be able used with care, e.g. verify
   that the translation address->name corresponds to name->address.

1.5. SMTP Return Codes

   Our basic assumption is that refuse/accept is handled at the SMTP
   layer and that an MTA that decides to refuse mail from a host / a group of hosts.

   5)  MUST be able message should do so
   while still in the SMTP dialogue. First, this means that we do not
   have to log all occurences store a copy of anti-relay service
       denials.

   6)  SHOULD be able a message we later decide to verify <local-part> in outgoing mail.

   7)  SHOULD be able refuse and
   second, our responsibility for that message is low or none - since we
   have not yet read it we leave it to limit ("rate control") mail flow.

   8)  MUST be able the sender to configure for different handle the error.

   SMTP has several classes of Return Codes Codes, see [1] for
       different rules (e.g. 451 Temp Fail vs 551 a discussion:

   o   5xx
       is a Fatal Error).

   The discussion below often ends up Error and results in a need to do various forms of
   pattern matching, on domain/host names the mail transfer being
       terminated and the mail returned to sender. For some events,
       like "Denied - you're on IP addresses/subnets.
   It is RECOMMENDED that the data/template for doing so may be supplied
   outside of spammer's list", this is
       probably the MTA, e.g. that correct response and the pattern matching rules be included right thing to say.

       A mistake in the MTA but that the actual patterns configuration, however, may be in an external file.

   Of course all string matching MUST be non case sensitive.

2.1 Control use as Mail Relay

   The MTA MUST be able cause valid mail to deny/accept
       bounce back to the sender, which may be Mail Relay based quite unfortunate.

   o   4xx
       is a Temporary Error and results in the mail transfer being
       put back on queue again and a
   combination of:

   o   "RCPT To" addresses (domains).

   o   Sending host's FQN hostname.

   o   Sending host's IP address.

   In all cases the new attempt being made later.
       Therefore, configuration MUST support wild cards (for FQNs) mistakes are much less fatal and
   masks (for IP addresses), i.e. domain.com or *.domain.com; 10.0.0.0/8
   or 192.168.1.0/24.

   The configuration SHOULD allow for you
       may correct them before any real damage is done.

       A 4xx response also makes the decision data spammer's host re-queue the mail
       and if it really is his own host who gets to be supplied
   by an external source, e.g. text file or dbm database.

2.2 Verify "MAIL From"

   The MTA MUST be able do this, it is
       probably a good thing. If, on the other hand, he is using
       someone else as Relay Host, all the mail being queued is a
       fairly strong evidence that something illegal is going on and
       should cause attention at the Relay Host.

   4xx, Temporary Error, is almost always the recommended Return Code,
   since it both allows us to perform correct our mistakes and keeps the spam
   mail in the mail queue at the sender for a simple "sanity check" longer period of time.

   However, 4xx Temporary Errors may have unexpected interaction with
   MX-records. If the "MAIL
   From" receiving domain has several MX records and refuse the
   lowest preference MX-host refuses to receive mail if that from a certain
   "MAIL From" domain is
   nonexistent. To overcome temporary errors/problems in the DNS, Return
   Codes like 4xx are recommended; however with a "451" Response Code, the MTA MAY allow for Return
   Codes that show real DNS state sending host may
   choose to - 4xx for temporary problems and 5xx often will - use the next host on the MX list.



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 4]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   for NonExistent domain.

2.3 Refuse "MAIL From"

   The MTA MUST be able


   If that next MX host does not have the same refuse-list, it will of
   course accept the mail, only to refuse find that the final host still
   refuses to receive mail from a specific "MAIL
   From" user (foo@domain.com) or from an entire "MAIL From" domain
   (domain.com). In general this kind that piece of rules are easily overcome by mail ("MAIL From"). I.e. our intent
   was to make the spammers changing "MAIL From" every so often, offending mail stay at the offending sender's host
   and fill up his mqueue disk, but it all ended up at our friend, the ability to
   block a certain user or
   next lowest preference MX-host.

2. Requirements

   Here we first give a certain domain is quite helpful while an
   attack has just been discovered and is ongoing.

   Given brief list of requirements, followed by a combination more
   thorough discussion of "domain sanity check", "non-relay" and
   "<local-part> verification" the method may each of them.

   1)  MUST be more useful.

2.4 Refuse able to restrict unauthorized use as Mail Relay.

   2)  MUST provide "Received:" lines with enough information to
       make it possible to trace the mail from a group of hosts

   The MTA path, despite spammers use
       forged host names in HELO statements etc.

   3)  MUST provide local log information that makes it possible to
       trace the event afterwards.

   4)  MUST log all occurences of anti-relay/anti-spam actions.

   5)  SHOULD be able to accept or refuse mail from a specific host or
   from / a group of hosts.

   It is REQUIRED that the MTA support decisions based on FQN hostnames
   (host.domain.com), on domain names with wild cards (*.domain.com), on
   individual IP addresses (10.11.12.13) or on IP addresses with a
   prefix length (10.0.0.0/8, 192.168.1.0/24).

   It is also REQUIRED that these decision rules can

   6a) SHOULD be combined, e.g.

       accept   host.domain.com
       refuse   *.domain.com
       accept   10.11.12.13
       accept   192.168.1.0/24 able to refuse   10.0.0.0/8

   IP-address/length is REQUIRED. However, early implementations with
   wild cards, e.g. 10.11.12.*, instead are of course much better then
   without.

2.5 Log service denials

   The MTA mail from a specific "MAIL From"
       user, <foo@domain.example>.

   6b) SHOULD be able to refuse mail from an entire "MAIL From"
       domain <.*@domain.example>.

   7)  SHOULD be able to limit ("rate control") mail flow.

   8)  SHOULD be able to verify "MAIL From" domain (using DNS or
       using other means).

   9)  SHOULD be able to verify <local-part> in outgoing mail.

   10) MUST be able to log all service denial actions based configure for different Return Codes for
       different rules (e.g. 451 Temp Fail vs 551 Fatal Error).

   The discussion below often ends up in a need to do various forms of
   pattern matching, on domain/host names and on IP addresses/subnets.
   It is RECOMMENDED that the
   anti-spam rules. The log entries SHOULD contain at least:

   o   Refuse information, i.e. why data/template for doing so may be supplied
   outside of the request was refused ("Mail
       From", Relaying Denied, Spam User, Spam Host, etc).

   o   "RCPT To" addresses (domains).

   o   Offending host's FQN hostname. MTA, e.g. that the pattern matching rules be included
   in the MTA but that the actual patterns may be in an external file.
   It is also RECOMMENDED that the pattern matching rules (external
   file) may contain regular expressions, to give maximum flexibility.



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 5]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   o   Offending host's IP address.

   o   Other relevant information (e.g. given during


   Of course all string matching on domain/host names MUST be non case
   sensitive. Since <local-part> may be case sensitive it may be natural
   to keep that here. However, since <sPAmMeR@domain.example> and
   <spammer@domain.example> is most probably the SMTP
       dialogue, before we decided same user and since the
   string compares are used to refuse the request).

2.6 Verify <local-part>

   The MTA SHOULD allow his messages, we suggest that outgoing mail has its
   <local-part> verified
   so that the sender name is be compared non case sensitive too.

2.1. Restricting unauthorized Mail Relay usage

   Unauthorized usage of a real user or an existing alias. This is
   basically to protect the rest host as Mail Relay means theft of the Internet from various "typos"
       (MAIL From <fo0bar@domain.com>) relay's
   resources and malicious users
       (MAIL From <I.am.unknown.to.you.he.he@domain.com>).

   As always this can be overcome by spammers really wanting to do so,
   but with more strict rules for relaying puts the owner's reputation at risk. It also makes it becomes harder and harder.
   In fact, catching "typos"
   impossible to filter out or block spam without at the initial (and official) mail relay
   should in itself be enough motivation for this requirement.

2.7 Rate Control

   The MTA SHOULD make it possible for same time
   blocking legitimate mail.

   Therefore, the mail host MTA MUST be able to control the rate control/refuse such Relay usage.

   In an SMTP session we have 3 elements, with which mail is sent a varying degree of
   trust:

   1)  "MAIL From:"              Easily and often forged.
   2)  "RCPT To:"                Correct, or received. The idea at least intended.
   3)  "SMTP Caller" (host)      IP.src addr OK, FQN may be OK.

   Since 1) is twofold:

   o   If so easily and often forged, we happen cannot depend on that at
   all to have a spammer legally using authorize usage of our mail host
       (i.e. a legal mail user with an existing, legal, account that
       sends out spam - as Mail Relay.

   Instead, the MTA MUST be sending spam illegal able to authorize Mail Relay usage based on
   a combination of:

   o   "RCPT To" address (domain).
   o   "SMTP Caller" FQN hostname.
   o   "SMTP Caller" IP address.

   The suggested algorithm is:

   a)  If "RCPT To" is one of "our" domains, local or not) a domain that
       we may want accept to reduce the speed with which he sends out mail. This forward to (alternate MX), then accept to Relay.

   b)  If "SMTP Caller" is not
       without controversy and must be used with extreme care, but
       it may protect the rest of the Internet from him.

   o   If we are under a spam attack it may help us considerably just
       being able to slow down the incoming mail rate for that
       particular user/host.

   For receiving mail the MTA SHOULD be able to do so based on "MAIL
   From" user, "MAIL From" domain, sending host (name/address) authorized, either its IP.src or a
   combination.

   In both cases 4xx Return Code is recommended.

2.8 Return Codes

   Our basic assumption is that refuse/accept is handled at its FQN
       (depending on if you trust the SMTP
   layer and that an MTA that decides DNS), then accept to Relay.

   c)  Else refuse a message should do so
   while still in the SMTP dialogue. First this means that we do not to Relay.

   When doing a) you have to store a copy make sure all kinds of a message we later decide to refuse SMTP source routing
   (both the official [@a,@b:u@c] and
   second our responsibility for that message the '%' hack) is low either removed
   completely before the test, or none - since we is at least not taken into account.

   In all cases the configuration MUST support wild cards (for FQNs) and



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 6]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   have not read it we leave it to


   masks (for IP addresses), i.e. domain.example or *.domain.example;
   10.0.0.0/8 or 192.168.1.0/24.

   The configuration SHOULD allow for the sender decision/template data to handle the error. be
   supplied by an external source, e.g. text file or dbm database. The MTA MUST
   decision/template SHOULD be configurable allowed to use different Return Codes for
   different rules (e.g. 451 Temp Fail vs 551 Fatal Error). Now, this
   must be used with great care:

   o   5xx
       is contain regular expressions.

2.2. Received: lines

   The MTA MUST prepend a Fatal Error and results "Received:" line, [2], in the mail, with
   enough information to make it possible to trace the mail transfer being
       terminated and path by
   reading the mail returned to sender. For some events,
       like "Denied - you're on the spammer's list", this is probably
       the correct response and headers themselves, even if spammers use bogus
   information in HELO statements etc.

   Such a "Received:" line MUST contain:

   o   The IP address of the right thing to say.

       A mistake caller.

   o   The 'date-time' as described in configuration, however, may cause valid mail to
       bounce back RFC822, [2], pp 18.

   It SHOULD contain:

   o   The FQN corresponding to the sender, which may be quite unfortunate. callers IP address.

   o   4xx   The argument given in the "HELO" statement.

   It is a Temporary Error and results suggested that most other "Received:" fields described in
   RFC822 be included in the mail transfer being
       put back on queue again and a new attempt being made later.
       Therefore, configuration mistakes "Received:" lines.

   These requirements are much less fatal, which
       really helps out.

       A 4xx response deliberately stronger than RFC1023, [3].

2.3. Event logs

   The MTA MUST provide enough local log information to make the spammer's host re-queue the mail and
       if it really is his own host who gets possible
   to do this, it is
       probably a good thing. If, on trace the other hand, he is using
       someone else as Relay Host, event. This includes most of the information put into
   the "Received:" lines, see above.

2.4. Log anti-relay/anti-spam actions

   The MTA MUST log all anti-relay/anti-spam actions. The log entries
   SHOULD contain at least:

   o   Time information.

   o   Refuse information, i.e. why the request was refused ("Mail
       From", "Relaying Denied", "Spam User", "Spam Host", etc).

   o   "RCPT To" addresses (domains).



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 7]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   o   Offending host's IP address.

   o   Offending host's FQN hostname.

   o   Other relevant information (e.g. given during the SMTP
       dialogue, before we decided to refuse the request).

2.5. Refuse mail being queued is based on SMTP Caller address

   The MTA SHOULD be able to accept or refuse mail from a
       fairly strong evidence specific host
   or from a group of hosts. Here we mean the IP.src address or the FQN
   that something illegal is going on.

   4xx, Temporary Error, its .IN-ADDR.ARPA resolves to (depending on whether your trust
   the DNS). This functionality could be implemented at a firewall, but
   since the MTA should be able to "defend itself" we require it here.

   It is almost always RECOMMENDED that the recommended Return Code. MTA decide based on FQN hostnames
   (host.domain.example), on wild card domain names (*.domain.example),
   on individual IP addresses (10.11.12.13) or on IP addresses with a
   prefix length (10.0.0.0/8, 192.168.1.0/24).

   It is also RECOMMENDED that these decision rules can be combined to
   form a flexible list of accept/refuse/accept/refuse, e.g:

       accept   host.domain.example
       refuse   *.domain.example
       accept   10.11.12.13
       accept   192.168.1.0/24
       refuse   10.0.0.0/8

   IP-address/length is RECOMMENDED. However, 4xx Temporary Errors may have unexpected interaction implementations with
   MX-records. If the receiving domain has several MX records and wild
   cards, e.g. 10.11.12.* (classful networks on byte boundaries only)
   are of course much better then those without.

   To improve filtering even more, the
   lowest preference MX-host refuses MTA MAY provide complete regular
   expressions to be used for hostnames; possibly also for IP addresses.

2.6. Refuse based on "MAIL From"

   The MTA SHOULD be able to refuse to receive mail from a certain specific
   "MAIL From" user (foo@domain.example) or from an entire "MAIL From"
   domain with (domain.example). In general this kind of rules are easily
   overcome by the spammers changing "MAIL From" every so often, but the
   ability to block a "451" Response Code, certain user or a certain domain is quite helpful
   while an attack has just been discovered and is ongoing.

2.7. Rate Control

   The MTA SHOULD provide tools for the sending mail host may
   choose to use control the other host rate



Lindberg et.al.  Anti-Spam Requirements on the MX list. an SMTP MTA          [Page 8]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   with which mail is sent or received. The idea is twofold:

   1)  If that other MX host does not have the same refuse-list, it will of
   course accept the mail, only to find that the final host still
   refuses we happen to receive that piece of have an legitimate mail ("MAIL From"). I.e. our intent
   was user with an existing
       legitimate account and this user sends out spam, we may want
       to make the offending mail stay at reduce the offending sender's host speed with which he sends it out. This is not
       without controversy and fill up his mqueue disk, must be used with extreme care, but it all ended up at our friend,
       may protect the
   next lowest preference MX-host.

3. sendmail example

   The main purpose rest of the memo is to define Internet from him.

   2)  If we are under a set of requirements that
   will spam attack it may help reduce spam. It is not intended to describe how us considerably just
       being able to do that slow down the incoming mail rate for any that
       particular MTA. However, many of us use and are familiar with
   sendmail [2] and therefore we provide some hints; these require late



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 7]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 1997


   versions of sendmail-8.8.* (when user/host.

   For sending mail, this was written, 12 Nov 1997,
   sendmail-8.8.8 was the latest). The example neither makes a claim has to
   solve be done by throttling the problem nor TCP
   connection to be correct and you use it at your own risk.

   These examples all set the acceptable output data rate, e.g. reduce the
   "write()" frequency.

   For receiving mail, we could use basically the same technique, e.g.
   reduce the "read()" frequency, or we could signal with a 4xx Return
   Code "451", Temp Fail. Please read that
   section above once more and verify that you will not hit your
   friends, your next lowest preference MX-hosts, we cannot receive. It is RECOMMENDED that may have
   different rules.

   (NB sendmail makes the decision to
   take such action be based on "MAIL From" user, "MAIL From" domain,
   "SMTP Caller" (name/address) or a difference between <tab> combination of all these.

2.8. Verify "MAIL From"

   The MTA SHOULD be able to perform a simple "sanity check" of the
   "MAIL From" domain and <space> used as
   separators; refuse to receive mail if you use cut-and-paste from that domain is
   nonexistent. To overcome temporary errors/problems in the DNS, 4xx
   Return Codes are strongly recommended; however the MTA MAY allow for
   Return Codes that show real DNS state - 4xx for temporary problems
   and 5xx for NonExistent domain.

   In all honesty, please note that this memo you requirement and ability is a
   mixed blessing and should be used with extreme care.

   For early versions of spam spam software it does provide quite some
   relief, since that software generates mail with completely bogus
   "MAIL From" that will never even get into the system.

   On the other hand, sites with weak DNS connectivity may find their
   legitimate mail having problems reaching destinations due to DNS
   timeouts. However, since DNS information is handled asynchronously
   and is cached even though the initial requester has given up, chances
   are high that the necessary information is there at a later attempt.

   For later versions of spam software, a check of "MAIL From" is much
   less likely to get <space> everywhere).

   ##################################################################
   # Deny spammers, single users help, since that software evolves too and will start
   using existing mail addresses (whether or entire domains
   Kspammers       dbm -o  /etc/mail/spammers.db
   #
   Scheck_mail
   # check for valid domain name (name exists within DNS)
   R$*                     $: $>3 $1
   ifdef(`_NO_CANONIFY_', `
   # pass to name server to make hostname canonical
   # (done here if we have "nocanonify", in S3-S96 otherwise)
   R$* < @ $* $~P > $*     $: $1 < @ $[ $2 $3 $] > $4
   ')
   R$* < @ $*domain.com .> $: $1<@$2domain.com>            sigh
   R$* < @ $+ . >          $: <$1@$2>                      OK
   R$* < @ $+ >            $#error $: 451 Domain must resolve
   #
   #R$*                    $@ OK        return not that is legal is beyond
   the scope of this memo). But, at least the Internet will benefit from here if you
   #                                    have no spammers check
   ###
   # check user@dom.ain and dom.ain versus spammers database
   R<$* @ $+>              $: $1<@$2>                      re-focus
   # user@dom.ain
   R$* < @ $+ >            $: $1<@$2><$(spammers $1@$2 $:OK $)>
   R$* < @ $+ ><OK>        $: $1<@$2>
   R$* < @ $+ ><$* @ $+>   $#error $: 451 Denied due to spam-list
   # dom.ain
   R$* < @ $+ >            $: $1<@$2><$(spammers    $2 $:OK $)>
   R$* < @ $+ ><OK>        $: $1<@$2>
   R$* < @ $+ ><$+>        $#error $: 451 Denied due to spam-list
   # You may consider more tests here, e.g. verify/check against
   #    $(dequote "" $&{client_name} $)
   #    $(dequote "" $&{client_addr} $)
   R$*                     $@ OK
   ##################################################################



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 8]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 9]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   ##################################################################
   # In "class D" you enter domains and hosts for two purposes
   #   1) You accept to relay


   the side effect that this test stops typos and misconfigured UAs.

2.9. Verify <local-part>

   The MTA SHOULD allow outgoing mail TO them (MX).
   #   2) You accept to relay mail FROM them (SmartHost).
   # In both cases, this have its <local-part> verified
   so that the sender name is "recursive", i.e. foo.se -> *.foo.se
   #FD/etc/mail/sendmail.cD
   CD
   #
   # In "class B" you enter  the "exceptionally bad guys", i.e. hosts
   # that you want a real user or an existing alias. This is
   basically to deny relay protect the rest of the Internet from regardless - various "typos"
       MAIL From <fo0bar@domain.example>
   and/or malicious users
       MAIL From <I.am.unknown.to.you.he.he@domain.example>

   As always this may can be hosts
   # that overcome by spammers really wanting to do not have so,
   but with more strict rules for relaying it becomes harder and harder.
   In fact, catching "typos" at the initial (and official) mail relay is
   in itself enough filters motivation for this requirement.

2.10. Return Codes

   The MTA MUST be configurable to use different Return Codes for
   different rules (e.g. 451 Temporary Failure vs 551 Fatal Error).
   Please refer to the previous section on SMTP Return Codes.

3. Future work

3.1. Impact on SMTP UAs

   Despite this memo is about MTAs and the requirements put on them,
   some of what is done here falls back to the UAs (User Agents, the
   "ordinary mail programs").

   A UA does two things:

   1)  Reads mail from a mailbox and prints on the screen.
       This typically uses a protocol like POP, IMAP or any other reason. Be careful.
   # FB/etc/mail/sendmail.cB
   CB
   #
   Scheck_rcpt
   # first get rid NFS.

   2)  Reads text from the keyboard and hands that over to the
       mailbox MTA for delivery as a piece of a%b@c type addresses
   R< $+ % $+ >            < $1 @ $2 >
   R< $+ @ $+ @ $+ >       < $1 @ $2 >
   # "RCPT To" mail. This typically
       uses the SMTP protocol, i.e. the same protocol that terminates locally is OK
   R< $+ @ $=w >           $@ OK
   R< $+ @ $=w . >         $@ OK
   R<$->                   $@ OK
   # "RCPT To" for accepted domains is OK
   R< $+ @ $=D >           $@ OK
   R< $+ @ $=D . >         $@ OK
   R< $+ @ $+ . $=D >      $@ OK
   R< $+ @ $+ . $=D . >    $@ OK
   # used
       between MTAs.

   When MTAs now start to implement various anti-relay filters as
   described above, a UA on a portable laptop host may get sender host's name
   R$*                     $: $(dequote "" $&{client_name} $)
   # if it's me it's OK
   R$=w                    $@ OK
   R$@                     $@ OK
   # exceptionally bad guys...
   R$=B                    $#error $:"451 Relaying Denied, " $1
   # do this a response
   like "Relaying Denied" just because it happens to use IP addresses
   within the wrong range or "name". This could be resolved by some
   other mail-sending protocol between the US and the MTA.

   Or, we could note that when the SMTP Authentication work is all in case you want "bad with recursion"
   #R$+$=B                 $#error $:"451 Relaying Denied, " $1$2
   #
   place it will allow for Authenticated SMTP to serve as the protocol



Lindberg et.al.  Anti-Spam Requirements on an accepted host SMTP MTA         [Page 10]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   between the UAs and the home MTA (whether that should be considered a
   new protocol or "the same old SMTP" is OK (with "recursion")
   R$=D                    $@ OK
   R$+$=D                  $@ OK
   # irrelevant).

   This adds one item to the suggested Relay algorithm:

   +   If "SMTP Authenticated" then accept to Relay.

3.2. Personal anti-spam filters

   Since all users are individuals, there is little hope that any
   central anti-spam action will suit them all - in fact one could argue
   about Freedom of Speech if some central set of anti-spam rules is
   enforced without the users' approval (one could of course also argue
   whether spam really adds anything else to anyone, but that must be up to
   each individual user rather than centrally decided).

   Therefore the only reasonable extension is bogus
   R$*                     $#error $:"451 Relaying Denied, " $1
   ##################################################################

4. Security Considerations

   This memo does not consider security to allow for personal
   anti-spam filters, i.e. anti-spam filters like the ones described
   earlier in its this memo, but available and configurable on a per user
   basis. Since most general form, taken
   literally, users will not have a strong opinion (except that
   they want to avoid spam) the mail system should provide a system
   default and give each user the ability to override or modify that.
   In a UNIX based environment one could think of

       /etc/mail/rc.spam
       ~/.spamrc

   and rules on how the latter can interfere with the former.

   All of this opens up quite a number of unresolved issues, e.g.
   whether each user himself really should be allowed to decide on SMTP
   Return Codes (and how it should be described so he understands enough
   of the implications) and how existing mail systems will deal with
   different per user responses, especially how they will deal with a
   mix of 5xx and 4xx codes:

       C  MAIL From: <usr@spam.example>
       S  250 <usr@spam.example>... Sender ok
       C  RCTP To: <usr@domain.example>
       S  250 <usr@domain.example>... Recipient ok
       C  RCTP To: <foo@domain.example>
       S  451 <foo@domain.example>... Denied due to spam list
       C  RCTP To: <bar@domain.example>
       S  551 <bar@domain.example>... Denied due to spam list

   Of course one could decide on either "250 OK" or "551 Denied" with no
   other alternatives for the individual user, but this too has to be
   explained enough that an ordinary user understands the implications



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA         [Page 11]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away
   with, or block out, mail he actually wanted.

3.3. SMTP Authentication

   SMTP Authentication has already been mentioned as a method to
   authorize Mail relaying, but of course there is much more to it certainly does so than
   that. When that infrastructure and functionality is all in place,
   spammers will have a broader much harder time forging addresses and more general
   sense - protecting Internet users from mass mail abuse does have some



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA          [Page 9]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 1997


   security implications.

5. Acknowledgements

   This memo hiding.


3.4. ESMTP ContentType

   A lot of the problem with spam is actually that it is so completely
   "blind", without any relation to the result of discussions in an ad hoc group receivers' personal interest and
   that there are no easy way to say No Thank You.

   One way things could evolve is that spam is taken care of Swedish
   ISPs by legal
   means, e.g. making it illegal to send unsolicited commercial email
   and Universities. Without hope make that happen world wide. Not very likely, but anyway.

   Another way would be to mention everyone accept that spam/UCE will continue to exist,
   accept it legally (just like we simply
   give accept the domain names for pile of paper mail that
   clutters up the ISPs here: algonet.se, global-ip.net,
   pi.se, swip.net, telia.net and udac.se; paper mail mailbox) but require it be tagged as UCE.
   This would then go along the Universities stay
   anonymous.

6. References

   [1] Jonathan B. Postel "Simple Mail Transfer Protocol; RFC821",
       August 1982. Available via anonymous ftp at
       ftp://ds.internic.net/rfc/rfc821.txt

   [2] sendmail Home Page.      http://www.sendmail.org

   *   Spam (R) is a registered trademark lines of a meat product made by
       Hormel. Use personal anti-spam filters
   (~/.spamrc) where each user could define what kind of the term Spam in the Internet community comes
       from a Monty Python sketch and is almost Internet folklore.
       The term Spam is usually meant negative, however this UCE he is not
       in any way intended
   willing to describe the Hormel product.

7. Addendum - Future work

7.1. Impact on SMTP UAs

   Despite accept and then have an "ESMTP ContentType" code that
   could match his areas of interest, e.g:

       S  220 host.domain.example Ready
       C  HELO host.uce.example
       S  250 host.domain.example Hello host.uce.example
       C  ESMTP ContentType: UCE; money, porno
       S  250 ContentType accepted
       C  MAIL From: <uce@uce.example>
       S  250 <uce@uce.example>... Sender ok
       C  RCPT To: <foo@domain.example>
       S  250 <foo@domain.example>... Recipient ok
       C  RCPT To: <bar@domain.example>
       S  551 <bar@domain.example>... No thanks, not for me

   Besides all issues of entering more functionality into ESMTP, a major
   drawback with this memo idea is about MTA:s and the requirements put on them,
   some of what is done here falls back to do with people claimimg

       ESMTP ContentType: mail; personal

   although it is really spam/UCE. This is a non technical issue that
   must be resolved, although that may be hard or even impossible.



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA         [Page 12]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


4. Security Considerations

   The grassfire-like increase of spam raises several security issues
   which, in fact, puts the UA:s (User Agents, the
   "ordinary entire Internet mail programs").

   An UA does two things:

   1)  Reads community at risk:

   o   People may fail to find important mail from a in their flooded
       mailboxes. Or, they may delete it while cleaning up.

   o   ISPs get mailbox hosts overloaded and prints on the screen.
       This typically uses disk filled. Cleaning
       up and helping customers, require a protocol like POP, IMAP lot of human resources.

   o   While disks are unaccessible, either due to being filled or NFS.

   2)  Reads text from
       due to "mail quota", important mail may be delayed or lost.
       Normally this would not happen without notice, but if both
       the keyboard sender and hands that over to receiver hosts have their disk flooded, the
       mailbox MTA for delivery
       mail being returned may also fail, i.e. the email service may
       become even less trustworthy then before.

   o   Hosts used as unauthorized Mail Relays get overloaded. Besides
       the technical implications, this too requires a piece lot of mail. This typically
       uses the SMTP protocol, i.e. the same protocol human
       resources, cleaning up mail queues and taking care of furious
       external users that were spammed through the Relay.

   o   The fight against spammers include blocking their hosts (which
       is used
       between MTA:s.

   When MTA:s now start to implement various anti-relay filters as described above, a UA on in this memo). However, there is a portable laptop host great risk
       that Mail Relay hosts be blocked too, despite they are also
       victims. In the long run, this may get responses
   like "Relaying Denied" just because it happens to deteriorate Internet mail.

   o   The common use IP of forged "MAIL From" and "From:" addresses
   within
       puts the wrong range or "name". To overcome this, one should use
   some other protocol to transport blame on innocent persons/hosts/organizations. This
       is bad for reputation and may affect business relations.

5. Acknowledgements

   This memo is the piece result of mail from the UA discussions in an ad hoc group of Swedish
   ISPs and Universities. Without hope to mention everyone we simply
   give the
   (Relay) MTA. domain names here: algonet.se, global-ip.net, pi.se,
   swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and
   uu.se.

   We want to acknowledge valuable input and suggestions from Andras
   Salamon, John Myers, Bob Flandrena, Dave Presotto and Dave Kristol.









Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA         [Page 10]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 13]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   This would do away with


6. References

   [1] Jonathan B. Postel "Simple Mail Transfer Protocol; RFC821",
       August 1982.
       Available via anonymous ftp at
       ftp://ds.internic.net/rfc/rfc821.txt

   [2] David H. Crocker "Standard for the need format of ARPA Internet
       text messages; RFC822", August 1982.
       Available via anonymous ftp at
       ftp://ds.internic.net/rfc/rfc822.txt

   [3] R.T. Braden "Requirements for SMTP between everybody Internet hosts - application
       and will
   allow more strict authentication between SMTP MTA:s.

7.2. Anti-spam filters

   Today, when an MTA with support; RFC1123", Oct-01-1989.
       Available via anonymous ftp at
       ftp://ds.internic.net/rfc/rfc1123.txt

   [4] S. Bradner "Key words for use in RFCs to Indicate Requirement
       Level; RFC2119", March 1997.
       Available via anonymous ftp at
       ftp://ds.internic.net/rfc/rfc2119.txt

   [5] sendmail Home Page.
       http://www.sendmail.org

   *   spam filter receives (R) is a message it has two
   possibilities, reject or accept the message. The mechanism used registered trademark of a meat product made by
   sendmail and other MTA software is to check
       Hormel. Use of the term spam in a policy filter list
   whether the sender, recipient Internet community comes
       from a Monty Python sketch and sending host is accepted. If the
   message almost Internet folklore.
       The term spam is not destined for a local user, a policy filter usually meant negative, however this is checked not
       in any way intended to see whether we relay for the sending host, whether we accept describe the
   sender Hormel product.

Editor's Address

   Gunnar Lindberg
   Computer Communications Group
   Chalmers University of the message and whether we accept the recipient Technology
   S-412 96 Gothenburg, SWEDEN,
   Phone +46 31 772 5913
   FAX   +46 31 772 5922
   lindberg@cdg.chalmers.se

Appendix A1. sendmail example

   The main purpose of the
   message. If the message memo is destined for to define a local user, we do the same
   thing.

   This way, we actually filter messages set of requirements that
   will help reduce spam. It is routed through us. We
   also apply the same policy filter, not only intended to non-local users but describe how to
   all local users as well.

   Users probably have different opinions about what addresses should be
   in the policy filter list, a central filter will be considered by
   some as a nuisance that should be removed. In this view it is not
   unlikely do that the system administrator, who is responsible
   for the
   maintenance any particular MTA. However, many of the policy filter list, will hesitate to add addresses
   to the list us use and thus give continued access to the spammers to abuse
   the MTA. Less blunt tools than central filtering should be used to
   fight spam.

7.2.1. Personal anti-spam filters

   If users could design their own policy filter, for what should be
   delivered to their mailboxes, the system manager is less likely seen
   as a despotic censor. If this concept is accepted, much more freedom
   is given when designing the filter are familiar with
   sendmail [5] and therefore we provide some hints; these require late
   versions of sendmail-8.8.* (when this was written, 16 Dec 1997,



Lindberg et.al.  Anti-Spam Requirements on what principles it should
   be built. Some users may want an SMTP MTA         [Page 14]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   sendmail-8.8.8 was the latest). The example neither makes a narrow filter while others want wide.
   With personal filters it will be up claim to
   solve the user problem nor to decide how the
   filter should function. The three parameters that can be used for
   designing a filter should be addresses correct and you use it at your own risk.

   These examples all use Return Code "451", Temp Fail. Please read that should be rejected,
   addresses
   section above once more and verify that should be accepted you will not hit your
   friends, your next lowest preference MX-hosts, that may have
   different rules.

   (NB sendmail makes a difference between <tab> and an indication <space> used as
   separators; if you use cut-and-paste from this memo you are likely
   to accept or
   reject by default.

   It could function like today, a list with addresses get <space> everywhere).

   ##################################################################
   # Deny spammers, single users or entire domains that
   is rejected, default is
   Kspammers       dbm -o  /etc/mail/spammers.db
   #
   Scheck_mail
   # check for valid domain name (name exists within DNS)
   R<$* .>                 $: <$1>      Drop fake trailing '.'
   R$* .                   $:  $1       Drop fake trailing '.'
   R$*                     $: $>3 $1
   ifdef(`_NO_CANONIFY_', `
   # pass to accept. It could function the opposite
   way, a list with addresses or domains that is accepted, default is name server to
   reject.

   In all cases some sort of interface make hostname canonical
   # (done here if we have "nocanonify", in S3-S96 otherwise)
   R$* < @ $* $~P > $*     $: $1 < @ $[ $2 $3 $] > $4
   ')
   R$* < @ $*domain.com .> $: $1<@$2domain.com>            sigh
   R$* < @ $+ . >          $: <$1@$2>                      OK
   R$* < @ $+ >            $#error $: 451 Domain must be developed, resolve
   #
   #R$*                    $@ OK        return from here if you
   #                                    have no spammers check
   ###
   # check user@dom.ain and dom.ain versus spammers database
   R<$* @ $+>              $: $1<@$2>                      re-focus
   # user@dom.ain
   R$* < @ $+ >            $: $1<@$2><$(spammers $1@$2 $:OK $)>
   R$* < @ $+ ><OK>        $: $1<@$2>
   R$* < @ $+ ><$* @ $+>   $#error $: 451 Denied due to make the
   user able spam-list
   # dom.ain
   R$* < @ $+ >            $: $1<@$2><$(spammers    $2 $:OK $)>
   R$* < @ $+ ><OK>        $: $1<@$2>
   R$* < @ $+ ><$+>        $#error $: 451 Denied due to configure their personal policy filter. It spam-list
   # You may not be consider more tests here, e.g. verify/check against
   #    $(dequote "" $&{client_name} $)
   #    $(dequote "" $&{client_addr} $)
   R$*                     $@ OK
   ##################################################################



Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA         [Page 11]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 15]

draft-lindberg-anti-spam-mta-01.txt                          16 Dec 1997


   very different from how the owner of a listserv list manages the
   list, all configuration performed by email, or it could be done by
   using a web browser.

   If default is to reject messages, a mechanism for senders to request
   to be members of the accept list needs to be developed. One thought
   is to create a user-request address that will, when sent to, give the
   user a hint to add the sender to the accept list.

   Some redesigning of the MTA is necessary for this type of filtering
   to be possible. It would then need to hear out the RCPT TO before
   checking the policy filter of the recipient and deciding whether to
   accept or reject


   In the message. However, this is not a very complicated
   function to implement. Sendmail already checks if users have .forward
   files in their home directories, checking example below we use "CD" ("$=D") dual purpose, both for a policy filter list
   would not be much more trouble.

   This kind of personal spam filter could be implemented today, as it
   does not require global implementation to function. It will benefit
   the users who does not have to accept spam, as well as the system
   administrator who does not need to take the responsibility of
   deciding what to accept or not. The challenge is to design the user
   interface in such a way that users understand how they should operate
   the filter.

7.2.2. Anti-spam filters return codes

   One open question here is Return Codes - should the receiving MTA
   indicate to the sending MTA that this mail was not delivered due
   domains (subdomains) we accept to
   some personal anti-spam filter or should it silently drop it?  Should
   it return 4xx or 5xx - relay into and should that be up to the user?

   First hosts that we
   accept use us as their Mail Relay. It is of all, it would be both rude course trivial to split
   that into two different classes, if needed.

   ##################################################################
   # In "class D" you enter domains and unfair hosts for two purposes
   #   1) You accept to drop relay mail without
   any indication, so there has to be 4xx or 5xx. Since an ordinary user
   will never be able to forsee, or understand, the interactions between
   several MX hosts Return Code "551 - Denied due TO them (MX).
   #   2) You accept to spam list" is
   recommended.

7.3. Mandatory signing of messages

   Today, the Internet relay mail FROM them (SmartHost).
   # In both cases, this is quickly becoming the groupware of "recursive", i.e. foo.se -> *.foo.se
   #FD/etc/mail/sendmail.cD
   CD
   #
   # In "class B" you enter  the masses.
   It could be argued "exceptionally bad guys", i.e. hosts
   # that what characterizes the Internet, in
   opposition you want to a traditional groupware system, is deny relay from regardless - this may be hosts
   # that on the Internet
   users are in practice anonymous. One do not have enough filters or any other reason. Be careful.
   # FB/etc/mail/sendmail.cB
   CB
   #
   Scheck_rcpt
   # first get rid of the main problems with
   spamming is a%b@c type addresses
   R< $+ % $+ >            < $1 @ $2 >
   R< $+ @ $+ @ $+ >       < $1 @ $2 >
   # "RCPT To" that the terminates locally is OK
   R< $+ @ $=w >           $@ OK
   R< $+ @ $=w . >         $@ OK
   R<$->                   $@ OK
   # "RCPT To" for accepted domains is OK
   R< $+ @ $=D >           $@ OK
   R< $+ @ $=D . >         $@ OK
   R< $+ @ $+ . $=D >      $@ OK
   R< $+ @ $+ . $=D . >    $@ OK
   # get sender almost always tries to achieve anonymity,
   and using todays standard technology they have no problems doing
   that.




Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA         [Page 12]

draft-lindberg-anti-spam-mta-00.txt                          12 Nov 1997


   Spammers should not be given a chance to hide, they should be forced
   to reveal their identity. With their identities in public, measures
   can be taken to make them stop sending spam or to not accept email
   from them.

   This can be achieved host's name
   R$*                     $: $(dequote "" $&{client_name} $)
   # if signing of messages it's me it's OK
   R$=w                    $@ OK
   R$@                     $@ OK
   # exceptionally bad guys...
   R$=B                    $#error $:"451 Relaying Denied, " $1
   # do this in case you want "bad with recursion"
   #R$+$=B                 $#error $:"451 Relaying Denied, " $1$2
   # an electronic
   signature should become mandatory. It would make spamming impossible,
   or at least futile. As a side effect, assigning certificates to
   Internet users would benefit the authentication procedures for other
   Internet services.

   It is important that this transition accepted host is made as smooth as possible,
   methods to handle the intermediate stage must be developed.

   There OK (with "recursion")
   R$=D                    $@ OK
   R$+$=D                  $@ OK
   # anything else is much work going on in creating the standards necessary to
   make this possible and effective.

   The MTA should be given a chance to check the signature, using ESMTP,
   and reject the message if incorrect, see draft-myers-smtp-auth-XX and
   draft-myers-auth-sasl-XX.

   Public keys and certificates needs to be signed and distributed
   across the Internet, see RFC2065.

   Everything should be knitted together and organized, see draft-
   eastlake-muse-XX.

Editor's Address

   Gunnar Lindberg
   Computer Communications Group
   Chalmers University of Technology
   S-412 96 Gothenburg, SWEDEN,
   Phone +46 31 772 5913
   FAX   +46 31 772 5922
   lindberg@cdg.chalmers.se bogus
   R$*                     $#error $:"451 Relaying Denied, " $1
   ##################################################################




Lindberg et.al.  Anti-Spam Requirements on an SMTP MTA         [Page 13] 16]

--- please cut here too ----------------------------------------------

----