Email Submission Operations: Access and Accountability Requirements
RFC 5068
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
08 | (System) | Received changes through RFC Editor sync (changed abstract to 'Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The … Received changes through RFC Editor sync (changed abstract to '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. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services. Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.') |
|
2015-10-14
|
08 | (System) | Notify list changed from cdhutzler@aol.com, dcrocker@bbiw.net, presnick@qualcomm.com, sandersr@corp.earthlink.net, hardie@qualcomm.com, sah@428cobrajet.net, dot@dotat.at to sah@428cobrajet.net, hardie@qualcomm.com, sandersr@corp.earthlink.net |
|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2007-12-02
|
08 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2007-12-02
|
08 | Amy Vezza | [Note]: 'RFC 5068<br>BCP 0134' added by Amy Vezza |
|
2007-11-07
|
08 | (System) | RFC published |
|
2007-08-28
|
08 | (System) | IANA Action state changed to No IC from In Progress |
|
2007-08-28
|
08 | (System) | IANA Action state changed to In Progress |
|
2007-08-28
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2007-08-27
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2007-08-27
|
08 | Amy Vezza | IESG has approved the document |
|
2007-08-27
|
08 | Amy Vezza | Closed "Approve" ballot |
|
2007-08-24
|
08 | (System) | Removed from agenda for telechat - 2007-08-23 |
|
2007-08-23
|
08 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation - Defer by Amy Vezza |
|
2007-08-23
|
08 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
|
2007-08-22
|
08 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2007-08-22
|
08 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
|
2007-08-22
|
08 | Jari Arkko | [Ballot comment] |
|
2007-08-22
|
08 | Jari Arkko | [Ballot comment] Christian Vogt's review: This document provides guidance on designing secure authentication mechanisms for Web services. The goal is to replace HTML-form- and password-based … [Ballot comment] Christian Vogt's review: This document provides guidance on designing secure authentication mechanisms for Web services. The goal is to replace HTML-form- and password-based mechanisms that are commonly used today. The document is a valuable step forward in the combat against phishing. However, below are a few issues that Sam might want to address before this documents becomes RFC. Section 3.1 (Capabilities of Attackers): The 1st paragraph lists mechanisms by which an attacker can trick a victim user into accepting a spoofed Web site. One of them is "on-path network attacks". I am unsure what is meant by this. It could refer to attacks on DNS, but those attacks are listed separately. It could also refer to MiTM attacks on TLS connection establishment, but it is assumed that certificates are available. In consequence, I would assume that it refers to the process of obtaining a certificate. But this is unclear and should be clarified. Section 3.1 (Capabilities of Attackers): The 2nd paragraph of section 3.1 describes which components of a UI an attacker might be able to forge. The text differentiates between components that are based on special knowledge about the user (such as an account balance or transaction history), and components that do not require such knowledge (such as a loginpage). What I am missing here is some thoughts on how far forgery of the latter type of component could enable forgery of the former type. Reusing the examples in parentheses, an attacker might be able to trick a victim user into providing a password via a spoofed login page, and then retrieve the user's current account balance and transaction history from the legitimate site in order to subsequently print it on another spoofed page. Section 4.3 (No Password Equivalents): The terms "strong/weak password equivalence" seem to be used differently in this document than in [draft-iab-auth-mech], which is uses as a reference in this document. In [draft-iab-auth-mech], the terms are used to describe a dependency between login credentials for different systems, while in this document, they are used for the data exchanged between an authenticator and an authenticatee. Section 8 (Security Considerations): Paragraph 5 mixes two issues: (i) Web sites using both the proposed authentication mechanism and a legacy, HTML-based mechanism for backwards compatibility (ii) users who take the same password for Web sites with the proposed authentication mechanism and Web sites with a legacy authentication mechanism These two issues are orthogonal and should be separated. While the document suggests a solution for issue (ii) -- which calls for users not to use the same password for different Web sites --, there is no suggested solution for issue (i). One possible solution could be provide a mechanism by which users can disable access through legacy authentication mechanisms. Re-enabling access for legacy authentication mechanisms could be accomplished only through the proposed authentication mechanism. Maybe Sam wants to add this to his draft... Editorial: - General Abbreviation "UI" is never spelled out. I'd recommend spelling it out everywhere. - Abstract s/providers and users and for /providers and users, and/ s/These requirements may serve/These requirements may also serve/ ? - Section 4.1 s/Passwords and OTher Methods/Passwords and Other Methods/ s/do not have smart cards/do not have smart card readers/ s/access to other resources may/access to other resources--may/ - Section 4.2 s/security community has/security community has done/ - Section 4.3 s/No Password EquivelentsN/o Password Equivalents/ - Section 4.6 s/the the/the/ |
|
2007-08-21
|
08 | Sam Hartman | [Ballot comment] I'm quite surprised to be able to support publication of this document and especially support doing so as a BCP. I expected to … [Ballot comment] I'm quite surprised to be able to support publication of this document and especially support doing so as a BCP. I expected to have a discuss based on some of my and others' comments in the first and second last call. However that ended up not being the case. While I agree with the general principle that John Klensin raised, I think that in this case BCP is an appropriate status. |
|
2007-08-21
|
08 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
|
2007-08-20
|
08 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
|
2007-08-16
|
08 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2007-08-16
|
08 | Cullen Jennings | Placed on agenda for telechat - 2007-08-23 by Cullen Jennings |
|
2007-08-16
|
08 | Ron Bonica | Removed from agenda for telechat - 2007-08-23 by Ron Bonica |
|
2007-08-14
|
08 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2007-07-30
|
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2007-07-19
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2007-07-17
|
08 | Chris Newman | [Ballot Position Update] New position, Yes, has been recorded by Chris Newman |
|
2007-07-16
|
08 | Sam Hartman | State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman |
|
2007-07-16
|
08 | Russ Housley | [Ballot discuss] John Klensin raised a question in Last Call that did not receive an adequate response. John said: > > Many … [Ballot discuss] John Klensin raised a question in Last Call that did not receive an adequate response. John said: > > Many or most of my concerns about this document would disappear if > it were placed on the normal standards track as a Proposed Standard, > followed by a review after some months of which features and > recommendations really had received considerable implementation > and deployment and proven effective in practice. |
|
2007-07-16
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2007-07-16
|
08 | Russ Housley | [Ballot discuss] John Klensin raised a question in Last Call that did not receive an adequate response. John said: > > Many … [Ballot discuss] John Klensin raised a question in Last Call that did not receive an adequate response. John said: > > Many or most of my concerns about this document would disappear if > it were placed on the normal standards track as a Proposed Standard, > followed by a review after some months of which features and > recommendations really had received considerable implementation > and deployment and proven effective in practice. > John also said: > > This document even appears to update RFC 2821, altering one of its > requirements. |
|
2007-07-16
|
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2007-07-15
|
08 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2007-07-13
|
08 | Lars Eggert | [Ballot comment] INTRODUCTION, paragraph 15: > The document seeks BCP status. Comments and discussion of this > document should be addressed to the … [Ballot comment] INTRODUCTION, paragraph 15: > The document seeks BCP status. Comments and discussion of this > document should be addressed to the ietf-smtp@imc.org mailing list. Remove this paragraph. |
|
2007-07-13
|
08 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded by Lars Eggert |
|
2007-07-11
|
08 | Dan Romascanu | [Note]: 'Dave Crocker is the PROTO shepherd.' added by Dan Romascanu |
|
2007-07-10
|
08 | (System) | New version available: draft-hutzler-spamops-08.txt |
|
2007-07-10
|
08 | Dan Romascanu | [Note]: 'Dave Crocker is the PROTO shepherd.<br><br>Draft-08 was submitted and should show up soon in the repository. The draft is available at http://bbiw.net/recent.html#spamops.' added by … [Note]: 'Dave Crocker is the PROTO shepherd.<br><br>Draft-08 was submitted and should show up soon in the repository. The draft is available at http://bbiw.net/recent.html#spamops.' added by Dan Romascanu |
|
2007-07-10
|
08 | Dan Romascanu | Placed on agenda for telechat - 2007-07-19 by Dan Romascanu |
|
2007-07-10
|
08 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
|
2007-07-10
|
08 | Dan Romascanu | Ballot has been issued by Dan Romascanu |
|
2007-07-10
|
08 | Dan Romascanu | Created "Approve" ballot |
|
2007-07-10
|
08 | Dan Romascanu | State Changes to IESG Evaluation from Waiting for Writeup by Dan Romascanu |
|
2007-07-09
|
08 | Dan Romascanu | A revised version of the draft-hutzler-spamops draft has been submitted to the I-D mechanism. Various formats are now available at: <http://bbiw.net/recent.html#spamops> … A revised version of the draft-hutzler-spamops draft has been submitted to the I-D mechanism. Various formats are now available at: <http://bbiw.net/recent.html#spamops> The modifications are in response to comments made after this latest Last Call, except for item #8... Responses and changes: 1. Comments to the Last Call were generally positive. Formal reviews were specifically positive about the utility of the document. Feedback from the email and anti-abuse operations community has been generally positive. Negative comments have tended to express a desire that the document cover more issues, not different ones or fewer ones. That is, those unhappy with the document wish it tackled more of the problem. Given that the document is an initial effort at standardizing email operations practices of this type, its very limited scope is intentional. So the concerns that were expressed justify follow-on efforts, rather than modifications to the current one. 2. Should the document be a BCP or seek some other status? Our reading of the definition of BCP -- and some comments posted on this matter -- indicate that this draft is exactly what a BCP label is intended for. 3. Word-smithing suggestions A number of comments were offered to improve the clarity, precision or fine-grained accuracy of the draft. These did not pertain to basic aspects of the document, but raised concerns about possible misunderstandings; the suggestions have been incorporated. 4. Document scope It was suggested that the document text emphasize that its scope is SMTP and SUBMISSION. This has been done. 5. Document title This is also intended to ensure that the document's scope is clear to (potential) readers, in particular to attract email operators. The title has been changed accordingly. 6. Normative text about supporting port 25 The text went beyond what was intended and has been modified. 7. Normative text about delivery (MDA) behaviors This was out of scope and has been removed. 8. Author replacement Robert Sanders has disappeared. I've tried to track him down but failed to get any responses from him. We've replaced him with Tony Finch, who has extensive email technical and operations experience, as well as quite a bit of recent IETF involvement. |
|
2007-07-09
|
08 | Dan Romascanu | State Change Notice email list have been change to cdhutzler@aol.com; dcrocker@bbiw.net; presnick@qualcomm.com; sandersr@corp.earthlink.net; hardie@qualcomm.com; sah@428cobrajet.net; dot@dotat.at from cdhutzler@aol.com; … State Change Notice email list have been change to cdhutzler@aol.com; dcrocker@bbiw.net; presnick@qualcomm.com; sandersr@corp.earthlink.net; hardie@qualcomm.com; sah@428cobrajet.net; dot@dotat.at from cdhutzler@aol.com; dcrocker@bbiw.net; presnick@qualcomm.com; sandersr@corp.earthlink.net; hardie@qualcomm.com; sah@428cobrajet.net |
|
2007-07-06
|
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Love Astrand. |
|
2007-06-29
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Love Astrand |
|
2007-06-29
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Love Astrand |
|
2007-06-29
|
08 | Samuel Weiler | Assignment of request for Last Call review by SECDIR to Steven Bellovin was rejected |
|
2007-06-20
|
08 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2007-06-13
|
08 | Yoshiko Fong | IANA Last Call Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2007-06-07
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steven Bellovin |
|
2007-06-07
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steven Bellovin |
|
2007-06-06
|
08 | Amy Vezza | Last call sent |
|
2007-06-06
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2007-06-06
|
08 | Dan Romascanu | Proto write-up from PROTO shepherd Dave Crcker Request: 'Email Submission: Access and Accountability' <draft-hutzler-spamops-07> as a BCP RFC … Proto write-up from PROTO shepherd Dave Crcker Request: 'Email Submission: Access and Accountability' <draft-hutzler-spamops-07> as a BCP RFC This document is an independent submission to the IETF. It has been circulated extensively on the ietf-smtp mailing , the ietf mailing list, and numerous Internet operations and anti-spam mailing lists. (See also <http://bbiw.net/recent.html#spamops> for other formatted versions ofthe document. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hutzler-spamops-07.txt Questionnaire: (1.a) Who is the Document Shepherd for this document? Dave Crocker Has the Document Shepherd personally reviewed this version of the document Yes and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes (1.b) Has the document had adequate review both from key members of the interested community and others? Yes Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? No For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (1.e) How solid is the consensus of the interested community behind this document? Consensus appears to be quite solid. Any disagreements about the content have primarily been restricted to efforts to *add* more requirements and strictures. Instead, the document diligently avoids such issues that engender controversy. Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? This document has been discussed broadly within the email anti-abuse community, as well as within the IETF email technical community. A large number of people in this community have spoken up at one time or another with words of encouragement and positive suggestions for improvements. There has been some compromise on some of the terminology, but rough consensus appears to have been achieved on the compromises. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See www.ietf.org/ID-Checklist.html and tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Yes Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No If such normative references exist, what is the strategy for their completion? n/a Are there normative references that are downward references, as described in [RFC3967] (Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,â€? December 2004.)? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967] (Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,â€? December 2004.). No (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? n/a (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? n/a (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains 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, suchas 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. With the recent advent of email authentication technologies aimed at providing assurances and traceability between internetworked networks, the authors recognized that the initial submission of a message became the weakest link. Consequently, the document offers recommendations for constructive operational policies for the first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. Development Summary Although formally an Independent submission, the document authors represent extensive email technical and operations experience and have extensively circulated successive versions of the draft among the Internet mail technical and operations communities. The document has synthesized that considerable body of review. Document Quality The document has been extensively reviewed and has received positive feedback as being a useful contribution to the body of Internet Mail practices documents. Personnel Who is the Document Shepherd for this document? Dave Crocker Who is the Responsible Area Director? Dan Romascanu |
|
2007-06-06
|
08 | Dan Romascanu | State Changes to Last Call Requested from AD Evaluation::External Party by Dan Romascanu |
|
2007-06-06
|
08 | Dan Romascanu | Last Call was requested by Dan Romascanu |
|
2007-06-06
|
08 | Dan Romascanu | Proto write-up from PROTO shepherd Dave Crcker Request: 'Email Submission: Access and Accountability' <draft-hutzler-spamops-07> as a BCP RFC … Proto write-up from PROTO shepherd Dave Crcker Request: 'Email Submission: Access and Accountability' <draft-hutzler-spamops-07> as a BCP RFC This document is an independent submission to the IETF. It has been circulated extensively on the ietf-smtp mailing , the ietf mailing list, and numerous Internet operations and anti-spam mailing lists. (See also <http://bbiw.net/recent.html#spamops> for other formatted versions ofthe document. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hutzler-spamops-07.txt Questionnaire: (1.a) Who is the Document Shepherd for this document? Dave Crocker Has the Document Shepherd personally reviewed this version of the document Yes and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes (1.b) Has the document had adequate review both from key members of the interested community and others? Yes Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? No For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (1.e) How solid is the consensus of the interested community behind this document? Consensus appears to be quite solid. Any disagreements about the content have primarily been restricted to efforts to *add* more requirements and strictures. Instead, the document diligently avoids such issues that engender controversy. Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? This document has been discussed broadly within the email anti-abuse community, as well as within the IETF email technical community. A large number of people in this community have spoken up at one time or another with words of encouragement and positive suggestions for improvements. There has been some compromise on some of the terminology, but rough consensus appears to have been achieved on the compromises. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See www.ietf.org/ID-Checklist.html and tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Yes Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No If such normative references exist, what is the strategy for their completion? n/a Are there normative references that are downward references, as described in [RFC3967] (Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,â€? December 2004.)? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967] (Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level,â€? December 2004.). No (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? n/a (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? n/a (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains 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, suchas 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. With the recent advent of email authentication technologies aimed at providing assurances and traceability between internetworked networks, the authors recognized that the initial submission of a message became the weakest link. Consequently, the document offers recommendations for constructive operational policies for the first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. Development Summary Although formally an Independent submission, the document authors represent extensive email technical and operations experience and have extensively circulated successive versions of the draft among the Internet mail technical and operations communities. The document has synthesized that considerable body of review. Document Quality The document has been extensively reviewed and has received positive feedback as being a useful contribution to the body of Internet Mail practices documents. Personnel Who is the Document Shepherd for this document? Dave Crocker Who is the Responsible Area Director? Dan Romascanu |
|
2007-06-06
|
08 | Dan Romascanu | [Note]: 'Dave Crocker is the PROTO shepherd' added by Dan Romascanu |
|
2007-05-25
|
07 | (System) | New version available: draft-hutzler-spamops-07.txt |
|
2007-05-21
|
06 | (System) | New version available: draft-hutzler-spamops-06.txt |
|
2006-05-30
|
08 | Dan Romascanu | [Note]: '5/30/06 - message from one of the editors (Dave Crocker) - ''The impediment is me. I have the token for doing some upgrades to … [Note]: '5/30/06 - message from one of the editors (Dave Crocker) - ''The impediment is me. I have the token for doing some upgrades to the doc and simply have not had a chance to get to it.''<br>' added by Dan Romascanu |
|
2006-03-30
|
08 | Dan Romascanu | Shepherding AD has been changed to Dan Romascanu from Bert Wijnen |
|
2006-03-09
|
08 | Bert Wijnen | State Changes to AD Evaluation::External Party from Waiting for Writeup::AD Followup by Bert Wijnen |
|
2006-03-09
|
08 | Bert Wijnen | Not 100% sure what status is, but I believe that authors have done a call for operator review/comment. So I consider it off of my … Not 100% sure what status is, but I believe that authors have done a call for operator review/comment. So I consider it off of my plate untill the authors re-contact me (or my successor) |
|
2006-03-09
|
08 | Bert Wijnen | Status date has been changed to 2006-03-08 from 2005-07-13 |
|
2005-10-27
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2005-10-27
|
05 | (System) | New version available: draft-hutzler-spamops-05.txt |
|
2005-07-13
|
08 | Bert Wijnen | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Bert Wijnen |
|
2005-07-13
|
08 | Bert Wijnen | Some 150+ posting on the IETF Last Call. I (bert) am reviewing them. Dave Crocker informs a that a new revision is in the works. |
|
2005-07-13
|
08 | Bert Wijnen | Status date has been changed to 2005-07-13 from 2005-06-03 |
|
2005-07-01
|
08 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2005-06-15
|
08 | Michelle Cotton | IANA Last Call Comments: No IANA Considerations section. We understand this document to have NO IANA Actions. |
|
2005-06-03
|
08 | Michael Lee | State Changes to In Last Call from Last Call Requested by Michael Lee |
|
2005-06-03
|
08 | Bert Wijnen | State Change Notice email list have been change to cdhutzler@aol.com; dcrocker@bbiw.net; presnick@qualcomm.com; sandersr@corp.earthlink.net; hardie@qualcomm.com; sah@428cobrajet.net from cdhutzler@aol.com; dcrocker@bbiw.net; … State Change Notice email list have been change to cdhutzler@aol.com; dcrocker@bbiw.net; presnick@qualcomm.com; sandersr@corp.earthlink.net; hardie@qualcomm.com; sah@428cobrajet.net from cdhutzler@aol.com; dcrocker@bbiw.net; presnick@qualcomm.com; sandersr@corp.earthlink.net |
|
2005-06-03
|
08 | Bert Wijnen | Positive reviews received from APPS area (Marshall Rose and Rand Wacker). -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Wednesday, May 25, 2005 18:52 … Positive reviews received from APPS area (Marshall Rose and Rand Wacker). -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Wednesday, May 25, 2005 18:52 To: Ted Hardie Cc: Rand Wacker; Scott Hollenbeck; Bert Wijnen Subject: Re: review request for draft-hutzler-spamops On May 25, 2005, at 09:33, Ted Hardie wrote: > Hi Rand, Marshall, > The OPS folks have been handed draft-hutzler-spamops > as a candidate for BCP. I was wondering if you would be willing > to review it and feedback comments to me, Scott and Bert Wijnen? i have reviewed http://www.ietf.org/internet-drafts/draft-hutzler-spamops-04.txt it is more or less to the point. it has nothing objectionable. it codifies a proper subset of the existing practice of many ISPs, so i do not foresee any harm by progressing it as a BCP. /mtr -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Thursday, May 26, 2005 22:20 To: Wijnen, Bert (Bert) Subject: Fwd: Re: Request for review of draft-hutzler-spamops Hi Bert, You've seen Marshall's message by now; here' Rand's. Ted >Cc: Scott Hollenbeck <sah@428cobrajet.net> >From: Rand Wacker <randal@singletrack.org> >Subject: Re: Request for review of draft-hutzler-spamops >Date: Wed, 25 May 2005 17:45:27 -0700 >To: Ted Hardie <hardie@qualcomm.com> >X-QUALCOMM-AV: Sophos AV Testing > >Ted, I reviewed this document this afternoon and find nothing >glaringly dangerous about it. Codifying the need to get rid of open >relays is always good, opening up the submission port is always good. > >I think it would be good if the document suggested a much stronger >stance on what network owners should do to lock down traffic >emanating from their networks, perhaps by elaborating on various >approaches that may not be as blunt as blocking port 25 (rate >limiting, etc). > >Anything else I can do? > >Cheers - Rand > |
|
2005-06-03
|
08 | Bert Wijnen | Status date has been changed to 2005-06-03 from 2005-05-23 |
|
2005-06-03
|
08 | Bert Wijnen | State Changes to Last Call Requested from AD Evaluation by Bert Wijnen |
|
2005-06-03
|
08 | Bert Wijnen | Last Call was requested by Bert Wijnen |
|
2005-06-03
|
08 | (System) | Ballot writeup text was added |
|
2005-06-03
|
08 | (System) | Last call text was added |
|
2005-06-03
|
08 | (System) | Ballot approval text was added |
|
2005-06-03
|
08 | Bert Wijnen | Positive reviews received from APPS area (Marshall Rose and Rand Wacker). -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Wednesday, May 25, 2005 18:52 … Positive reviews received from APPS area (Marshall Rose and Rand Wacker). -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Wednesday, May 25, 2005 18:52 To: Ted Hardie Cc: Rand Wacker; Scott Hollenbeck; Bert Wijnen Subject: Re: review request for draft-hutzler-spamops On May 25, 2005, at 09:33, Ted Hardie wrote: > Hi Rand, Marshall, > The OPS folks have been handed draft-hutzler-spamops > as a candidate for BCP. I was wondering if you would be willing > to review it and feedback comments to me, Scott and Bert Wijnen? i have reviewed http://www.ietf.org/internet-drafts/draft-hutzler-spamops-04.txt it is more or less to the point. it has nothing objectionable. it codifies a proper subset of the existing practice of many ISPs, so i do not foresee any harm by progressing it as a BCP. /mtr -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Thursday, May 26, 2005 22:20 To: Wijnen, Bert (Bert) Subject: Fwd: Re: Request for review of draft-hutzler-spamops Hi Bert, You've seen Marshall's message by now; here' Rand's. Ted >Cc: Scott Hollenbeck <sah@428cobrajet.net> >From: Rand Wacker <randal@singletrack.org> >Subject: Re: Request for review of draft-hutzler-spamops >Date: Wed, 25 May 2005 17:45:27 -0700 >To: Ted Hardie <hardie@qualcomm.com> >X-QUALCOMM-AV: Sophos AV Testing > >Ted, I reviewed this document this afternoon and find nothing >glaringly dangerous about it. Codifying the need to get rid of open >relays is always good, opening up the submission port is always good. > >I think it would be good if the document suggested a much stronger >stance on what network owners should do to lock down traffic >emanating from their networks, perhaps by elaborating on various >approaches that may not be as blunt as blocking port 25 (rate >limiting, etc). > >Anything else I can do? > >Cheers - Rand > |
|
2005-06-03
|
08 | Bert Wijnen | Status date has been changed to 2005-06-03 from 2005-05-23 |
|
2005-05-23
|
08 | Bert Wijnen | Also requesting a review from the APPS area. |
|
2005-05-23
|
08 | Bert Wijnen | Status date has been changed to 2005-05-23 from 2005-05-10 |
|
2005-05-23
|
08 | Bert Wijnen | State Changes to AD Evaluation from Publication Requested by Bert Wijnen |
|
2005-05-10
|
08 | Bert Wijnen | Writeup received from Dave Crocker on May 5th |
|
2005-05-10
|
08 | Bert Wijnen | Draft Added by Bert Wijnen in state Publication Requested |
|
2005-05-06
|
04 | (System) | New version available: draft-hutzler-spamops-04.txt |
|
2005-03-18
|
03 | (System) | New version available: draft-hutzler-spamops-03.txt |
|
2004-09-16
|
02 | (System) | New version available: draft-hutzler-spamops-02.txt |
|
2004-08-23
|
01 | (System) | New version available: draft-hutzler-spamops-01.txt |
|
2004-03-31
|
00 | (System) | New version available: draft-hutzler-spamops-00.txt |