<?xml version='1.0'?>

<reference anchor='RFC2505'>

<front>
<title abbrev='Anti-Spam Recommendations'>Anti-Spam Recommendations for SMTP MTAs</title>
<author initials='G.' surname='Lindberg' fullname='Gunnar Lindberg'>
<organization>Chalmers University of Technology, Computer Communications Group</organization>
<address>
<postal>
<street />
<city>Gothenburg</city>
<code>SE-412 96</code>
<country>SE</country></postal>
<phone>+46 31 7725913</phone>
<email>lindberg@cdg.chalmers.se</email></address></author>
<date month='February' year='1999' />
<abstract>
<t>This memo gives a number of implementation recommendations for SMTP,, MTAs (Mail Transfer Agents, e.g.sendmail) to make them more capable of reducing the impact of spam(*).</t>
<t>The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.</t>
<t>The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.</t>
<t>A brief summary of this memo is:
<list style='symbols'>
<t>Stop unauthorized mail relaying.</t>
<t>Spammers then have to operate in the open; deal with them.</t>
<t>Design a mail system that can handle spam.</t></list></t></abstract></front>

<seriesInfo name='BCP' value='30' />
<seriesInfo name='RFC' value='2505' />
</reference>
