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 6, 2009.

Abstract

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

Table of Contents

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

1.  Introduction

Spam has grown from being:

• An interesting side-effect of new technology.
• A sometimes useful marketing tool.
• An overload of inbox-time.
• An overload of disk space.
• An overload of bandwidth.
• 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] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) 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.

• 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.
• Reduction in spam, registered addresses.
• 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.

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

Author's Address

Full Copyright Statement

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