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

Internet Engineering Task Force                              Turner, Ed.
Internet-Draft                                          govirtual.com.au
Intended status: Informational                         September 1, 2008
Expires: March 5, 2009


                    Spam reduction using messageid.
                draft-turner-antispam-using-messageid-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 5, 2009.

Abstract

   This draft suggests a technique of spam reduction by extending the
   SMTP service to include a 'Did You Send' query protocol.













Turner                    Expires March 5, 2009                 [Page 1]

Internet-Draft              Abbreviated Title             September 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  A basic Did You Send protocol description.  . . . . . . . . . . 3
   3.  Processing requirements.  . . . . . . . . . . . . . . . . . . . 3
   4.  Message ID header.  . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Uptake scenario.  . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Major advantages. . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Techniques for avoidance. . . . . . . . . . . . . . . . . . . . 4
   8.  Denial of service risk. . . . . . . . . . . . . . . . . . . . . 4
   9.  Potential reduction of spam.  . . . . . . . . . . . . . . . . . 5
   10. Configure options.  . . . . . . . . . . . . . . . . . . . . . . 5
   11. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   12. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5
   13. Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 6


































Turner                    Expires March 5, 2009                 [Page 2]

Internet-Draft              Abbreviated Title             September 2008


1.  Introduction

   Spam has grown from being:

   o  An interesting side-effect of new technology.

   o  A sometimes useful marketing tool.

   o  An overload of inbox-time.

   o  An overload of disk space.

   o  An overload of bandwidth.

   o  A dangerous affliction to useful technology.

   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.


2.  A basic Did You Send protocol description.

   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.


3.  Processing requirements.

   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.


4.  Message ID header.

   The MessageID is a header field generated by a sending smtp[RFC2821]



Turner                    Expires March 5, 2009                 [Page 3]

Internet-Draft              Abbreviated Title             September 2008


   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.


5.  Uptake scenario.

   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.


6.  Major advantages.

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

   o  Reduction in spam, registered addresses.

   o  Reduction of virus payloaded spam.


7.  Techniques for avoidance.

   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.


8.  Denial of service risk.

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

   o  Scenario 2: Spammer creates botnet which directly issues bogus DYS
      requests.  Mitigation: Check of reverse IP MX record would



Turner                    Expires March 5, 2009                 [Page 4]

Internet-Draft              Abbreviated Title             September 2008


      indicate a firewall rule is required

   o  Scenario 3: Spammer uses registered MX server to send spam.  A
      firewall trigger could block traffic after a number of requests.


9.  Potential reduction of spam.

   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.


10.  Configure options.

   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.


11.  Security Considerations

   See section entitled: Denial of service risk.


12.  IANA considerations

   This document has no actions for IANA.


13.  Normative References

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.


Author's Address

   Mark Turner (editor)
   govirtual.com.au
   PO Box 20272
   NSW,   2002
   Australia

   Phone:
   Email: markturner@govirtual.com.au






Turner                    Expires March 5, 2009                 [Page 5]

Internet-Draft              Abbreviated Title             September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Turner                    Expires March 5, 2009                 [Page 6]