You are here: Home > Publications > RIPE Document Store > Good Practice For Combating Unsolicited Bulk Email

Changes to Good Practice For Combating Unsolicited Bulk Email

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted
ripe-206: The provisions of this BCP ripe-409: This document are to be applied to all customers. However, some customers will have customers of their own. The ISP will conform to Best Practice by ensuring that such customers adopt this BCP themselves, and thereby apply Best Practice procedures in turn to their own customers. outlines best practices for minimising email abuse.

delete: <a name="toc"> delete: </a> Table of Contents

delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc01"> insert: <p>

insert: <a href="#0"> 0. Introduction insert: <br />
delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc1"> insert: <a href="#1"> 1. No email relaying insert: <br />
delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc11"> Discussion delete: </a> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc12"> Requirements delete: </a> delete: </li> delete: </ul> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc2"> insert: <a href="#2"> 2. Traceability of email delete: </a> passing through the system delete: <ul> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc21"> Discussion insert: <br />
delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc22"> Requirements delete: </a> delete: </li> delete: </ul> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc3"> insert: <a href="#3"> 3. Identification of the sender of email insert: <br />
of email delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc31"> Discussion delete: </a> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc32"> Requirements delete: </a> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc33"> Exception delete: </a> delete: </li> delete: </ul> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc4"> insert: <a href="#4"> 4. Handle abuse reports delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc41"> Discussion delete: </a> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc42"> Requirements delete: </a> delete: </li> delete: </ul> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc5"> insert: <br />
insert: <a href="#5"> 5. Act upon reports of abuse insert: <br />
of abuse delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc51"> Discussion insert: <span class="top"> insert: <a href="#6"> 6. Deny use of UBE for promotion delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc52"> Requirements insert: <br />
insert: <a href="#7"> 7. Prohibit the distribution of UBE tools and address lists by customers insert: <br />
delete: </li> delete: </ul> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc6"> 6. insert: </span>
insert: <a href="#8"> 8. Disseminate information delete: </a> on action taken delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc61"> Discussion against customers insert: <br />
delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc62"> Requirements delete: </a> delete: </li> delete: </ul> delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc7"> 7. insert: <a href="#9"> 9. Education delete: <ul compact="compact"> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc71"> Discussion insert: </p>

insert: <h2>

Appendices insert: </h2>

insert: <p>

A: insert: <a href="#a"> Glossary insert: <br />
delete: </li> delete: <li> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc72"> Requirements B: insert: <a href="#B"> References and Resources insert: <br />
delete: </li> delete: </ul> delete: </li> delete: <li> Appendix A: delete: <a href="http://www.ripe.net/ripe/docs/spam.html#tocA"> Glossary delete: </a> delete: </li> delete: <li> Appendix B: delete: <a href="http://www.ripe.net/ripe/docs/spam.html#tocB"> References delete: </a> and Resources delete: </li> delete: <li> Appendix C: delete: <a href="http://www.ripe.net/ripe/docs/spam.html#tocC"> insert: <a href="#c"> Specimen Clauses insert: <br />
delete: </li> delete: <li> Appendix D: delete: <a href="http://www.ripe.net/ripe/docs/spam.html#tocD"> Key Words insert: <a href="#d"> Definition of Normative Terms in Requirements delete: </li> delete: </ul> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: </p>

insert: <hr size="1" />
insert: <h2>

insert: <a id="0" name="0"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: </p> delete: <hr /> delete: <h2> delete: <a name="toc01"> delete: </a> 0. Introduction

Unsolicited Bulk Email insert: <b> U insert: </b> nsolicited insert: <b> B insert: </b> ulk insert: <b> E insert: </b> mail (UBE) is a widespread problem on the Internet. It is sometimes called "junk email" or "spam". Because of the volumes involved and the indiscriminate nature of its sending, there can be few email users who do not have first hand experience of receiving UBE, often in significant quantity.

delete: <p> insert: <h3>

The sending of UBE is considered to be unacceptable behaviour because: delete: </p> insert: </h3>

  • it interferes with the operation of the Internet. delete: <blockquote> Internet insert: <ul>
      insert: <li>
    • There have been instances of systems collapsing from the sheer bulk of email that has been sent. Senders have arranged for delivery failures to be reported to third parties, causing significant problems to their operations. Besides these gross failures, UBE, by its presence alone, degrades email systems for everyone, delaying and blocking legitimate traffic. These effects can be seen far beyond the Internet, across all the systems that carry email. delete: </blockquote> insert: </li>
    • insert: </ul>
  • it creates unwanted traffic for the recipients. delete: <blockquote> recipients insert: <ul>
      insert: <li>
    • In most cases, users must pay for their connection, so they are funding the reception of something that was not wanted in the first place. delete: </blockquote> insert: </li>
    • insert: </ul>
  • it creates support overheads for ISPs. delete: <blockquote> ISPs insert: <ul>
      insert: <li>
    • ISPs must deal not only with the complaints from their own customers who have received unwanted email, e-mail, but also with the reports submitted by others, demanding precipitate action, when their own customers have sent the UBE. delete: </blockquote> UB
    delete: <p> Furthermore: insert: </li>
  • insert: </ul>
insert: <p>

insert: <b> Furthermore insert: </b>

  • In its commercial form UBE usually promotes goods of dubious provenance, legality or taste. taste
  • No reputable schemes for regulating UBE exist.
  • The individuals and companies sending UBE have shown no willingness to seriously co-operate with the Internet industry to reduce the impact of their activities. activities
  • The UBE is seldom sent to those who might appreciate it. It costs the sender next to nothing to send UBE. This removes any incentive to limit its distribution. There are real fears that UBE could grow without limit and clog up the Internet, and the mailboxes of every email e-mail user on the planet. planet

It is resource intensive and to a large extent ineffective for ISPs to try to block UBE once it has been sent, so this BCP does not describe the limited manner in which this may be attempted. In the fight against UBE the ISP's most practical contribution is to minimise or eliminate the sending (or other use) of UBE by its customers or from its systems. The purpose of this BCP is to describe the industry's current collective opinion of the Best Practice in achieving this.

Besides being in the general interest for ISPs to adopt Best Practice, many ISPs will wish to be publicly seen to be doing what they can to combat UBE. To that end, it is expected that ISPs will wish to state formally that they have adopted the recommendations of this BCP. To assist in this, the document has been written as a "standard", using the terms MUST, SHOULD, MAY and MUST NOT as defined in RFC 2119 (see insert: <a href="#d"> Appendix D insert: </a> for a summary of this).

delete: <p> insert: <h3>

