WDIFF

draft-lindberg-anti-spam-mta-02.txt --> draft-lindberg-anti-spam-mta-03.txt

INTERNET-DRAFT Gunnar Lindberg
draft-lindberg-anti-spam-mta-02.txt
draft-lindberg-anti-spam-mta-03.txt Chalmers University
Expires July, October, 1998 of Technology
6 Feb
23 Apr 1998

Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs

Abstract

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

The intent is that these requirements 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
requirements
recommendations were included, and used, on all Internet SMTP MTAs,
things would improve considerably and give time to design a more long
term solution. Some ideas are presented in the 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 (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Lindberg et.al. Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs [Page 1]

draft-lindberg-anti-spam-mta-02.txt 6 Feb

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

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 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 Several Most of the senders of spam are anything but serious, e.g dishonest, e.g. hide behind
false addresses 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 requested" when you never asked for it, and
generally do everything they can without regard to honesty or mail hosts that refuse

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 2]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

ethics, to receive. try to get a few more people to look at their
message".

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 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.

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
theft of service is almost certainly illegal in most - if not all countries, but - countries
(at least in the US, spammers have been successfully sued).
However, 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-02.txt 6 Feb 1998 the list of receivers back in the US US, the
legal aspects become
almost overhelming. process of getting damages from the spammers becomes
extremely difficult

1.2. Scope

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

If, however, enough Internet 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. Terminology

Throughout this memo we will use the terminology

But, please note:

The Non-Relay rules are not in themselves enough to stop spam.
Even of 99% of RFC2119, [4]:

o "MUST"

This word or the adjective "REQUIRED" means SMTP MTAs implemented them from day 1,
spammers would still find the remaining 1% and use them. Or,
spammers would just switch gear and connect directly to each
and every recipient host; that will be to a higher cost for
the item spammer, but is
an absolute requirement.

o "SHOULD"

This word or still quite likely.

Despite IPv6 deployment may be near in time, the spam problem is here
already and thus this memo restricts itself to the current IPv4.

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 3]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

1.3. Terminology

Throughout this memo we will use the 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.

1.4. Using DNS information

In the memo we sometimes use the term "host name" or "domain name"
which should be interpreted as a Fully Qualified Domain Name, FQDN.
By this we mean the name returned from the DNS in response to a PTR
query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a
name, or we mean a name with a DNS A or MX record associated to it.

When we suggest use of host or domain names, FQN, FQDNs rather than IP addresses. This addresses this is because FQN
FQDNs are intuitively much easier to use.

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 3]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 However, all such usage
depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it
is fairly easy to forge that, either by false cache information
injected in DNS servers or spammers running their own DNS, DNS with false
information in them, host and domain names must be used with care,
e.g. verify verified so that the translation address->name corresponds to
name->address.

1.5. SMTP Return Codes

Our basic assumption is that refuse/accept With Secure DNS, RFC2065, [5], things will improve,
since spoofing of .IN-ADDR.ARPA will no longer be possible.

One of the recommendations is handled at about verifying "MAIL From:" domains
with the SMTP
layer and that an MTA DNS (assure that decides to refuse a message should do so
while still in appropriate DNS information exisists for
the SMTP dialogue. First, this means that we do not
have to store a copy domain). When making use of this capability there are a message we later decide few
things to refuse and
second, our responsibility for that message is low or none - since we
have not yet read it we leave consider:

For early versions of spam software it to the sender to handle the error. does provide quite some

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 4]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

relief, since that software generates mail with completely bogus
"MAIL From:" that will never get into the system if verified with
the DNS. This is in active use at many installations today and it
does reduce spam.

On the other hand, sites with weak DNS connectivity may find their
legitimate mail having problems reaching destinations due to DNS
timeouts when the receivers verify their "MAIL From:". 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 help, since spam software evolves too and will start
using existing mail addresses (whether or not that is legal is beyond
the scope of this memo). But, at least the Internet will benefit from
the side effect that this test stops typos and misconfigured UAs.

1.5. Where to block spam, in SMTP, in RFC822 or in the UA

Our basic assumption is that refuse/accept is handled at the SMTP
layer and that an MTA that decides to refuse a message should do so
while still in the SMTP dialogue. First, this means that we do not
have to store a copy of a message we later decide to refuse and
second, our responsibility for that message is low or none - since we
have not yet read it in, we leave it to the sender to handle the
error.

1.6. SMTP Return Codes

SMTP has several classes of Return Codes, see [1] for a discussion:

o 5xx
is a Fatal Error Permanent Negative Completion reply (Fatal Error) and
results in the mail transfer being terminated and the mail
returned to sender. For some

o 4xx
is a Transient Negative Completion reply (Temporary Error) and
results in the mail transfer being put back on queue again and
a new attempt being made later.

o 2xx
is a Positive Completion reply and indicates that the MTA now
has taken responsibility for the delivery of the mail.

When making use of the options/"knobs" described in this memo there
are a few things to consider:

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 5]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

For some events, like "Denied - you're on the spammer's list", this is
probably 5xx
may be the correct response and Return Code, since it terminates the right thing to say.

