One document matched: draft-turner-antispam-using-messageid-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-turner-antispam-using-messageid-00" ipr="full3978">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Abbreviated Title">Spam reduction using messageid.</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Mark Turner" initials="" role="editor" surname="Turner">
      <organization>govirtual.com.au</organization>

      <address>
        <postal>
          <street>PO Box 20272</street>

          <!-- Reorder these if your country does things differently -->

          <city>NSW</city>

          <region></region>

          <code>2002</code>

          <country>Australia</country>
        </postal>

        <phone></phone>

        <email>markturner@govirtual.com.au</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="September" year="2008" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>spam reduction</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This draft suggests a technique of spam reduction by extending the 
       SMTP service to include a 'Did You Send' query protocol.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Spam has grown from being:
<list style="symbols">
          <t>An interesting side-effect of new technology.</t>

          <t>A sometimes useful marketing tool.</t>
	  <t>An overload of inbox-time.</t>
	  <t>An overload of disk space.</t>
	  <t>An overload of bandwidth.</t>
	  <t>A dangerous affliction to useful technology.</t>
        </list> 
This document suggests a technique for reducing spam dispersion.
Some estimates put spam traffic at astonishing levels.
Reports are available which speak in terms of 50% of email traffic.
Clearly there is much to be saved with reducing this traffic.
</t></section>
<section title='A basic Did You Send protocol description.'>
<t>A fundamental question in confirming the origins of an object
is to ask if it was sent by the sender.
Current smtp sessions are in the main, send and move on the next task.
There are of course, many tests made by the receiving agent
as to the validity of the email.
Though in search of a basic confirmation exchange,
it could be found that a mechanism is already half in place.
In the form of the MessageID header of every email.
If the sending agent stores the MessageID data for a length of
time, then the receiving agent was to query the originating agent
on this field, confirmation of the send could be confirmed or denied.
</t></section>
<section title='Processing requirements.'>
<t>It may have been impossible for earlier agent implementations
to do this due to the storage and processing requirements percieved.
The cost of these is now greatly reduced.
Calculations would show it to be cheaper than the cost of 
current spam volumes.
Additionally, product such as SQLite have not been available until recently.
</t>
</section>
<section title='Message ID header.'>
<t>The MessageID is a header field generated by a sending smtp<xref target="RFC2821"></xref> server.
Although Message-ID generation does need to be globally unique, 
there is an Internet Draft which suggests this possibility: 
draft-ietf-usefor-message-id-01.txt  
It is generally generated to be locally unique.
It usually uses the FQDN as a suffix, though as there has been no reason to 
use the uniqueness across domains, non-FQDN use has not been questioned.
</t>
</section>
<section title='Uptake scenario.'>
<t>To ensure a reasonable path to implementation, conforming agents
could be given a bypass filter.
This would reduce load on filters, reducing load on servers.
</t></section>
<section title='Major advantages.'><t>
<list style="symbols">
<t>Of significant annoyance to emailer.1 occurs when bounces are received from emailer.2 who have spam which appears to originate from emailer.1's domain, when in fact they are from a spamming bot-net or similar.
</t><t> Reduction in spam, registered addresses.</t>
<t>Reduction of virus payloaded spam.</t></list></t>
</section>
<section title='Techniques for avoidance.'>
<t>Spammers will require a registered domain with a DYS enabled server.
Reverse tracking is therefore possible. Confirmation the spam was sent is implied.
In countries where spam is illegal, this may be useful as evidence.
In other countries, the sending smtp server is visible and block able.
</t></section>
<section title='Denial of service risk.' anchor='DOSrisk'>
<t><list style="symbols">
<t>Scenario 1: Spammer creates botnet which targets a number of domains. 
The domain's issue DYS's towards (unconfirmed) originating server/s (DYS.UOS).
The UOS's reply with many DYS 'UNKNOWN'.
UOS's are inundated with DYS requests with possible adverse effects.
This requires a map of domains to smtp servers.This can be gained from MX records.
Response to this attack could be a focussed blacklist.</t><t>
Scenario 2: Spammer creates botnet which directly issues bogus DYS requests.
Mitigation: Check of reverse IP MX record would indicate a firewall rule is required</t>
<t>Scenario 3: Spammer uses registered MX server to send spam.
A firewall trigger could block traffic after a number of requests.
</t></list></t></section>
<section title='Potential reduction of spam.'>
<t>This is a function of co-operating smtp agents.
If all agents used this protocol, then 'spam' as we know it would be greatly reduced.</t>
</section>
<section title='Configure options.'><t>
The sending agent has options on storage period of sent ID's.
Subsequent handling of receipts could flag or delete the sent.ID.
The sending agent could flag the sent.ID with the time of receipt.
</t>
</section>

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>

    <section anchor="Security" title="Security Considerations">
      <t>See section entitled: Denial of service risk.</t>
    </section>
    <section title="IANA considerations"><t>This document has no actions for IANA.</t></section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml"?-->
      &RFC2821;

</references>
  </back>
</rfc>