For an ISP to be effective in combating UBE, Best Practice is as follows. delete: </p> follows: insert: </h3>

  1. The ISP MUST ensure that their email systems will not relay email e-mail for unauthorised third parties.
  2. The ISP MUST ensure that all email generated within their network can be traced to its source; and MUST ensure that the immediate source of email which arrives from other networks can be determined.
  3. The ISP MUST ensure that all email generated within their own networks can be attributed to a particular customer or system.
  4. The ISP MUST operate appropriate arrangements for the handling of reports of abuse by their customers. They MUST also ensure that IP allocation entries in Regional Registries such as RIPE NCC contain appropriate abuse team email addresses.
  5. Where abuse is proved, the ISP MUST take effective action to prevent the customer from sending further UBE. continuing that abuse. The legal basis on which services are provided to customers MUST allow such action to be taken.
  6. The ISP MUST treat use of UBE to promote secondary services as an abuse of the provision of that secondary service. insert: </li>
  7. insert: <li>
  8. The ISP MUST NOT permit customers to distribute tools, or lists of email addresses, whose purpose is the sending of UBE. insert: </li>
  9. insert: <li>
  10. The ISP SHOULD disseminate information on the action taken in regard to customers who have sent UBE.
  11. The ISP MUST educate their customers on the nature of UBE, and MUST ensure that their customers have been made aware that sending UBE will be treated as unacceptable behaviour. The ISP MUST inform their customers about any automated anti-spam mechanisms in operation, and MUST educate their customers about any potential harmful side-effects.
delete: <p> insert: <p class="style1">

insert: <span class="bottom"> These seven nine points are expanded below. insert: </span>

Along with the extended explanations, this BCP lists a number of conditions that ISPs MUST impose upon their customers. It will be necessary to ensure that the contract made between ISP and customer gives the ISP the legal right to make these impositions and to withdraw services when unacceptable behaviour occurs.

To ensure fair competition between ISPs, so that no marketing advantage can be gained by failing to spell out these obligations properly, the ISP MAY use the standard clauses set out in insert: <a href="#c"> Appendix C insert: </a> and MUST use these clauses or others which are at least as effective. The ISP MAY place these clauses into a more general Acceptable Use Policy (AUP) that covers other abuse issues.

The provisions of this BCP document are to be applied to all customers. However, some customers will have customers of their own. The ISP will conform to Best Practice by ensuring that such customers adopt this BCP themselves, and thereby apply Best Practice procedures in turn to their own customers.

insert: <a href="#a"> Appendix A insert: </a> provides a glossary of terms, but in particular, throughout this document the term "ISP" should be understood to apply not only to "top level" providers of Internet connectivity, but also to customers of such ISPs who are "recursively" applying the BCP to their own customers. Also, the term "customer" should be understood to apply not only where there is a formal contractual relationship, but also to other cases where someone may be a "user" of the ISP's facilities.

delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: <h2>

insert: <a id="1" name="1"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: </p> delete: <p> delete: </p> delete: <h2> delete: <a name="toc1"> delete: </a> 1. No e-mail relaying

delete: <ul> delete: <li> No email relaying delete: </li> delete: </ul> delete: <h3> delete: <a name="toc11"> delete: </a> insert: <h4>

Discussion delete: </h3> insert: </h4>

Historically, email e-mail systems using the SMTP protocol have been prepared to accept email from anyone and then deliver it to, or towards, its true destination. This willingness to "relay" made Internet email extremely robust, since minor configuration errors on one machine could be overcome by another machine with more accurate knowledge of how to deliver the email. Furthermore, the spirit of co-operation that pervades the Internet has meant that machine owners tended not to log, let alone block, such relaying.

With the advent of the Domain Name System (DNS) and far better connectivity for all machines, this need for relaying passed away long ago. However, the functionality continues to be provided within email programs.

Unfortunately, in recent times, the unscrupulous have been abusing the "relay" function by sending a single piece of email with a long list of destinations. This can cause someone else's system to generate multiple copies of the email e-mail for delivery to many different addresses. By "amplifying" email in this way, the sender of UBE is exploiting the resources of others to do most of the work of generating the UBE. Furthermore, it is possible for the sender to use a poorly configured system to hide the true source of the email or at least to ensure that the less skilled misidentify its source.

As it is no longer required and because it is open to abuse, it is now considered quite improper for systems to be configured in such a way that they will relay email e-mail for unauthorised people.

There are several ongoing projects on the wider Internet to identify systems that are still prepared to relay email. Typically, such systems are added to blocking lists that affect the propagation of email. e-mail. Even if one wished to run an "open relay" the time is approaching when few will be prepared to interwork with such a system.

It is common for ISPs to run "smarthosts", which provide SMTP email delivery for their customers, especially those on dialup dial up connections or local networks. This avoids the necessity for these customer machines to have fully fledged delivery systems of their own. This "smarthosting" is just a form of relaying, but is of course a completely acceptable practice, provided that the smarthost is configured to refuse to relay any email sent to it by unauthorised machines.

delete: <h3> delete: <a name="toc12"> delete: </a> insert: <h4>

Requirements delete: </h3> delete: <p> insert: </h4>

insert: <ul>
    insert: <li>
  • ISPs MUST configure their email systems to prevent unauthorised email relaying. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • ISPs SHOULD accept email for their own customers, and they MAY make explicit private arrangements to relay email e-mail for specific other systems. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • ISPs MUST prohibit their customers from running systems that will relay email for unauthorised people. If such a system is being run the ISP MUST take steps to remove it from the Internet until this behaviour is corrected. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • The ISP SHOULD arrange to regularly check that its customers, particularly those on permanent connections, are not running open email relays. Where this is inappropriate for security reasons, or where the connection is intermittent, the ISP SHOULD ensure that the customers are told how to make this check for themselves. The ISP MAY provide tools, probably on the web, to allow customers to make their own checks. delete: </p> delete: <p> insert: </li>
  • insert: </ul>
insert: <p>

insert: <a href="#B"> Appendix B insert: </a> contains pointers to technical information about how to ensure that email relaying does not occur. delete: </p> delete: <p> insert: <br />
insert: <a href="#c"> Appendix C insert: </a> contains specimen contractual clauses to allow these, and other, requirements to be implemented.

delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: <h2>

insert: <a id="2" name="2"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: </p> delete: <p> delete: </p> delete: <p> delete: </p> delete: <h2> delete: <a name="toc2"> delete: </a> delete: </h2> delete: <ul> delete: <li> 2. Traceability of email passing through the system delete: </li> delete: </ul> delete: <h3> delete: <a name="toc21"> delete: </a> insert: </h2>

insert: <h4>

Discussion delete: </h3> insert: </h4>

Tracing the source of email requires that all systems comply with the email standards and add a "Received" header line as the email passes through them. This serves to identify the machine that is adding the header and the machine from which the email arrived. In principle, the oldest such line indicates the source of the email. In practice, this is sometimes forged, and to trace the true sender it is necessary to work through the Received lines in time order until a discontinuity is found.

The senders of email will sometimes try to obscure the true origin of email by forging the name of the source machine in the "HELO" protocol command. This type of forgery is made easy to detect by ensuring that the Received line contains not only the name, but also the IP address of the sending system, since the latter cannot be disguised.

delete: <h3> delete: <a name="toc22"> delete: </a> insert: <h4>

Requirements delete: </h3> delete: <p> insert: </h4>

insert: <ul>
    insert: <li>
  • ISPs MUST ensure that a standards-compliant "Received" line is added to all email that passes through their systems. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • ISPs MUST ensure that the identity of the machine passing them the email is correctly recorded. The HELO announcement MUST NOT be treated as being valid and an IP address SHOULD be recorded. delete: </p> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: </li>
  • insert: </ul>
insert: <h2>

insert: <a id="3" name="3"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: <br /> delete: <br /> delete: </p> delete: <h2> delete: <a name="toc3"> delete: </a> 3. Identification of the sender of email