A session at
once and we are done with it. However, a mistake in configuration, however, configuration may
cause valid legitimate mail to
bounce back to the sender, bounce, which may be quite unfortunate.

Therefore, we suggest 4xx as the Return Code for most cases. Since
that is a Temporary Error and results in non fatal error, the mail transfer being
put back on queue again gets re-queued at the sender and a new attempt being made later.
Therefore, configuration mistakes are much less fatal
we have at least some time to discover and you
may correct them before any real damage configuration
errors, rather than have mail bounce (typically this is done. when we
refuse to Relay for domains that we actually should accept since we
are on their MX list).

A 4xx response also makes the spammer's host re-queue the mail and if
it really is his own host who gets to do this, it is probably a good thing.
thing - fill up his disks with his own spam. If, on the other hand,
he is using someone else as Relay Host, all the spam mail being
queued is a fairly strong evidence that something illegal bad is going on and
should cause attention at the that Relay Host.

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

However, 4xx Temporary Errors may have unexpected interaction with
MX-records. If the receiving domain has several MX records and the
lowest preference MX-host refuses to receive mail from a certain
"MAIL From" domain with a "451"
Response Code, the sending host may choose to - and 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-02.txt 6 Feb 1998

If that next 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 to receive that piece of mail ("MAIL From"). From:"). I.e. our intent
was to make the offending mail stay at the offending sender's host
and fill up his mqueue disk, but it all ended up at our friend, the
next lowest preference MX-host.

2. Requirements

Here we first give a brief list of requirements, followed by a

Finally, it has been suggested that one may use a 2xx Return Code but
nevertheless decide not to forward or receive the spam mail; typical
alternatives are to store it elsewhere (e.g. /dev/null). This clearly
violates the intent of RFC821 and should not be done without careful
consideration - instead of blindly dropping the mail one could re-
queue it and manually (or automagically) inspect whether it is spam
or legitimate mail and whether it should be dropped or forwarded.

1.7. Mailing Lists

An MTA that also has the ability to handle mailing lists and expand
that to a number of recipients, needs to be able to authorize senders
and protect its lists from spam. The mechanisms for this may be very
different from those for ordinary mail and ordinary users and are not
covered in this memo.

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 6]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

2. Recommendations

Here we first give a brief list of recommendations, followed by a
more thorough discussion of each of them. We will also give
recommendations on things NOT to do, things that may seem natural in
the spam fight (and might even work so far) but that might wreak
havoc on Internet mail and thus may cause more damage than good.

1) MUST be able to restrict unauthorized use as Mail Relay.

2) MUST be able to provide "Received:" lines with enough
information to make it possible to trace the mail path, despite
spammers use forged host names in HELO statements etc.

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

4) SHOULD be able to log all occurrences of anti-relay/anti-spam
actions.

5) MUST NOT refuse "MAIL To: <Postmaster@my.local.dom.ain>".

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

6a)

7a) MUST NOT refuse "MAIL From: <>".

7b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".

8a) SHOULD be able to refuse mail from a specific "MAIL From" From:"
user, <foo@domain.example>.

6b)

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

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

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

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

10)

12) SHOULD be able to control SMTP VRFY and EXPN.

13) SHOULD be able to control SMTP ETRN.

14) MUST be able to configure for to provide different Return Codes
for different rules (e.g. 451 Temp Fail vs 551 550 Fatal Error).

11) SHOULD be able to authorize mailing list usage.

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 7]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

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 data/template for doing so may be supplied
outside of the MTA, e.g. that the pattern matching rules be included
in the MTA but that the actual patterns may be in an external file.

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 5]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998
It is also RECOMMENDED that the pattern matching rules (external
file) may contain regular expressions, to give maximum flexibility.

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 same user and since the
string compares are used to refuse his messages, we suggest that
<local-part> be compared non case sensitive too.

2.1. Restricting unauthorized Mail Relay usage

Unauthorized usage of a host as Mail Relay means theft of the relay's
resources and puts the owner's reputation at risk. It also makes it
impossible to filter out or block spam without at the same time
blocking legitimate mail.

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

In an SMTP session we have 3 4 elements, with a varying degree of
trust:

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

Since 1) is so and 2) are so easily and often forged, we cannot depend on that
them at all to authorize usage of our host as Mail Relay.

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

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

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 8]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

The suggested algorithm is:

a) If "RCPT To" To:" is one of "our" domains, local or a domain that
we accept to forward to (alternate MX), then accept to Relay.

b) If "SMTP Caller" SMTP_Caller is authorized, either its IP.src or its FQN FQDN
(depending on if you trust the DNS), then accept to Relay.

c) Else refuse to Relay.

When doing a) you have to make sure all kinds of SMTP source routing
(both the official [@a,@b:u@c] and [@a,@b:u@c], the '%' hack) hack and uucp-style '!' path)
is either removed

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 6]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998 completely before the test, or is at least not
taken into account.

In all cases the configuration MUST support wild cards for FQNs FQDNs and
classful IP addresses and SHOULD support "address/mask" for classless
IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*,
192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.

