Bert, We have just posted a final draft of the SpamOps draft. Here is the formal request for publication. Please let us know of any questions, etc. And MANY thanks for you attention on this. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net - - - - - - - - - - Individual Submission Request for BCP status, for: (A copy is also at: .) # I-D Title: Email Submission Between Independent Networks # I-D Intended Status at Publication: BCP # Abstract: Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. Consequently the document offers recommendations for constructive operational policies between independent operators of email transmission services. # Author(s): Carl Hutzler America Online Dave Crocker Brandenburg InternetWorking Peter W. Resnick QUALCOMM Incorporated Robert Sanders Earthlink, Inc. PROTOCOL WRITE-UP ----------------- > 1.a) Have the chairs personally reviewed this version of the Internet > Draft (ID), Yes, although this is an individual submission. The document authors each have extensive email technical and operations experience and contributed significantly to the writing of the document. See discussion of additional reviews, below. > and in particular, do they believe this ID is ready to forward to the IESG > for publication? Yes. We are thoroughly comfortable with the recommendations and writing in this document. We believe that it reflects a judicious set of procedures, to improve both sender-side and receiver-side network operations, with respect to control and reduction of spam traffic. > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? Do you have any concerns about the > depth or breadth of the reviews that have been performed? The document has had extensive public review, over the course of one year: Revision history: Four I-D versions, over the course of 1 year: It is a recommendation from an Industry consortium: Anti-Spam Technical Alliance Technology and Policy Proposal at Multiple references to the document in the IRTF's ASRG and the retained ietf-smtp mailing list. SPF discussion list: Industry news reference, e.g.: Specific reviewers include: eric@SENDMAIL.COM Eric Allman harald@ALVESTRAND.NO Harald Tveit Alvestrand bishopgreg@AOL.COM Greg Bishop jdfalk@MICROSOFT.COM JD Falk eliotg@EXCHANGE.MICROSOFT.COM Eliot Gillum joshuago@MICROSOFT.COM Joshua Goodman erichh@CORP.EARTHLINK.NET Erich Hablutzel jhayward3@AOL.COM Jeff Hayward hkatz@EXCHANGE.MICROSOFT.COM Harry Katz johnl@IECC.COM John Levine miles@YAHOO-INC.COM Miles Libby sandersr@CORP.EARTHLINK.NET Robert Sanders saschwein@AOL.COM Steve Schweinhart craigspi@MICROSOFT.COM Craig Spiezle davidvet@MICROSOFT.COM David Vetter Techno@AOL.NET Eric Zeller > 1.c) Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? Other than the benefits of a community-wide Last Call, we do not see the need for additional review. The document represents conservative choices, so that we do not see any risks in its contents. > 1.d) Do you have any specific concerns/issues with this document that > you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain parts of the > document, or have concerns whether there really is a need for > it. In any event, if your issues have been discussed in the WG > and the WG has indicated it that it still wishes to advance the > document, detail those concerns in the write-up. As with any anti-spam recommendation, the biggest concern is that the careful, limited scope of the recommendations might not be appreciated by readers. That is, there is a tendency to expect too much benefit. The document has been careful to do nothing to encourage such misunderstanding. > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? The document has strong agreement from the authors and a wide audience of experts. We have also had positive comments from external reviewers of the document. Most criticisms of the document are to request more recommendations or to make the existing ones stronger. We have declined to make these, because they do not reflect sufficient community consensus and/or they would introduce risk. > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. No. > 1.g) Have the chairs verified that the document adheres to all of the > ID nits? (see http://www.ietf.org/ID-Checklist.html). We believe the document is conformant. > 1.h) Is the document split into normative and informative references? Yes. > Are there normative references to IDs, where the IDs are not > also ready for advancement or are otherwise in an unclear state? No. > 1.i) For Standards Track and BCP documents, the IESG approval > announcement includes a write-up section with the following > sections: > > * Technical Summary Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. Consequently the document offers recommendations for constructive operational policies between independent operators of email transmission services. The document seeks BCP status. Comments and discussion of this document should be addressed to the ietf-smtp@imc.org mailing list. > * Working Group Summary The very characteristics that make email such a convenient communications medium - its near ubiquity, rapid delivery and low cost - have made it a fertile ground for the distribution of unwanted or malicious content. Spam, fraud and worms have become a serious problem, threatening the viability of email and costing end users and providers millions of dollars in damages and lost productivity. In recent years, independent operators including enterprises and ISPs have turned to a number of different technologies and processes, in an attempt to combat these problems, with varying effect and with vastly different impacts on users and on the Internet mail infrastructure. Email will often travel between multiple independent providers of email transmission services, en route to its final destination. They will generally have no prior arrangement with one another and may employ different rules on the transmission. It is therefore difficult both to debug problems that occur in mail transmission and to assign accountability if undesired or malicious mail is injected into the Internet mail infrastructure. This document suggests operational policies that independent operators of email transmission services may adopt, to assist in providing continued, smooth operation of Internet email, but with controls in place to improve accountability. These policies are appropriate for operators of all sizes and may be implemented by operators independently, without regard for whether the other side of an email exchange has implemented them. It is important to note that the adoption of these policies alone will not solve the problems of spam and other undesirable email. However they provide a useful step in clarifying lines of accountability and interoperability between operators. This will help raise the bar for abusers, and will pave the way for additional tools to preserve the utility of the Internet email infrastructure. > * Protocol Quality This is a true Best Common Practice (BCP) document. No new protocols are created. All references to protocols refer to existing RFC protocols. > 1.j) Please provide such a write-up. Recent examples can be found in > the "protocol action" announcements for approved documents. See above in 1.i