delete: <ul> delete: <li> Identification of the sender of email delete: </li> delete: </ul> delete: <h3> delete: <a name="toc31"> delete: </a> insert: <h4>

Discussion delete: </h3> insert: </h4>

Section 2 has the effect of ensuring that email can be traced back to an originating IP address.

With dialup dial up access, it is common to use "dynamic IP", so that the same address will be reused for other customers. ISDN connections take only a few seconds, so in principle the same IP address can almost immediately be in use by another person entirely.

However, the combination of IP address and time of connection will uniquely identify where the email e-mail came from. So an accurate time must be recorded into the email header Received line. The combination of this time with other access logs, held by the originating ISP, will serve to identify the sender.

The above description has only skimmed the surface of a complex topic. The LINX Best Current Practice document on "Traceability" (see insert: <a href="#B"> Appendix B) B insert: </a> ) can be consulted for further information and advice.

delete: <h3> delete: <a name="toc32"> delete: </a> insert: <h4>

Requirements delete: </h3> delete: <p> insert: </h4>

insert: <ul>
    insert: <li>
  • ISPs MUST ensure that they keep accurate time on their email systems. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • Dynamic IP addresses can be reused in very short order. ISPs SHOULD be using time stamps based on NTP, or an equivalent protocol that regularly checks the time against standard values and which can provide sub-second accuracy. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • ISPs MUST keep other logs for a reasonable period period, insert: <span class="changed"> subject to local Data Protection legislation, so that they can ensure as far as possible insert: </span> that they are able to translate a given dynamic IP address, in use at a given time, to a particular customer who can be held accountable for any abuse. delete: </p> delete: <h3> delete: <a name="toc33"> delete: </a> insert: </li>
  • insert: </ul>
insert: <h4>

Exception delete: </h3> insert: </h4>

An exception to sections (2) and (3) Sections 2 and 3 arises in the case of a system run to deliberately hide the source of email - often called an "anon server". "Anon servers" are used to preserve anonymity where, for example, someone seeks help from a group supporting victims of abuse or wishes to express political views in a country that may punish dissent.

delete: <p> insert: <ul>
    insert: <li>
  • ISPs or their customers MAY run anon servers where this is explicitly intended to be the function of the service being provided. They MUST NOT allow their standard service to provide anonymity by failing to comply with this BCP. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • However an anon server SHOULD NOT be capable of 'amplification' of email by expanding address lists and SHOULD have limiting mechanisms to ensure that the volume of email passing through the server cannot be unusually high without explicit system owner knowledge. delete: </p> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: </li>
  • insert: </ul>
insert: <h2>

insert: <a id="4" name="4"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: <br /> delete: <br /> delete: <br /> delete: </p> delete: <h2> delete: <a name="toc4"> delete: </a> delete: </h2> delete: <ul> delete: <li> 4. Handle abuse reports delete: </li> delete: </ul> delete: <h3> delete: <a name="toc41"> delete: </a> insert: </h2>

insert: <h4>

Discussion delete: </h3> delete: <p> insert: </h4>

insert: <p class="changed">

ISPs are required to accept and process any e-mailed reports of about abuse by their customers. own customers, whatever person or organisation may send the reports.

If a customer posts UBE then complaints are likely to be made to the ISP. These complaints have, have in the past, by convention, generally been sent to the "postmaster" mailbox. More recently it has become desirable to direct such email to a specialist "abuse" mailbox. This practice was first fully documented in RFC 2142. RFC2142. insert: </p>

insert: <p>

Some ISPs are developing specialised reporting systems that, for example, allow complaints to be entered into a form on a website. There are many advantages to such systems in that they ensure that reports are complete and they can boost productivity, allowing prompt and efficient handling of the reports. However, they have disadvantages in that they can only be used online and at present there are no standard conventions for their layout or their location. Therefore, although ISPs may wish to encourage their use and to develop other automated submission systems for third-party sites that collate reports from many people, it is not appropriate, at present, to see them as entirely replacing e-mail reports. insert: </p>

insert: <p>

It is often "obvious" which ISP is responsible for particular IP addresses and hence which "abuse" mailbox to use. However, in some cases it may be necessary to consult the appropriate Regional Registry (such as RIPE NCC) in order to determine IP address ownership. It has therefore become standard practice to document within registry entries the explicit abuse@isp -mail address to be used. It is important that complaints continue to be accepted at the "obvious" address even though the registry entry may indicate that another address is to be preferred. At present, registry entries can only record abuse mailbox details by means of comment fields, which inhibits automatic processing, but a formally specified system may be introduced in the future.

When a complaint is received, it is wise to promptly acknowledge it, perhaps merely with a standard message that describes the local policies and procedures.

It is desirable to run a "ticketing" system that allows incident reports to be tracked. This will assist in combining reports and in collating further correspondence that may arrive from the original complainant.

It is also desirable to reply to people who submit complaints to explain what action is eventually decided upon. Sometimes, especially when a large number of reports are being received, this is not very practical. The standard message described above can usefully explain that this may happen, and it may be possible to direct people to a web site website where any action taken by the ISP will be recorded (see section Section 6 below).

delete: <h3> delete: <a name="toc42"> delete: </a> insert: <p>

Requirements delete: </h3> delete: <p> The insert: </p>

insert: <ul>
    insert: <li>
  • Where ISPs have many customers whose domain names are structured in a hierarchy linked to the ISP name (as in the examples below) then the ISP MUST accept reports to an address of the form abuse@domain where domain is the domain used by its customers, or in the case where the customer's domain is a subdomain of a generic domain, the abuse address must work in the generic domain. delete: </p> delete: <p> domain insert: <br />
    insert: <br />
    insert: <ul>
      insert: <li>
    • i.e. where customers have addresses like: delete: </p> delete: <blockquote> like customer@isp.com delete: </blockquote> delete: <p> insert: <br />
      the abuse address to be supported is: delete: </p> delete: <blockquote> is abuse@isp.com delete: </blockquote> delete: <p> insert: <br />
      where customers have addresses like: delete: </p> delete: <blockquote> like email@customer.isp.com delete: </blockquote> delete: <p> insert: <br />
      the abuse address to be supported is: delete: </p> delete: <blockquote> is abuse@isp.com delete: </blockquote> delete: <p> insert: <br />
      insert: <br />
      insert: </li>
    • insert: </ul>
    insert: </li>
  • insert: <li>
  • Where ISPs have customers who use their own domain names, not immediately linkable to the ISP, then the ISP MUST still accept abuse reports sent to the ISP insert: <br />
    insert: <br />
    insert: <ul>
      insert: <li>
    • For example, where customers of isp.com use their own domains, such as customer@example.com insert: <br />
      the abuse address to be supported is abuse@isp.com insert: <br />
      insert: <br />
      insert: </li>
    • insert: </ul>
    insert: </li>
  • insert: <li>
  • The ISP MUST document the appropriate "abuse@" address within the Regional Registry information for each IP address block delegated to them insert: </li>
  • insert: <li>
  • If it wishes, the ISP MAY accept reports submitted to other abuse addresses as well (e.g. abuse@isp.net), but it MUST NOT require the report to be resubmitted to another address before acting upon it. delete: </p> delete: <p> it insert: </li>
  • insert: <li>
  • If it wishes, the ISP MAY accept reports submitted via other media such as web forms and MAY encourage this so as to improve the accuracy of reports and to improve productivity in dealing with reports, but an ISP MUST NOT refuse to accept reports by e-mail to the appropriate "abuse@" address insert: </li>
  • insert: <li>
  • The ISP SHOULD document the existence of these their "abuse@" addresses on the their corporate web site, website, and SHOULD indicate the type of information that is required to make an abuse report useful. delete: </p> delete: <p> useful insert: </li>
  • insert: <li>
  • The ISP MUST acknowledge the receipt of abuse reports and SHOULD use a ticketing system to allow tracking of such reports. delete: </p> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents reports insert: </li>
  • insert: </ul>