The configuration SHOULD allow for the decision/template data to be
supplied by an external source, e.g. text file or dbm database. The
decision/template SHOULD be allowed to contain regular expressions.

2.2. Received: lines

The MTA MUST prepend a "Received:" line in the mail (as described in
RFC822, [2], and required in RFC1123, [3]). This "Received:" line
MUST contain enough information to make it possible to trace the mail
path back to the sender. We have two cases:

2.2.1. Direct MTA-to-MTA connections

Internet mail was designed such that the sending host connects
directly to the recipient as described by MX records (there may be
several MX hosts on a priority list). To assure traceability back to
the sending host (which may be a firewall/gateway, as described
later) each MTA along the path, including the final MTA, MUST prepend
a "Received:" line.

Such For such a "Received:" line we have:

It MUST contain:

o The IP address of the caller.

o The 'date-time' as described in RFC822, [2], pp 18.

It SHOULD contain:

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 9]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

o The FQN FQDN corresponding to the callers IP address.

o The argument given in the "HELO" statement.

It is suggested that most other "Received:" fields described in
RFC822 be included in the "Received:" lines.

These requirements recommendations are deliberately stronger than RFC1123, [3],
and are there to assure that mail sent directly from a spammer's host
to a recipient can be traced with enough accuracy; a typical example
is when a spammer uses a dialup account and the ISP needs to have his
IP address at the 'date-time' to be able to take action against him.

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 7]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

2.2.2. Firewall/gateway type devices

Organizations with a policy to hide their internal network structure
must still be allowed and able to do so. They usually make their
internal MTAs prepend "Received:" lines with a very limited amount of
information, or prepend none at all. They then Then they send out the mail
through some kind of firewall/gateway device, which may even remove
all the internal MTAs' "Received:" lines before it prepends its own
"Received:" line (as required in RFC1123, [3]).

By doing so they take on the full responsibility to trace spammers
that send from inside their organization. organization or they accept to be held
responsible for those spammers' activities. It is REQUIRED that the
information provided in their outgoing mail is sufficient for them to
perform such necessary traces.

2.3. Event logs

The MTA MUST be able to provide enough local log information to make
it possible to trace the event. This includes most of the information
put into the "Received:" lines, see above.

2.4. Log anti-relay/anti-spam actions

The MTA SHOULD be able to 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" To:" addresses (domains).

o Offending host's IP address.

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 10]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

o Offending host's FQN FQDN hostname.

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

2.5.

2.5 "MAIL To: <Postmaster@my.local.dom.ain>"

The MTA MUST NOT refuse "MAIL To: <Postmaster@my.local.dom.ain>".

By "my.local.dom.ain" we mean the domain name(s) that are treated as
local and result in local delivery.

This is regardles of any other anti-spam actions that have been
taken, specified in this memo or elsewhere, and is to assure that it
is at least possible to reach the Postmaster (RFC822, [2]) on a
possibly misconfigured system and have him/her correct the error.

2.6. Refuse mail based on SMTP Caller SMTP_Caller address

The MTA SHOULD be able to accept or refuse mail from a specific host
or from a group of hosts. Here we mean the IP.src address or the FQN FQDN
that 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 recommend it here.

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 8]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

It is RECOMMENDED that the MTA decide based on FQN FQDN 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

The list is searched until first match and the accept/refuse action
is based on that.

IP-address/length is RECOMMENDED. However, implementations with 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 MTA MAY provide complete regular
expressions to be used for hostnames; possibly also for IP addresses.

2.6. Refuse based on

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 11]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

2.7 "MAIL From: <>" and "MAIL From" From: <user@my.local.dom.ain>"

Although the fight against spammers is important it must never be
done in way that violates existing email standards.

The MTA SHOULD be able to MUST NOT refuse to receive mail from a specific "MAIL From" user (foo@domain.example) or From: <>".

That sender address is used in error messages from an entire "MAIL From"
domain (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 certain user or mail system
itself, e.g. when a certain domain legitimate mail relay is quite helpful
while an attack has just been discovered used and is ongoing.

2.7. Rate Control

The MTA SHOULD provide tools for forwards an
error back to the user. Refusing to receive such mail host means that
users may not be notified of errors, e.g. "User unknown", which will
no doubt wreak more havoc to control the rate
with which mail is sent or received. community than spam does.

The idea is twofold:

1) If MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".

By "my.local.dom.ain" we happen to have an legitimate mail user with an existing
legitimate account mean the domain name(s) that are treated as
local and this user sends out spam, we result in local delivery. At first thought it may want seem like
noone else will need to reduce the speed with which he sends it out. This is not
without controversy say "MAIL From: <user@my.local.dom.ain>" and must be used with extreme care, but it
that restrictions on who may protect say that would reduce the rest risk of fraud
and thus reduce spam. While this may be true in the Internet from him.

2) If we are under a spam attack (very) short
term, it may help us considerably just
being able also does away with at least two legitimate usages:

o Aliases (.forward files).
<user1@my.local.dom.ain> sends to slow down the incoming mail rate for <user2@external.example> and
that
particular user/host.

