| Network Working Group | Turner, Editor |
| Internet Draft | govirtual.com.au |
| <draft-turner-antispam-using-messageid-01> | September 2008 |
| Intended status: Informational | |
| Expires: March 2009 |
Spam reduction using messageid.
draft-turner-antispam-using-messageid-01
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 in March 2009.
Copyright © The IETF Trust (2008). All Rights Reserved.
This draft suggests a technique of spam reduction by extending the SMTP service to include a 'Did You Send' query protocol.
A rudimentary suggestion of a protocol is introduced.
Reference is made to RFC2392.
Spam has grown from being:
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.
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.
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.
The MessageID Undefined target: RFC2392xref to unknown element: is a header field generated by a sending smtp Undefined target: RFC2821xref to unknown element: 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.
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.
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.
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.
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.
There is an obvious need to track back through the 'Received:' path entries to the public facing smtp server issueing the email. To shorten the seaching operation it is suggested that a prefix be added to the entry of the public facing server, such as 'dys.publicfacing.server.com'. This facilitates the need of backtracking, firewall requirements, redirection and any need to seperate the dys function. This also facilitates the testing options leading to integration.
The dys protocol is suggested to be an extensionUndefined target: RFC1869xref to unknown element: of the SMTP protocol. Firstly, the ability to recognise any 'not available' signal is suggested.
See section entitled: Denial of service risk.
This document has no actions for IANA.
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).