insert: <h2>

insert: <a id="5" name="5"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: </p> delete: <h2> delete: <a name="toc5"> delete: </a> delete: </h2> delete: <ul> delete: <li> 5. Act upon reports of abuse delete: </li> delete: </ul> delete: <h3> delete: <a name="toc51"> delete: </a> insert: </h2>

insert: <h4>

Discussion delete: </h3> insert: </h4>

There is no acceptable excuse for the sending of unsolicited bulk email.

Apart from people pleading ignorance of the unacceptable nature of UBE, which is covered in the Requirements requirements section below, the most likely explanation will be a claim that the email e-mail was in fact solicited.

In determining whether to accept this explanation the ISP must look at how the email e-mail addresses were acquired. Data Protection legislation will normally require that information is processed "fairly and lawfully". In particular, the ISP should look for positive answers to all the following questions:

delete: <ol> delete: <ol>
  • Were people aware that their email address was being collected?
  • Is the email e-mail being sent obviously connected to the collection of the address?
  • Was there a way of "opting out" from receiving email?
  • Is there a way for the recipient of the email to revoke their previous permission?
delete: </ol> delete: </ol> delete: <p> (UK Data Protection legislation implements Directive 97/66/EC; legislation in other insert: <div>
insert: <p>

All EU countries will be similar. The UK Data Protection Registrar offers Guidelines explaining the Data Protection Principles, and have legislation implementing EC Directive 2002/58/EC and its forerunners 95/46/EC and 97/66/EC; in most cases the questions above follow these guidelines.) delete: </p> will reflect the primary concerns of the legislation. insert: </p>

insert: </div>

The effect of these tests is that posting articles to Usenet or the mere visiting of a web site website does NOT make the subsequent sending of bulk email "solicited". Nor does it make it likely that acquiring lists of email e-mail addresses from a third party will mean that a customer has acquired any ability insert: <span class="changed"> entitlement insert: </span> to send solicited email e-mail to those addresses. addresses

Clearly, where someone has explicitly signed up for a mailing list the email that arrives is solicited. However, in the real world some mailing lists are dormant for long periods and the people who join them can have poor memories. When email does arrive it may be reported to the mailing list owner's ISP as being unsolicited. Since the same software can be used to send genuine requested mailing list email and UBE, the ISP will have to apply the tests given above to distinguish the two cases.

Mailing list owners can demonstrate that they are behaving responsibly by keeping good records. Ideally they would be able to produce a copy of the "subscribe" email for the list and would have checked it out at the time by "mailback" confirmation techniques to ensure that a third party had not maliciously requested the subscription. It is of course vital that the recipient of the unwanted email can unsubscribe from the list. Modern mailing list software packages automate all these procedures. There is a great deal more about this topic in the LINX Best Current Practice document on "Operating Mailing Lists" (see insert: <a href="#B"> Appendix B insert: </a> ).

As discussed at the start of this document, ISPs may have customers large enough to apply this BCP on their own account, and manage their own customers or users. In these cases the ISP may depend on their customer to deal with the sender of UBE, and need not apply the sanctions discussed below, such as disconnecting these large customers from the Internet. However, the ISP remains accountable to the wider community, which will expect the ISP to be reasonably assured that their customer will indeed take suitable action in the ISP's stead.

delete: <h3> delete: <a name="toc52"> delete: </a> insert: <h4>

Requirements delete: </h3> delete: <p> insert: </h4>

insert: <ul>
    insert: <li>
  • The ISP MUST act upon proven cases of sending UBE and MUST ensure that the contracts with their customers enable them to act effectively. delete: </p> delete: <p> effectively insert: </li>
  • insert: <li>
  • The ISP MUST ensure that the alleged abuser is NOT informed of the identity of those who are reporting the abuse, except with their explicit permission. delete: </p> delete: <p> permission insert: </li>
  • insert: <li>
  • The ISP MAY immediately terminate the customer's account. delete: </p> delete: <p> account insert: <br />
    insert: <ul>
      insert: <li>
    • However, since ignorance of what is acceptable will remain a popular explanation for abuse, and it may be hard to determine if this was actually the case, the ISP MAY operate a "two strike" 'two strikes' policy and allow a customer to continue to operate their account after a "first offence". delete: </p> delete: <p> insert: </li>
    • insert: </ul>
    insert: </li>
  • insert: <li>
  • If a "two strike" 'two strikes' policy is applied, the ISP SHOULD, on the "first offence" take special steps to educate their customer as to what is acceptable behaviour and it MAY require the customer to sign a specific undertaking not to re-offend before allowing them to access the Internet again. delete: </p> delete: <p> insert: </li>
  • insert: <ul>
      insert: <li>
    • If a "second offence" second origination of UBE by the customer occurs within six months the ISP MUST terminate the customers customer's account and all services connected with it. The loss of the sender's connection to the Internet from a particular email e-mail address is an important sanction in combating UBE. delete: </p> delete: <p> insert: </li>
    • insert: </ul>
    insert: <li>
  • Many people cannot be bothered to report abuse, because they believe reports will not be effective. So an ISP cannot expect to see a large number of corroborating reports. Therefore just two reports which give identical messages MUST be considered to be evidence of bulk sending. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • If the ISP receives a single report of abuse it MAY conclude that there is insufficient evidence that the email e-mail was sent in bulk. It SHOULD, however, inform the customer of the reported incident and SHOULD take the opportunity to remind the customer of the unacceptability of bulk email sending and the sanctions available to combat it. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • The ISP MUST consider the possibility of collusion and forgery, and that reports of abuse may have been faked. It MUST allow the customer the opportunity to establish their innocence, and MUST act reasonably "on the balance of probability" in establishing whether abuse did in fact take place. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • The ISP may find that the customer claims that the email was in fact solicited. The ISP MUST NOT accept this claim unless the email address was obtained and processed "fairly and lawfully". delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • If the email was sent out through mailing list software the ISP MUST consider the likelihood that the email was solicited but this fact has been forgotten. However, the ISP SHOULD encourage mailing list owners to keep records of subscription requests and to validate their authenticity. The ISP MUST ensure that it is straightforward for people to remove themselves from mailing lists run by their customers. delete: </p> delete: <p> insert: </li>
  • insert: <li>
  • Where the sender of UBE is not directly a customer of the ISP, then the ISP MAY delegate the responsibility to enforce this BCP to the its own customer, provided that the ISP takes reasonable steps to ensure that the customer will do so. delete: </p> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: </li>
  • insert: </ul>
insert: <div class="added">
insert: <h2>

insert: <a id="6" name="6"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top 6. Deny use of UBE for promotion insert: </h2>