For sending mail, this has mail gets forwarded back to be done by throttling the TCP
connection <user2@my.local.dom.ain>, e.g.
since <user2> has moved to set my.local.dom.ain and has a .forward
file.

o Mailing lists.
RFC1123, [3], gives a clear requirement that "MAIL From:" for
mail from a mailing list should reflect the acceptable output data rate, e.g. reduce owner of the
"write()" frequency.

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 9]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

For receiving mail, we could use basically list,
rather then the same technique, e.g.
reduce the "read()" frequency, or we could signal with a 4xx Return
Code individual sender. However, not all lists are
that well maintained (not even all IETF lists) and thus we cannot receive. It is RECOMMENDED that the decision will
have to
take such action be based on "MAIL From" user, fall back to the principle of "Be strict in what you
send and liberal in what you receive".

If "MAIL From" domain,
"SMTP Caller" (name/address) or From: <user1@my.local.dom.ain>" is rejected, both these
cases will result in failure to deliver a combination of all these. legitimate mail.

2.8. Verify Refuse based on "MAIL From" From:"

The MTA SHOULD be able to perform a simple "sanity check" of the
"MAIL From" domain and refuse to receive mail if that from a specific
"MAIL From:" user (foo@domain.example) or from an entire "MAIL From:"
domain is
nonexistent. To (domain.example). In general this kind of rules are easily
overcome temporary errors/problems in by the DNS, 4xx
Return Codes are strongly recommended; however spammers changing "MAIL From:" every so often, but
the MTA MAY allow for
Return Codes that show real DNS state - 4xx for temporary problems ability to block a certain user or a certain domain is quite
helpful while an attack has just been discovered and 5xx is ongoing.

Lindberg et.al. Anti-Spam Recommendations for NonExistent domain.

In all honesty, please SMTP MTAs [Page 12]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

Please note that this requirement and ability is a
mixed blessing

"MAIL From: <>"
and should
"MAIL From: <user@my.local.dom.ain>"

MUST NOT be used with extreme care.

For early versions of spam spam software it does refused (see above).

2.9. Rate Control

The MTA SHOULD provide quite some
relief, since that software generates mail with completely bogus
"MAIL From" that will never even get into tools for the system.

On mail host to control the other hand, sites rate
with weak DNS connectivity may find their
legitimate which 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 help, since that software evolves too and will start
using existing mail addresses (whether sent or not that is legal is beyond
the scope of this memo). But, at least the Internet will benefit from
the side effect that this test stops typos and misconfigured UAs.

2.9. Verify <local-part> received. The MTA SHOULD allow outgoing mail idea is twofold:

1) If we happen to have its <local-part> verified
so that the sender name is a real an legitimate mail user or with an existing alias.
legitimate account and this user sends out spam, we may want
to reduce the speed with which he sends it out. This is
basically to not
without controversy and must be used with extreme care, but it
may protect the rest of the Internet from 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 can be overcome by spammers really wanting to do so,
but with more strict rules for relaying him.

2) If we are under a spam attack it becomes harder and harder.
In fact, catching "typos" at may help us considerably just
being able to slow down the initial (and official) incoming mail relay is
in itself enough motivation rate for that
particular user/host.

For sending mail, this requirement.

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 10]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

2.10. Return Codes

The MTA MUST has to be configurable done by throttling the TCP
connection to set the acceptable output data rate, e.g. reduce the
"write()" frequency.

For receiving mail, we could use different Return Codes for
different rules (e.g. 451 Temporary Failure vs 551 Fatal Error).
Please refer to basically the previous section on SMTP same technique, e.g.
reduce the "read()" frequency, or we could signal with a 4xx Return Codes.

2.11. Mailing Lists

An MTA
Code that also has the ability to handle mailing lists and expand we cannot receive. It is RECOMMENDED that the decision to
take such action be based on "MAIL From:" user, "MAIL From:" domain,
SMTP_Caller (name/address) or a number combination of recipients, all these.

2.10. Verify "MAIL From:"

The MTA SHOULD be able to authorize senders.
Despite perform a simple "sanity check" of the
"MAIL From" is very easy From:" domain and refuse to forge we have no alternative, so
authorization will have receive mail if that domain is
nonexistent (i.e. does not resolve to be based on "MAIL From".

The following options are suggested:

o Allow all members in the list.

o Allow all members and having an MX or an additional list of senders.

Violations could be handled in different ways (combinations of):

o A "5xx" record).
If the DNS error code and information in is temporary, TempFail, the MTA MUST return a log file.

o Forwarding 4xx
Return Code (Temporary Error). If the violating mail to DNS error is an Authoritative
NXdomain (host/domain unknown) the list owner.

o Forwarding MTA SHOULD still return a 4xx
Return Code (since this may just be primary and secondary DNS not
being in sync) but it MAY allow for an 5xx Return Code (as configured
by the violating sysadmin).

2.11. Verify <local-part>

The MTA SHOULD allow outgoing mail to some other address.

3. Future work

3.1. Impact on have its <local-part> verified

Lindberg et.al. Anti-Spam Recommendations for SMTP UAs and end users

Despite this memo is about MTAs and [Page 13]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

