Internet Engineering Task Force Turner, Ed.
Internet-Draft govirtual.com.au
Intended status: Informational September 28, 2008
Expires: April 1, 2009
Spam reduction using messageid.
draft-turner-antispam-using-messageid-01
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 April 1, 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 April 1, 2009 [Page 1]
Internet-Draft Abbreviated Title September 2008
Table of Contents
1. Changes from version 00 . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A basic Did You Send protocol description. . . . . . . . . . . 3
4. Processing requirements. . . . . . . . . . . . . . . . . . . . 3
5. Message ID header. . . . . . . . . . . . . . . . . . . . . . . 4
6. Uptake scenario. . . . . . . . . . . . . . . . . . . . . . . . 4
7. Major advantages. . . . . . . . . . . . . . . . . . . . . . . . 4
8. Techniques for avoidance. . . . . . . . . . . . . . . . . . . . 4
9. Denial of service risk. . . . . . . . . . . . . . . . . . . . . 4
10. Potential reduction of spam. . . . . . . . . . . . . . . . . . 5
11. Configure options. . . . . . . . . . . . . . . . . . . . . . . 5
12. Implementation suggestions . . . . . . . . . . . . . . . . . . 5
13. Protocol suggestion . . . . . . . . . . . . . . . . . . . . . . 5
14. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
15. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6
16. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Turner Expires April 1, 2009 [Page 2]
Internet-Draft Abbreviated Title September 2008
1. Changes from version 00
A rudimentary suggestion of a protocol is introduced.
Reference is made to RFC2392 [RFC2392].
2. 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.
3. 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.
4. 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
Turner Expires April 1, 2009 [Page 3]
Internet-Draft Abbreviated Title September 2008
be cheaper than the cost of current spam volumes. Additionally,
product such as SQLite have not been available until recently.
5. Message ID header.
The MessageID [RFC2392] is a header field generated by a sending smtp
[RFC2821] 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.
6. 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.
7. 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.
8. 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.
9. 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
Turner Expires April 1, 2009 [Page 4]
Internet-Draft Abbreviated Title September 2008
'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
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.
10. 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.
11. 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.
12. Implementation suggestions
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.
13. Protocol suggestion
The dys protocol is suggested to be an extension[RFC1869] of the SMTP
protocol. Firstly, the ability to recognise any 'not available'
signal is suggested.
The server is reached via the prefix 'dys', though it is not
configured as such:
Turner Expires April 1, 2009 [Page 5]
Internet-Draft Abbreviated Title September 2008
(smtp exhange).... 'DYS' sent , reply= '502 Error, command not
implemented'
= backoff to regular spam checks
(smtp exhange).... 'DYS' sent , reply= '502 Error, server busy'
= backoff for configured period
(smtp exhange).... 'DYS' sent , reply= '502 Redirect,
an.otherserver.com'
= backoff and retry at an.otherserver.com
The server is reached and provides dys.(ESMTP probe).
(smtp exhange).... 'DYS' sent , reply= '250-DYS' (in exchange).
The server is reached and queried in one operation.
(smtp exhange).... 'DYS
40F655CA30A781488E7BADFECFDA05690769F40B@mail.acorp.com'
The 'dys server' makes a lookup request and replies.
Answer: NRF = 'No Record Found'.
Answer: DSRR = 'Did Send Receipt Received'. (Did Send, but
already marked as received).
Answer: RF = 'Record Found'.
14. Security Considerations
See section entitled: Denial of service risk.
15. IANA considerations
This document has no actions for IANA.
16. Normative References
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995.
Turner Expires April 1, 2009 [Page 6]
Internet-Draft Abbreviated Title September 2008
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[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 April 1, 2009 [Page 7]
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 April 1, 2009 [Page 8]