insert: <h4>

Discussion insert: </h4>

insert: <p>

Improvements in filtering technology have led many senders of UBE to move much of the content of their message from the email to a website or other medium, and to direct their recipients towards that secondary source. Traffic coming to such websites provides the incentive for senders to keep sending UBE, and much UBE would not exist or would be more readily controlled but for the existence of these websites. insert: </p>

insert: <p>

It is not acceptable to use UBE to promote websites or other secondary services, nor is it acceptable to use such services to promote or reap the benefits of sending UBE. Accordingly, use of UBE to promote a website or other service must be treated as an abuse not only of the e-mail service used to send the UBE, but also as infringing the conditions of use of the website or other service promoted by the UBE. The expectation should be that promoting websites via UBE will result in them being shut down. insert: </p>

insert: <p>

The unacceptability of using UBE for promotion and the necessity of taking action against websites is not affected by there being more than one ISP involved. Each ISP is expected to take effective action against their particular customer. insert: </p>

insert: <p>

In some cases a franchise system is in operation and a central, legitimately operated, website is promoted by UBE sent by a franchisee without the knowledge or permission of the central website owner. In such circumstance UBE will only be eliminated if the website owner takes firm action to disenfranchise the UBE sender and to ensure that they do not profit from their abuse. ISPs providing services to such websites must satisfy themselves that appropriate control mechanisms are in place before concluding it would be unfair to suspend the website and letting it remain operational. insert: </p>

insert: <p>

In some cases websites are promoted by third parties who misrepresent the nature of the email they will send, so that UBE is sent on behalf of the website owner. In such circumstances the website owner will look to their service contract with the third party for recompense for the significant damage that will have been done to their reputation. Provided that the ISP is satisfied that the problem will not recur it would clearly be unreasonable to suspend the website. insert: </p>

insert: <h4>

Requirements insert: </h4>

insert: <ul>
    insert: <li>
  • ISPs MUST treat use of UBE to promote a website or other service as an abuse of that other service, as well as an abuse of email service provision. insert: </li>
  • insert: <li>
  • The ISP MUST act upon proven cases of using UBE to promote a website or other service hosted by the ISP whether or not the UBE originated on the ISP's network, and MUST ensure that the contracts with their customers enable them to act effectively. insert: </li>
  • insert: <li>
  • Where the promotion by UBE is authorised by or within the reasonable control of the customer who owns the website or other service, the ISP MUST treat this as abuse by the customer. insert: </li>
  • insert: <li>
  • Where UBE has been sent to promote a website or other service the ISP MAY immediately terminate that service. However, since ignorance of what is acceptable will remain a popular explanation for abuse and since it may be hard to determine if this was actually the case, the ISP MAY operate a 'two strikes' policy and allow a customer to continue to operate their system after a "first offence". insert: </li>
  • insert: </ul>
insert: <p>

If a 'two strikes' policy is applied: insert: </p>

insert: <ul>
    insert: <li>
  • The ISP SHOULD take special steps to educate their customer as to what is acceptable behaviour; insert: </li>
  • insert: <li>
  • it MAY require the customer to sign a specific undertaking not to re-offend or permit a re-offence before allowing them to access the Internet again; insert: </li>
  • insert: <li>
  • it SHOULD also take steps to ensure their customer explicitly informs the actual sender of the UBE that they do not authorise the sending of UBE, and instructs the sender to desist; insert: </li>
  • insert: <li>
  • it MAY require that the customer provide proof they have given such instruction before allowing them to access the Internet again. insert: <br />
    insert: <br />
    insert: </li>
  • insert: </ul>