so that the requirements put on them,
some of what sender name is done here falls back a real user or an existing alias. This is
basically to protect the UAs (User Agents, rest of the
"ordinary mail programs").

A UA does two things:

1) Reads mail Internet from a mailbox 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 can be overcome by spammers really wanting to do so,
but with more strict rules for relaying it becomes harder and prints on harder.
In fact, catching "typos" at the screen.
This typically uses initial (and official) mail relay is
in itself enough motivation for this recommendation.

2.12. SMTP VRFY and EXPN

Both SMTP VRFY and EXPN provide means for a protocol like POP, IMAP or NFS.

2) Reads text from potential spammer to test
whether the keyboard addresses on his list are valid (VRFY) and hands that over even get more
addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed
to issue these commands. This may be "on/off" or it may use access
lists similar to those mentioned previously. Default for both should
be "off".

2.13. SMTP ETRN

SMTP ETRN means that the
mailbox MTA will re-run its mail queue, which may be
quite costly and open for delivery as a piece Denial of mail. This typically
uses the SMTP protocol, i.e. Service attacks. Therefore, the same protocol that
MTA SHOULD control who is used
between MTAs.

When MTAs now start is allowed to implement various anti-relay filters as
described above, a UA on a portable laptop host issue the ETRN command. This
may get a response
like "Relaying Denied" just because be "on/off" or it happens to may use IP addresses

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 11]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

within an unknown range or that resolve access lists similar to unknown FQNs. those mentioned
previously. Default should be "off".

2.14. Return Codes

The typical victim of this "Relaying Denied" response primary issue here is flexibility - it is simply not possible to
define in a salesman
carrying a laptop on a business trip, or even an IETF delegate document how to make tradeoffs between returning 5xx and
make legitimate mail fail at once due to a
meeting hotel. The salesman will probably dial his nearest ISP configuration mistake and
will get an IP address from that dialup pool; the IETF delegate will
use an IP address for the terminal room. In both cases their laptop
mail program (the UA; e.g. pine, Netscape, Eudora) will try
returning 4xx and be able to send
out mail catch such configuration mistakes via their home MTA, e.g. SMTP-SERVER=mail.home.example, but
unless mail.home.example has been updated to accept that (temporary)
IP address it will respond "Relaying Denied" and refuse.

To get around this problem we could simply add
log file inspection.

Therefore, the terminal room's MTA MUST be configurable to provide different Return
Codes, 5xx / 4xx / 2xx, for different rules or policies

However, when the dialup pool's IP network to response is the list of accepted networks at
mail.home.example. This does open up some minimal risk result of spammers
using that host as their Mail Relay: If they use the same ISP's
dialup pool a DNS lookup and they configure to use mail.home.example at the same
time as our salesman is on his trip, then DNS
system returned TempFail, a temporary error, the spammers will be
authorized to relay their spam through mail.home.example. However, MTA MUST reflect
this is not extremely likely and as long as we do not open up for the
entire world all provide a 4xx return code. If the time and we keep DNS response is an
Authoritative NXdomain (host or domain unknown) the log files under close
observation and we stop relaying at once we find we're being used, MTA MAY reflect
this solution is probably good enough.

Antoher way around is that our salesman uses a Mail Relay provided by
the current dialup ISP, if that service exists. To do so he has to
modify SMTP-SERVER= in his UA, which may or may not be reasonable.

The correct way a 5xx Return Code.

Please refer to handle the previous section on SMTP Return Codes.

Lindberg et.al. Anti-Spam Recommendations for SMTP MTAs [Page 14]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

3. Future work

3.1. Impact on SMTP UAs and end users

Despite this situation, though, memo is by about MTAs and recommendations for them, some other
mail-sending protocol between 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 MTA. Although not
officially standardized, one such screen.
This typically uses a protocol is like POP, IMAP or NFS.

2) Reads text from the "XTND XMIT"
extensions to POP3 [6].

Or, we could note keyboard and hands that when over to the SMTP Authentication work is all in
place, it will allow
mailbox MTA for Authenticated SMTP to serve delivery as The Protocol
between a piece of mail. This typically
uses the UAs and SMTP protocol, i.e. the home MTA (whether that should be considered a
new protocol or "the same old SMTP" protocol that is irrelevant here).

This adds one item to the suggested Relay algorithm:

+ If "SMTP Authenticated" then accept used
between MTAs.

When MTAs now start to Relay.

3.2. Personal anti-spam implement various anti-relay 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

Lindberg et.al. Anti-Spam Requirements as
described above, a UA on an SMTP MTA [Page 12]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

whether spam really adds anything a portable laptop host may get a response
like "Relaying Denied" just because it happens to anyone, but use IP addresses
within an unknown range or that must be up to
each individual user rather than centrally decided).

Therefore the only reasonable extension is resolve to allow for personal
anti-spam filters, i.e. anti-spam filters like the ones described
earlier in unknown FQDNs.

The typical victim of this memo, but available and configurable on "Relaying Denied" response is a per user
basis. Since most users will not have salesman
carrying a strong opinion (except that
they want to avoid spam) the mail system should provide laptop on a system
default and give each user the ability to override business trip, or modify that.
In even an IETF delegate at a UNIX based environment one could think of

