Skip to main content

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

Draft-08 was submitted and should show up soon in the repository. The draft is available at http://bbiw.net/recent.html#spamops.' added …
[Note]: 'Dave Crocker is the PROTO shepherd.

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:

   

The modifications are …
A revised version of the draft-hutzler-spamops draft has been submitted to the I-D mechanism.

Various formats are now available at:

   

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
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'
   
    as a BCP RFC

    This …
Proto write-up from PROTO shepherd Dave Crcker

Request:

  'Email Submission: Access and Accountability'
   
    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
    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'
   
    as a BCP RFC

    This …
Proto write-up from PROTO shepherd Dave Crcker

Request:

  'Email Submission: Access and Accountability'
   
    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
    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.''
' 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
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
>From: Rand Wacker
>Subject: Re: Request for review of draft-hutzler-spamops
>Date: Wed, 25 May 2005 17:45:27 -0700
>To: Ted Hardie
>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
>From: Rand Wacker
>Subject: Re: Request for review of draft-hutzler-spamops
>Date: Wed, 25 May 2005 17:45:27 -0700
>To: Ted Hardie
>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