insert: <li>
  • The ISP MUST ensure that where UBE is being sent to promote their customer's services by the customer's franchisees (or by entities in other similar relationships) the customer has adequate safeguards in their franchise arrangements and is acting promptly to prevent the sender of the UBE from profiting from their activity. The ISP MUST ensure that their contracts with their customers enable them to act effectively in such situations. insert: </li>
  • insert: <li>
  • The ISP may find that the customer claims that email promoting their website was not sent by them or with their authority, or that it was sent maliciously in an attempt to persuade the ISP to take action against the customer. insert: <br />
    insert: <br />
    insert: <ul>
      insert: <li>
    • The ISP MUST consider the possibility that this might be true, and MUST act reasonably "on the balance of probability" in establishing whether abuse did in fact take place. insert: </li>
    • insert: <li>
    • The ISP MUST consider the possibility that the UBE was sent under the authority of the customer but without the customer's direct knowledge. insert: </li>
    • insert: </ul>
    insert: </li>
  • insert: <div>
    insert: <h2 class="added">

    insert: <a id="7" name="7"> delete: </p> delete: <p> delete: </p> 7. Prohibit the distribution of UBE tools and address lists by customers insert: </h2>

    insert: <h4 class="added">

    Discussion insert: </h4>

    insert: <p class="added">

    Some businesses promote the sending of UBE by making available programs for bulk email sending or e-mail address harvesting, and may also sell their own lists of e-mail addresses. Since using these products is unacceptable, the community considers the promotion of these products, usually on the web, as also being unacceptable. Although the major league senders of UBE use their own systems, the ability to obtain "kits" for sending UBE encourages others to attempt to use them and so there is a real benefit in suppressing these kits. insert: </p>

    insert: <p class="added">

    Of course many products have entirely legitimate uses in handling mailing lists run on an opt-in basis and there is no question of preventing these products being promoted. However, legitimate products do not provide methods for hiding the source of e-mail or for seeking out and using third party machines. insert: </p>

    insert: <p class="added">

    Similarly, there are a few legitimate sellers of address lists, although such lists are unusual because of the necessity of complying with Data Protection principles. It is regrettable to note that many alleged "opt-in" lists turn out to be incorrectly described. insert: </p>

    insert: <h4 class="added">

    Requirements insert: </h4>

    insert: <ul>
      insert: <li>
    • ISPs MUST NOT permit customers to advertise or distribute tools or lists of email addresses whose primary purpose is the sending of UBE, and must ensure that their contracts with their customers, for all services but especially websites, reflect this prohibition. Where customers are found to have breached this prohibition, ISPs MUST take effective action to ensure that their customer does not distribute this type of material in the future. insert: </li>
    • insert: <li>
    • When considering a customer advertising or distributing tools for the sending of UBE the ISP MUST consider whether the tool has legitimate uses, but MUST also consider if it has special features which would only be appropriately used when sending UBE. Consideration MUST also be given to the general nature of any advertising material to assess whether it acts effectively to discourage the use of "dual purpose" tools for sending UBE. insert: </li>
    • insert: <li>
    • When considering a customer advertising or distributing lists of email addresses, the ISP MUST consider whether their collection and likely use would conform to Data Protection principles and legislation insert: </li>
    • insert: </ul>
    insert: <div class="added">

    delete: <a name="toc6"> insert: <a id="8" name="8"> delete: </h2> delete: <ul> delete: <li> 8. Disseminate information on action taken against customers delete: </li> delete: </ul> delete: <h3> delete: <a name="toc61"> delete: </a> insert: </h2>

    insert: </div>
    insert: <h4>

    Discussion delete: </h3> insert: </h4>

    There are a number of advantages to making public any action taken against customers who have sent UBE. delete: </p> delete: <p> UBE: insert: </p>

    insert: <ul>
      insert: <li>
    • If the report is timely, it may serve to prevent further reports of abuse from other recipients of the UBE. This will reduce the ISP's workload. delete: </p> delete: <p> workload insert: </li>
    • insert: <li>
    • An ISP which reports the action it takes will improve its standing in the community, since people look favourably upon ISPs which take a tough line on the senders of UBE. UBE insert: </li>
    • insert: <li>
    • The ISP will also demonstrate to potential abusers that there is a real risk of being detected and sanctions being imposed. delete: </p> imposed insert: </li>
    • insert: </ul>

    However, when publishing information about the action that has been taken it is vital to be accurate and matter of fact, for otherwise there is a risk of an action for defamation.

    It is also necessary to comply with Data Protection legislation. This may not apply to companies - so their full name and address can be published; but with individuals it would almost certainly be necessary to avoid exact identification unless contractual steps had been taken to allow this information to be released when abuse had occurred.

    The sort of report which would cause no problems would be along the lines of "On <date> we terminated the account known as <hostname@isp.com> <username@isp.com> because of its use in sending Unsolicited Bulk Email. Further reports of abuse by this account are unnecessary."

    In addition to any public reporting, an ISP will wish to take such steps as are possible to disseminate information about abuse within its own organisation. It is not good practice to allow terminated accounts to be reopened, or the same individual, detectable by name, address or perhaps credit card, to immediately open a new account to replace the previous one.

    delete: <h3> delete: <a name="toc62"> delete: </a> insert: <h4>

    Requirements delete: </h3> delete: <p> insert: </h4>

    insert: <ul>
      insert: <li>
    • ISPs MAY announce the action that they have taken in dealing with the sending of UBE. delete: </p> delete: <p> UBE insert: </li>
    • insert: <li>
    • If announcements are made, ISPs MUST avoid defamation or contravention of the insert: <span class="changed"> Data Protection Act. delete: </p> delete: <p> legislation insert: </span> insert: </li>
    • insert: <li>
    • Even if individual reports are not given, ISPs SHOULD publish overview statistical information. delete: </p> delete: <p> information insert: </li>
    • insert: <li>
    • ISPs SHOULD ensure that individuals whose accounts have been terminated for sending UBE are not immediately able to open a new account, since there is clearly a risk of continuing abuse. delete: </p> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents abuse insert: </li>
    • insert: </ul>
    insert: <h2>

    insert: <a id="9" name="9"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: </p> delete: <p> delete: </p> delete: <h2> delete: <a name="toc7"> delete: </a> 9. Education

    delete: <ul> delete: <li> Education delete: </li> delete: </ul> delete: <h3> delete: <a name="toc71"> delete: </a> insert: <h4>

    Discussion delete: </h3> insert: </h4>

    ISPs need to take steps to educate their customers in acceptable email e-mail behaviour. It is recognised that ISPs may have difficulty in doing this because their marketing departments wish to play up the advantages of the Internet and downplay negative issues.

    Many reports of abuse that are received by ISPs do not contain vital information that will allow action to be taken. Customers forget, for example, to include full header information, which is needed to properly identify the sender. Customers can also let their feelings run away with them and heap abuse on the abuse handling personnel.

    It is the responsibility of everyone to try and improve this situation so that fewer inadequate or objectionable reports are sent, and less time is wasted dealing with such reports and less frustration is experienced by all concerned.

    delete: <h3> delete: <a name="toc72"> delete: </a> insert: <p>

    Many ISPs now operate e-mail filtering systems that attempt to distinguish UBE from legitimate e-mail and block or redirect the UBE. Systems may also attempt to detect mass-mailing email "worms" or "viruses". These systems are not perfect and will let through some UBE and some worms and can, on occasion, also disrupt the flow of items of legitimate email. It is important that ISP customers are aware of whether filtering is occurring, the type of system that is deployed, and hence the likely risk of email disruption. insert: </p>

    insert: <p>

    Because reports sent to "abuse@" mailboxes are highly likely to contain copies of UBE or viruses, it is most important that this email does not pass through filtering systems that discard or reject this type of e-mail. insert: </p>

    insert: <div class="added">
    insert: <h4>

    Requirements delete: </h3> delete: <p> insert: </h4>

    insert: </div>
    insert: <ul>
      insert: <li>
    • ISPs MUST ensure that documentation is available to customers that explains the nature of UBE and that sending it is considered to be unacceptable. delete: </p> delete: <p> This MUST include mention that it is not acceptable to promote a service provided by the ISP using UBE sent via third-party internet connection. insert: </li>
    • insert: <li>
    • ISPs MUST help to educate customers in the information that it is necessary to include in abuse reports, and the way such reports should be written. delete: </p> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: </li>
    • insert: <li>
    • ISPs MAY use automated anti-spam mechanisms to protect customers' email accounts. If such mechanisms are used, the ISP MUST inform the customer and MUST explain what risks this may or may not cause to legitimate email. insert: </li>
    • insert: <li>
    • ISPs MAY provide general advice to customers about any anti-spam mechanisms available that the customer may choose to employ on their own systems. If such advice is given, the ISP MUST explain what risks this may or may not cause to legitimate e-mail. insert: </li>
    • insert: <li>
    • ISPs MUST NOT deploy automated anti-spam or anti-virus mechanisms that block or reject reports sent to their abuse mailboxes. insert: </li>
    • insert: </ul>
    insert: <hr noshade="noshade" size="1" />
    insert: <h2>

    insert: <a name="a"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: <a name="tocA"> delete: </a> delete: </p> delete: <h2> APPENDIX Appendix A: Glossary

    delete: <h3> AUP delete: </h3>
    AUP - Acceptable Use Policy
    insert: <p>

    An extension to the contract between ISP and customer that sets out what the customer may and (mainly) may not do whilst using the ISP's services. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    BCP delete: </h3> delete: <dl> delete: <dt> - Best Current Practice
    insert: <p>

    A description of the best practice presently known to the industry. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    DNS delete: </h3> delete: <dl> delete: <dt> - Domain Name System
    insert: <p>

    The distributed system that provides a translation service between names and IP addresses. It is described in RFC 1035. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    HELO delete: </h3> delete: <dl> delete: <dt> - Hello
    insert: <p>

    A command within the SMTP email protocol, used to announce the name of a remote machine. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    IP delete: </h3> delete: <dl> delete: <dt> - Internet Protocol
    insert: <p>

    A basic protocol for exchanging packets between machines on the Internet. Other protocols are layered upon this to provide services for users. It is described in RFC 791 and RFC 1122. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    ISP delete: </h3> delete: <dl> delete: <dt> - Internet Service Provider
    insert: <p>

    ISP is used in this document as a generic term to describe companies and organisations that provide Internet access to others. It is also used to describe customers of ISPs who have adopted this BCP and are applying it to their own customers in the ISPs stead. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    LINX delete: </h3> delete: <dl> delete: <dt> - London Internet Exchange
    insert: <p>

    The insert: <a class="printable" href="http://www.linx.net/" title="http://www.linx.net/"> LINX insert: </a> is a totally neutral, not-for-profit not for profit partnership between ISPs. It operates the major UK Internet exchange point. As well as its core activity of facilitating the efficient movement of Internet traffic it is involved in non-core activities of general interest to its members. One such activity on "content regulation" has, as part of its work, generated the document from which this document. RIPE Document is derived. insert: </p>

    delete: <dd> See: delete: <a href="http://www.linx.net/"> http://www.linx.net/ delete: </a> delete: </dd> delete: </dl> delete: <h3> insert: <dt>
    NTP delete: </h3> delete: <dl> delete: <dt> - Network Time Protocol
    insert: <p>

    A protocol for obtaining an accurate measurement of the current time described in RFC 1119 and RFC 1305. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    RFC delete: </h3> delete: <dl> delete: <dt> - Request for Comments
    insert: <p>

    The RFCs are a series of notes, started in 1969, about the Internet (originally the ARPANET). The notes discuss many aspects of computing and computer communication focusing in networking protocols, procedures, programs, and concepts, but also including meeting notes, opinion, and sometimes humour. The Internet standards are documented within the insert: <a href="http://www.rfc-editor.org/" target="_blank"> RFC documents. documents insert: </a> . insert: </p>

    insert: <dt>
    RIPE - Réseaux IP Européens insert: </dt>
    See: delete: <a href="http://www.rfc-editor.org/"> http://www.rfc-editor.org/ insert: <p>

    insert: <a class="printable" href="http://www.ripe.net/" title="http://www.ripe.net/"> RIPE is a collaborative forum open to all parties whose objective is to ensure the administrative and technical coordination necessary to enable the operation of the Internet within the RIPE NCC service region. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    RIPE NCC insert: </dt>
    insert: <dd>
    insert: <p>

    The insert: <a href="http://www.ripe.net/"> RIPE NCC insert: </a> is the Regional Internet Registry for Internet number resources in Europe, the Middle East and parts of Asia. The organisation also facilitates RIPE Meetings and RIPE Working Groups. insert: </p>

    insert: </dd>
    insert: <dt>
    SMTP delete: </h3> delete: <dl> delete: <dt> Simple -Simple Mail Transfer Protocol
    insert: <p>

    The email transfer protocol. It is currently documented in RFC 821 and RFC 1123. 2821. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    UBE delete: </h3> delete: <dl> delete: <dt> - Unsolicited Bulk Email
    insert: <p>

    UBE is email that has been sent in large amounts without any explicit requests for it being made. It is sometimes called "junk email" or "spam". At present it usually contains advertising material for commercial ventures of dubious propriety. insert: </p>

    delete: </dl> delete: <h3> insert: <dt>
    UCE delete: </h3> delete: <dl> delete: <dt> - Unsolicited Commercial Email
    insert: <p>

    Some discussion of UBE distinguishes unsolicited email e-mail that is commercial in nature from non-commercial material. This document treats UBE as unacceptable per se, avoiding the need for value judgements judgments on what may or may not be "commercial". insert: </p>

    delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: <dl>
    insert: <hr noshade="noshade" size="1" />
    insert: <h2>

    insert: <a id="B" name="B"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: </p> delete: <p> delete: <br /> delete: <a name="tocB"> delete: </a> delete: </p> delete: <h2> APPENDIX Appendix B: References and Resources

    delete: <p> [Note: the publisher of this document insert: </dl>
    insert: <h4>

    Notes: insert: </h4>

    insert: <blockquote>
    insert: <p>

    1. The RIPE NCC is not responsible for the content of third party third-party sites, and does not necessarily endorse their contents and of course these contents. insert: <br />
    2. It is recognised that the links referred to here may not remain accurate forever] delete: </p> delete: <p> be available or current at any time in the future. insert: </p>

    insert: </blockquote>
    insert: <dl>
    insert: <p>

    insert: <span> There are many sites on the Internet that discuss unsolicited email in general. insert: </span> insert: <br />
    Some of the more interesting ones are:

    insert: <span> There is almost certainly a discussion of the prevention of unauthorised email relaying on the home site of all mail handling mail-handling software. For example: insert: </span> insert: <br />
    Some examples include:

    insert: <span> For a comprehensive survey of pointers to information about email e-mail server software insert: </span> , see the insert: <a class="printable" href="http://www.mail-abuse.com/support/an_sec3rdparty.html" target="_blank" title="http://www.mail-abuse.com/support/an sec3rdparty.html"> MAPS Transport Security Initiative delete: </p> delete: <blockquote> delete: <a href="http://www.mail-abuse.com/an_sec3rdparty.html"> http://maps.vix.com/tsi/ delete: </blockquote> delete: <p> insert: </p>

    insert: <p>

    insert: <span> There are also generic products that can be used with many systems to control relaying. For relaying insert: </span> . insert: <a class="printable" href="http://www.mailshield.com/" target="_blank" title="http://www.mailshield.com"> insert: <br />
    Mailshield insert: </a>
    is a commercial example see: delete: </p> delete: <blockquote> delete: <a href="http://www.mailshield.com/"> http://www.mailshield.com/ example. insert: </p>

    insert: <p>

    You can insert: <a class="printable" href="http://www.abuse.net/relay.html" target="_blank" title="http://www.abuse.net/relay.html"> test delete: </blockquote> delete: <p> To test if your system allows unauthorised relaying use: delete: </p> delete: <blockquote> delete: <a href="http://www.mail-abuse.com/an_sec3rdparty.html"> http://maps.vix.com/tsi/ar-test.html delete: </a> delete: </blockquote> relaying. insert: </p>

    LINX Best Current Practice "Traceability" delete: </p> delete: <blockquote> delete: <a href="http://www.linx.net/noncore/bcp/traceability-bcp.html"> http://www.linx.net/noncore/bcp/traceability-bcp.html Documents: insert: </p>

    insert: <ul>
      insert: <li>
    • insert: <a class="printable" href="https://www.linx.net/good/bcp/traceability-bcp-v1_0.html" target="_blank" title="http://www.linx.net/www_public/community_involvement/bcp/traceabilitybcp_v1"> Traceability delete: </blockquote> delete: <p> insert: </li>
    • insert: <li>
    • insert: <a class="printable" href="https://www.linx.net/good/bcp/mailinglist-bcp-v1_0.html" target="_blank" title="http://www.linx.net/www_public/community_involvement/bcp/bcp_operating_mailing_lists"> Operating Mailing Lists insert: </a> insert: </li>
    • insert: </ul>
    insert: <p>

    insert: <span> All published RFCs are available from: delete: </p> delete: <blockquote> delete: <a href="http://www.ietf.org/"> http://www.ietf.org/ insert: </span> insert: <br />
    insert: <a class="printable" href="http://www.ietf.org/rfc.html" target="_blank" title="http://www.ietf.org/rfc.html"> http://www.ietf.org/rfc.html delete: </blockquote> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: </p>

    insert: <hr noshade="noshade" size="1" />
    insert: <h2>

    insert: <a name="c"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: <a name="tocC"> delete: </a> delete: </p> delete: <h2> APPENDIX Appendix C: Specimen Clauses

    The following are clauses that ISPs may use in their Terms and Conditions and elsewhere to support the enforcement of sanctions against senders and promoters of UBE, as required to conform to this BCP. In these model clauses the ISP is referred to as "We" "we"/"us" and the customer as "You". "you"/"your". ISPs may wish to replace these by other defined terms from their own paperwork.

    delete: <p> insert: <h4>

    General clause to allow action to be taken delete: </p> delete: <blockquote> insert: </h4>

    insert: <dt class="top">
    From time to time We we publish Acceptable Use Policies ("AUPs") (AUPs) for the various services We we provide. As a condition of Your your use of a service, You you are required to abide by the then current AUP for that service. If You you do not do so, then We we have the right at our sole discretion to suspend or terminate your account without notice or refund, to make an additional charge for the misuse, or to block access to the relevant part of the service. delete: </blockquote> delete: <p> General clause to permit scanning delete: </p> delete: <blockquote> We may, at our discretion, run manual service insert: <span> , insert: </span> or automatic systems to determine Your compliance with our AUPs (e.g. scanning for "open mail relays"). You are deemed to have granted permission for this limited intrusion onto Your network or machine. delete: </blockquote> delete: <p> An AUP clause to disallow sending of bulk email delete: </p> delete: <blockquote> delete: <p> You may not use your account to send Unsolicited Bulk Email. You must have explicit permission from all destination addresses before you send an email in any quantity. delete: </p> delete: <p> You may not assume that you have been granted permission by passive actions such as the posting of an article to Usenet or a visit made to Your web site. delete: </p> delete: <p> Where You have acquired explicit permission, either on a web site or through some other relationship You should keep a record of this permission and must cease sending email when requested to stop. delete: </p> delete: </blockquote> delete: <p> to apply a combination of these measures insert: <span> . insert: </span> insert: </dt>
    insert: <h4>

    An AUP clause banning unauthorised mail relaying delete: </p> delete: <blockquote> insert: </h4>

    You must ensure that you do not further the sending of Unsolicited Bulk Email (UBE) by others. This applies to both material that originates on Your your system and also third party material that might pass through it.

    This includes but is not limited to a prohibition on running an "open mail relay", viz such as a machine which accepts mail from unauthorised or unknown senders and forwards it onward to a destination outside of Your your machine or network. If Your your machine does relay mail, on an authorised basis, then it must record its passing through your system by means of an appropriate "Received" line.

    As an exception to the ban on relaying and the necessity for a "Received" line, You you may run an "anonymous" relay service provided that You you monitor it in such a way as to detect unauthorised or excessive use.

    delete: </blockquote> delete: <p> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc"> Contents insert: <h4>

    General clause to permit scanning insert: </h4>

    insert: <p>

    We may, at our discretion, run manual or automatic systems to determine your compliance with our AUPs (e.g. scanning for "open mail relays"). You are deemed to have granted permission for this limited intrusion onto your network or machine. insert: </p>

    insert: <h4>

    An AUP clause to disallow sending of unsolicited bulk -mail (UBE) insert: </h4>

    insert: <p>

    You may not use your account to send unsolicited bulk email. You must have explicit permission from all destination addresses before you send an e-mail insert: <span class="changed"> to multiple recipients insert: </span> . insert: </p>

    insert: <dt>
    You may not assume that you have been granted permission by passive actions such as the posting of an article to Usenet or a visit made to your website. insert: </dt>
    insert: <dd>
    insert: </dd>
    insert: <dt>
    Where you have acquired explicit permission, either on a website or through some other relationship, you should keep a record of this permission and must cease sending email when requested to stop. insert: </dt>
    insert: <div>
    insert: <h4>

    An AUP clause to prohibit promotion of websites using UBE insert: </h4>

    insert: <p>

    Websites must not be advertised by you, or by another person, using techniques that would be classified as "abuse" if they were carried out using a service provided by us. This includes, but is not limited to, the sending of unsolicited bulk email. Such action will be treated under this AUP as if it had been done using your account. insert: </p>

    insert: </div>
    insert: <div>
    insert: <h4>

    An AUP clause to prohibit promotion of UBE tools and address lists insert: </h4>

    insert: <p>

    You must not offer or distribute any of the following products or services: insert: </p>

    insert: </div>
    insert: <ul>
      insert: <li>
    • software for sending UBE insert: </li>
    • insert: <li>
    • lists of email addresses, except where all the address owners have given their explicit permission insert: </li>
    • insert: </ul>
    insert: </dl>
    insert: <dl>
    insert: <hr noshade="noshade" size="1" />
    insert: <h2>

    insert: <a name="d"> delete: <a href="http://www.ripe.net/ripe/docs/spam.html#toc00"> Top delete: </a> delete: <a name="tocD"> delete: </a> delete: </p> delete: <p> delete: </p> delete: <h2> APPENDIX Appendix D: Key Words in Requirements Definition of Normative Terms

    This is a summary of the contents of RFC 2119 "Key Words words for Use use in RFCs to Indicate Requirement Levels". Readers are encouraged to consult the full document for guidance.

    delete: <h3> MUST delete: </h3> delete: <blockquote> insert: </dl>
    insert: <ul>
      insert: <li>
    • insert: <span> MUST: insert: </span> This word means that the definition is an absolute requirement. delete: </blockquote> delete: <h3> requirement insert: </li>
    • insert: <li>
    • insert: <span> MUST NOT delete: </h3> delete: <blockquote> NOT: insert: </span> This phrase means that the definition is an absolute prohibition. delete: </blockquote> delete: <h3> SHOULD delete: </h3> delete: <blockquote> prohibition insert: </li>
    • insert: <li>
    • insert: <span> SHOULD: insert: </span> This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. delete: </blockquote> delete: <h3> course insert: </li>
    • insert: <li>
    • insert: <span> SHOULD NOT delete: </h3> delete: <blockquote> NOT: insert: </span> This phrase means that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label. delete: </blockquote> delete: <h3> MAY delete: </h3> delete: <blockquote> label insert: </li>
    • insert: <li>
    • insert: <span> MAY: insert: </span> This word means that an item is truly optional. delete: </blockquote> delete: <blockquote> delete: </blockquote> delete: <hr /> delete: <p> Copyright © delete: <a href="http://www.linx.net/"> LINX delete: </a> 1999 delete: <br /> Copyright © delete: <a href="http://www.ripe.net/ripencc/about/index.html"> RIPE NCC delete: </a> , 2000 delete: </p> delete: <p> optional insert: </li>
    • insert: </ul>
    insert: <dl>
    insert: <hr noshade="noshade" size="1" />
    insert: <h5>
    insert: <small> The original LINX version of this document has certain references specific to the UK, and is available at http://www.linx.net/noncore/bcp/ube-bcp.html delete: </p> at: insert: <br />
    insert: <a href="https://www.linx.net/good/bcp/ube-bcp-v2_0.html" target="_blank"> https://www.linx.net/good/bcp/ube-bcp-v2_0.html insert: </a> insert: </small>
    insert: </h5>
    insert: <h5>
    insert: <small> Version 1.0 of this document was prepared by Richard Clayton and approved by LINX Members on 18 May 1999. insert: </small> insert: </h5>
    insert: <h5>
    insert: <small> Version 2.0 was prepared by Malcolm Hutty and Richard Clayton and approved by LINX Members as an authoritative statement of Best Current Practice on 17 August 2004. insert: </small> insert: </h5>
    insert: </dl>
    insert: <p>

    insert: </p>

    insert: </div>
    insert: </div>
    Good Practice For Combating Unsolicited Bulk In Minimising Email Abuse
    RIPE Documents Search