/etc/mail/rc.spam
~/.spamrc
meeting hotel. The salesman will probably dial his nearest ISP and rules on how
will get an IP address from that dialup pool; the latter can interfere with IETF delegate will
use an IP address for the former.

All of this opens up quite a number of unresolved issues, terminal room. In both cases their laptop
mail program (the UA; e.g.
whether each user himself really should be allowed pine, Netscape, Eudora) will try to decide on SMTP
Return Codes (and how it should be described so he understands enough
of the implications) and how existing send
out mail systems will deal with
different per user responses, especially how they via their home MTA, e.g. SMTP-SERVER=mail.home.example, but
unless mail.home.example has been updated to accept that (temporary)
IP address it will deal with a
mix of 5xx respond "Relaying Denied" 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 refuse.

To get around this problem we could decide on either "250 OK" simply add the terminal room's or "551 Denied" with no
other alternatives for
the individual user, but this too has dialup pool's IP network to be
explained enough that an ordinary user understands the implications list of "Refuse 'MAIL From: <.*@spam.example>'" and accepted networks at
mail.home.example. This does open up some minimal risk of spammers
using that it can do away
with, or block out, mail he actually wanted.

3.3. SMTP Authentication

SMTP Authentication has already been mentioned host as a method to
authorize their Mail relaying, but of course there is much more to it than
that. When that infrastructure Relay: If they use the same ISP's
dialup pool and functionality is all in place,
spammers will have a much harder they configure to use mail.home.example at the same
time forging addresses as our salesman is on his trip, then the spammers will be
authorized to relay their spam through mail.home.example. However,
this is not extremely likely and hiding. as long as we do not open up for the
entire world all the time and we keep the log files under close
observation and we stop relaying at once we find we're being used,
this solution is probably good enough.

Another way around is that our salesman uses a Mail Relay provided by
the current dialup ISP, if that service exists. To do so he has to
modify SMTP-SERVER= in his UA, which may or may not be reasonable.

Lindberg et.al. Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs [Page 13]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 15]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

3.4. SMTP ContentType

A lot of the problem with spam is actually that it is so completely
"blind", without any relation

The correct way to handle this situation, though, is by some other
mail-sending protocol between the receivers' personal interest UA and
that there the MTA. Although not
officially standardized, one such protocol is no easy way the "XTND XMIT"
extensions to say No Thank You.

One way things POP3 [7].

Or, we could evolve is note that spam when the SMTP Authentication work is taken care of by legal
means, e.g. making all in
place, it illegal will allow for Authenticated SMTP to send unsolicited commercial email serve as The Protocol
between the UAs and make the home MTA (whether that happen world wide. Not very likely, but anyway.

Another way would should be to accept that spam/UCE will continue to exist,
accept it legally (just like we accept the pile of paper mail that
clutters up the paper mail mailbox) but require it be tagged as UCE. considered a
new protocol or "the same old SMTP" is irrelevant here).

This would then go along adds one item to the lines of personal suggested Relay algorithm:

+ If "SMTP Authenticated" then accept to Relay.

3.2. Personal anti-spam filters
(~/.spamrc) where each user could define what kind of UCE he

Since all users are individuals, there is
willing to accept and then have an "SMTP ContentType" code little hope that any
central anti-spam action will suit them all - in fact one could
match his areas argue
about Freedom 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 SMTP 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 Speech if some central set of entering more functionality into SMTP, a major
problem with this idea is how to handle people claiming

SMTP ContentType: mail; personal

although it anti-spam rules is
enforced without the users' approval (one could of course also argue
whether spam really spam/UCE. This is a non technical issue adds anything to anyone, but that must be resolved, although that may be hard or even impossible.

4. Security Considerations

The grassfire-like increase of spam raises several security issues
which, in fact, puts the entire Internet mail community at risk:

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

o ISPs get mailbox hosts overloaded
each individual user rather than centrally decided).

Therefore the only reasonable extension is to allow for personal
anti-spam filters, i.e. anti-spam filters like the ones described
earlier in this memo, but available and disk filled. Cleaning configurable on a per user
basis. Since most 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 helping customers requires how existing mail systems will deal with
different per user responses, especially how they will deal with a lot
mix of human resources. 5xx and 4xx codes:

C MAIL From: <usr@spam.example>
S 250 <usr@spam.example>... Sender ok
C RCPT To: <usr@domain.example>
S 250 <usr@domain.example>... Recipient ok
C RCPT To: <foo@domain.example>

Lindberg et.al. Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs [Page 14]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 16]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

o While disks are unaccessible, either

S 451 <foo@domain.example>... Denied due to being filled or spam list
C RCPT To: <bar@domain.example>
S 550 <bar@domain.example>... Denied due to "mail quota", important mail may be delayed spam list

Of course one could decide on either "250 OK" or lost.
Normally this would not happen without notice, but if both
the sender and receiver hosts have their disk flooded, the
mail being returned may also fail, i.e. the email service may
become less trustworthy then before.

o Hosts used as unauthorized Mail Relays get overloaded. Besides "550 Denied" with no
other alternatives for the technical implications, individual user, but this too requires a lot has to be
explained enough that an ordinary user understands the implications
of human
resources, cleaning up mail queues "Refuse 'MAIL From: <.*@spam.example>'" and taking care of furious
external users that were spammed through the Relay.

o The fight against spammers include blocking their hosts (which
is described in this memo). However, there is it can do away
with, or block out, mail he actually wanted.

3.3. SMTP Authentication

SMTP Authentication has already been mentioned as a great risk
that method to
authorize Mail Relay hosts be blocked too, despite they are also
victims. In the long run, this may deteriorate Internet mail.

o The common use relaying, but of forged "MAIL From" and "From:" addresses
puts the blame on innocent persons/hosts/organizations. This course there is bad for reputation much more to it than
that. When that infrastructure and may affect business relations.

5. Acknowledgements

This memo functionality is the result of discussions all in an ad hoc group of Swedish
ISPs place,
spammers will have a much harder time forging addresses and Universities. Without hope hiding.

3.4. SMTP Type

A lot of the problem with spam is actually that it is so completely
"blind", without any relation to mention everyone we simply
give the domain names here: algonet.se, global-ip.net, pi.se,
swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, receivers' personal interest and
uu.se.

We want
that there is no easy way to acknowledge valuable input and suggestions from Andras
Salamon, John Myers, Bob Flandrena, Dave Presotto say No Thank You.

One way things could evolve is that spam is taken care of by legal
means, e.g. making it illegal to send unsolicited commercial email
and Dave Kristol.

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 make that happen world wide. Not very likely, but anyway.

Another way would be to accept that spam/UCE will continue to exist,
accept it legally (just like we accept the format pile 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 Internet hosts - application paper mail that
clutters up the paper mail mailbox) but require it be tagged as UCE.
This would then go along the lines of personal anti-spam filters
(~/.spamrc) where each user could define what kind of UCE he is
willing to accept and support; RFC1123", Oct-01-1989.
Available via anonymous ftp at
ftp://ds.internic.net/rfc/rfc1123.txt then have an "SMTP Type" code that could match
his areas of interest. This also goes quite well with the various
rules and regulations used by international Telemarketing. The SMTP
dialogue would then be:

S 220 host.domain.example Ready
C HELO host.uce.example
S 250 host.domain.example Hello host.uce.example
C SMTP Type: UCE; money, porno
S 250 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 550 <bar@domain.example>... No thanks, not for me

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 15]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

[4] S. Bradner "Key words Recommendations for use in RFCs to Indicate Requirement
Level; RFC2119", March 1997.
Available via anonymous ftp SMTP MTAs [Page 17]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

Having the test at
ftp://ds.internic.net/rfc/rfc2119.txt

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

[6] POP3 extensions
http://musicm.mcgill.ca/~MSI/HTTP/pop3xtndxmit.html

* spam (R) is a registered trademark of the SMTP layer means we may not need to receive a meat product made by
Hormel. Use
copy of the term spam mail in question - if all potential receivers say "550"
the Internet community comes
from a Monty Python sketch and SMTP session is almost Internet folklore.
The term spam terminated without data copy.

This requires adding more functionality to (E)SMTP, which is usually meant negative, however this IETF
controlled. It also need some legal support to handle the case

SMTP Type: mail; personal

although it is not really spam/UCE. This can be done on a legal basis
(which is hard in any way intended to describe the Hormel product.

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

Appendix A1. sendmail example

The main purpose international context) or it can be put into
the ISPs contract with its customers, just like most ISPs today have
contracts against customers sending spam.

3.5. Spam and NATs

With the increased use of NATs, Network Address Translators, may come
a need for additional information in log files. As long as there is
an 1:1 mapping between the memo addresses inside the NAT and the addresses
used outside it everything is OK, but if the NAT box also translates
port numbers (to combine many internal hosts into one external
address) we will need to define a set log not only the IP addresses of requirements that spam hosts
but also the port numbers. Otherwise we will help reduce spam. It is not intended to describe how be able to do that
for any particular MTA. However, many identify
the individual host inside the NAT.

4. Security Considerations

The grassfire-like increase of us use spam raises several security issues
which, in fact, puts the entire Internet mail community at risk:

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

o ISPs get mailbox hosts overloaded and are familiar with
sendmail [5] disk filled. Cleaning
up and therefore we provide some hints; these require late
versions of sendmail-8.8.* (when this was written, 6 Feb 1998,
sendmail-8.8.8 was the latest). The example neither makes helping customers requires a claim lot of human resources.
In fact, ISP mail servers have crashed by too much mail.

o While disks are unaccessible, either due to
solve the problem nor being filled or
due to "mail quota", important mail may be correct delayed or lost.
Normally this would not happen without notice, but if both
the sender and you use it at your own risk.

These examples all use Return Code "451", Temp Fail. Please read that
section above once more receiver hosts have their disk flooded, the
mail being returned may also fail, i.e. the email service may
become less trustworthy then before.

o Hosts used as unauthorized Mail Relays get overloaded. Besides
the technical implications, this too requires a lot of human
resources, cleaning up mail queues and verify that you will not hit your
friends, your next lowest preference MX-hosts, taking care of furious
external users that may have
different rules. were spammed through the Relay.

Lindberg et.al. Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs [Page 16]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 18]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

(NB sendmail makes a difference between <tab> and <space> used as
separators; if you use cut-and-paste from

o The fight against spammers include blocking their hosts (which
is described in this memo you are likely
to get <space> everywhere).

##################################################################
# Deny spammers, single users or entire domains
Kspammers dbm -o /etc/mail/spammers.db
#
###
# In "class S" you enter memo). However, there is a great risk
that Mail Relay hosts you consider to be spammers, either
# FQN (if you trust the DNS) or IP addresses (better). Since FQN
# and IP addresses do not look blocked too, despite they are also
victims. In the same, we keep them both here.
# We long run, this may deteriorate Internet mail.

o The common use simple pattern matching of forged "MAIL From:" and thus IP "From:" addresses only match
#
puts the blame on byte boundaries, i.e. /24 prefixes.
#
# If you want to make innocent persons/hosts/organizations. This
is bad for reputation and may affect business relations.

5. Acknowledgements

This memo is the test "recursive" result of discussions in an ad hoc group of Swedish
ISPs and Universities. Without hope to do so you just
# remove the comments at mention everyone we simply
give the "Rec" lines below.
#
# FS/etc/mail/sendmail.cS
CS
#
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 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 from here if you
# have no spammers check
###
# check user@dom.ain names here: algonet.se, global-ip.net, pi.se,
swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, 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
uu.se.

We want to spam-list
# dom.ain
R$* < @ $+ > $: $1<@$2><$(spammers $2 $:OK $)>
R$* < @ $+ ><OK> $: $1<@$2>
R$* < @ $+ ><$+> $#error $: 451 Denied due acknowledge valuable input and suggestions from Andras
Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol,
Donald Eastlake, Ned Freed, Keith Moore and Paul Hoffman.

Finally many thanks to spam-list

Lindberg et.al. Anti-Spam Requirements on an SMTP MTA [Page 17]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 1998

###
# get sender's host name
R$* $: $(dequote "" $&{client_name} $)
R$=S $@ $#error $: 451 Denied $1
#R$+.$=S $@ $#error $: 451 Denied $1.$2 Rec
###
# get sender's IP address
R$* $: $(dequote "" $&{client_addr} $)
R$=S $#error $: 451 Denied $1
#R$=S.$- $#error $: 451 Denied $1.$2 Rec
#R$=S.$-.$- $#error $: 451 Denied $1.$2.$3 Rec
#R$=S.$-.$-.$- $#error $: 451 Denied $1.$2.$3.$4 Rec
###
R$* $@ OK
################################################################## Harald Alvestrand for support and guidance
through the IETF process.

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 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 Internet hosts - application
and 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

Lindberg et.al. Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs [Page 18]

draft-lindberg-anti-spam-mta-02.txt 6 Feb 19]

draft-lindberg-anti-spam-mta-03.txt 23 Apr 1998

[5] D. Eastlake, 3rd, C. Kaufman "Domain Name System Security
Extensions; RFC2065", January 1997.
Available via anonymous ftp at
ftp://ds.internic.net/rfc/rfc2065.txt

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

[7] POP3 extensions
http://musicm.mcgill.ca/~MSI/HTTP/pop3xtndxmit.html

* spam (R) is a registered trademark of a meat product made by
Hormel. Use of the example below we use "CD" ("$=D") dual purpose, both for term spam in the
domains (subdomains) we accept to relay into Internet community comes
from a Monty Python sketch and the hosts that we
accept use us as their Mail Relay. It is of course trivial to split
that into two different classes, if needed.

##################################################################
# In "class D" you enter domains and hosts for two purposes
# 1) You accept to relay mail TO them (MX).
# 2) You accept to relay mail FROM them (SmartHost).
# In both cases, this almost Internet folklore.
The term spam 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 to deny relay from regardless - usually meant negative, however this may be hosts
# that do is not have enough filters or
in any other reason. Be careful.
# FB/etc/mail/sendmail.cB
CB
#
Scheck_rcpt
# first get rid way intended to describe the Hormel product.

Editor's Address

Gunnar Lindberg
Computer Communications Group
Chalmers University of a%b@c type addresses
R< $+ % $+ > < $1 @ $2 >
R< $+ @ $+ @ $+ > < $1 @ $2 >
# "RCPT To" 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
# 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 in case you want "bad with recursion"
#R$+$=B $#error $:"451 Relaying Denied, " $1$2
# an accepted host is OK (with "recursion")
R$=D $@ OK
R$+$=D $@ OK
# anything else is bogus
R$* $#error $:"451 Relaying Denied, " $1
################################################################## Technology
S-412 96 Gothenburg, SWEDEN,
Phone +46 31 772 5913
FAX +46 31 772 5922
lindberg@cdg.chalmers.se

Lindberg et.al. Anti-Spam Requirements on an Recommendations for SMTP MTA MTAs [Page 19] 20]

----