Email Greylisting: An Applicability Statement for SMTP
draft-ietf-appsawg-greylisting-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-05-01
|
09 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-04-30
|
09 | (System) | IANA Action state changed to No IC from In Progress |
2012-04-30
|
09 | (System) | IANA Action state changed to In Progress |
2012-04-30
|
09 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-04-30
|
09 | Amy Vezza | IESG has approved the document |
2012-04-30
|
09 | Amy Vezza | Closed "Approve" ballot |
2012-04-30
|
09 | Amy Vezza | Ballot approval text was generated |
2012-04-26
|
09 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation |
2012-04-26
|
09 | Murray Kucherawy | New version available: draft-ietf-appsawg-greylisting-09.txt |
2012-04-26
|
08 | Martin Stiemerling | [Ballot comment] Agreed with the authors to replace bullet 2 in Section 5 with this text: 2. Include a configurable time window within which … [Ballot comment] Agreed with the authors to replace bullet 2 in Section 5 with this text: 2. Include a configurable time window within which a retry from a greylisted host is considered, and ignored otherwise. The time window needs to be configured to contain typical retry times of common MTA configurations, thus anticipating that a fully-capable MTA will retry sometime after the beginning of the window and before the end of it. The default window SHOULD range from one minute to 24 hours. Retries during the period of this window are permitted and satisfy the greylisting test, and thus the client is no longer likely to be a sender of spam; retries after the end of the window SHOULD be considered to be a new message for the purposes of greylisting evaluation (i.e., reset the "first seen" timestamp for that IP address). Some sites use a higher time value for the low end of the window time to match common legitimate MTA retry timeouts, but additional benefit from doing so appears unlikely. Thanks for the fast responses! |
2012-04-26
|
08 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
2012-04-26
|
08 | Martin Stiemerling | [Ballot comment] Agreed with the authors to replace bullet 2 in Section 5 with this text: 2. Include a configurable time window within which … [Ballot comment] Agreed with the authors to replace bullet 2 in Section 5 with this text: 2. Include a configurable time window within which a retry from a greylisted host is considered, and ignored otherwise. The time window needs to be configured to contain typical retry times of common MTA configurations, thus anticipating that a fully-capable MTA will retry sometime after the beginning of the window and before the end of it. The default window SHOULD range from one minute to 24 hours. Retries during the period of this window are permitted and satisfy the greylisting test, and thus the client is no longer likely to be a sender of spam; retries after the end of the window SHOULD be considered to be a new message for the purposes of greylisting evaluation (i.e., reset the "first seen" timestamp for that IP address). Some sites use a higher time value for the low end of the window time to match common legitimate MTA retry timeouts, but additional benefit from doing so appears unlikely. |
2012-04-26
|
08 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2012-04-26
|
08 | Ralph Droms | [Ballot comment] Thanks for addressing my comment. |
2012-04-26
|
08 | Ralph Droms | Ballot comment text updated for Ralph Droms |
2012-04-25
|
08 | Ralph Droms | [Ballot comment] Thanks to Benoit for asking me about the effect of DHCP, which prompted this comment: It might be worth mentioning that changes in … [Ballot comment] Thanks to Benoit for asking me about the effect of DHCP, which prompted this comment: It might be worth mentioning that changes in the IP address assigned to the MTA may trigger false positive greylisting; e.g., if service provider changes the IP address assigned to the WAN interface of a NAT. |
2012-04-25
|
08 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-04-25
|
08 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-04-25
|
08 | Adrian Farrel | [Ballot comment] I strongly support this effort which draws a line between blacklisting and more acceptable techniques. I hope this will serve as encouragement to … [Ballot comment] I strongly support this effort which draws a line between blacklisting and more acceptable techniques. I hope this will serve as encouragement to service providers to move away from descriminatory and service-impacting blacklists. --- Section 1 s/for provider better service./for providing better service./ |
2012-04-25
|
08 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2012-04-25
|
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-04-25
|
08 | Benoît Claise | [Ballot comment] Please expand MTA. I know that you wrote: "Readers need to be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]." … [Ballot comment] Please expand MTA. I know that you wrote: "Readers need to be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]." We could help the reader a little bit, instead of searching into http://tools.ietf.org/html/rfc5598 to know what the acronym means Similarly, maybe it's obvious for people dealing with Email, but I had to lookup "MX record" ... OLD: Experience suggests that the, the vast majority of mail comes from NEW Experience suggests that the vast majority of mail comes from Regards, Benoit. |
2012-04-25
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-04-24
|
08 | Stewart Bryant | [Ballot comment] Thank you for the explanation. |
2012-04-24
|
08 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2012-04-24
|
08 | Stephen Farrell | [Ballot comment] - intro: "a period of time" is usually measured in minutes here, might be worth saying that just in case - 2.3: Odd … [Ballot comment] - intro: "a period of time" is usually measured in minutes here, might be worth saying that just in case - 2.3: Odd reference text: "refers to the [SMTP] command verb" I think it'd be better if the reference was handled differently and e.g. it said "refers to the 'SMTP' command verb in an SMTP [SMTP] session" (I prefer if the references are not part of the text but that's a different style issue). The "RFC5321.MailFrom" notation also shows as a reference on the tools page, not sure if that's desirable or not or if it can be avoided or not. - typo, section 3, s/the, the/the/ - section 5: Are there any 4yz errors that SHOULD NOT or MUST NOT be used here? I've no idea and suspect not based on this text, but if there were then that'd be worth saying. |
2012-04-24
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-04-24
|
08 | Russ Housley | [Ballot comment] Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 23-Apr-2012. The review can be found at: … [Ballot comment] Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 23-Apr-2012. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07382.html |
2012-04-24
|
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-04-24
|
08 | Martin Stiemerling | [Ballot discuss] Section 5. point 2: The minimum default window is one minute. This seems to be rather short in respect of clock skew between … [Ballot discuss] Section 5. point 2: The minimum default window is one minute. This seems to be rather short in respect of clock skew between different hosts and when messages are re-scheduled for delivery on hosts. Has this been tested/checked in real deployments. One example: This can be troublesome if the SMTP server which does the greylisting is +30 seconds off and the other end is off by -30 seconds. The other end will re-send the message just too late. |
2012-04-24
|
08 | Martin Stiemerling | Ballot discuss text updated for Martin Stiemerling |
2012-04-23
|
08 | Kathleen Moriarty | Request for Telechat review by GENART No Response. Reviewer: Kathleen Moriarty. |
2012-04-23
|
08 | Robert Sparks | [Ballot comment] This is a very clear and helpful document. Thank you for making the effort to assemble it. Greylisting has been widely deployed for … [Ballot comment] This is a very clear and helpful document. Thank you for making the effort to assemble it. Greylisting has been widely deployed for several years, but a concise explanation of the concept and its consequences has been lacking - this will be a very good tool for administrators interacting with systems that are already greylisting as well as those that are just adopting the practice. I don't agree that this should be BCP - it seems a good candidate for re-review and progression on the standards ladder. (Updating the comment with this question/suggestion:) In the second paragraph of section 3, consider pointing to the sentence in section 2.1 of RFC5321 that says "SMTP clients that transfer all traffic regardless of the target domains associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable." and say more strongly here that the agent receiving this retry response can't distinguish this condition from a disk full or other temporary condition making the receiver unable to accept where the sender really has no business knowing the reason why it's being told to re-try with a 400-level response |
2012-04-23
|
08 | Robert Sparks | Ballot comment text updated for Robert Sparks |
2012-04-23
|
08 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-04-23
|
08 | Robert Sparks | [Ballot comment] This is a very clear and helpful document. Thank you for making the effort to assemble it. Greylisting has been widely deployed for … [Ballot comment] This is a very clear and helpful document. Thank you for making the effort to assemble it. Greylisting has been widely deployed for several years, but a concise explanation of the concept and its consequences has been lacking - this will be a very good tool for administrators interacting with systems that are already greylisting as well as those that are just adopting the practice. I don't agree that this should be BCP - it seems a good candidate for re-review and progression on the standards ladder. |
2012-04-23
|
08 | Robert Sparks | [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks |
2012-04-23
|
08 | Stewart Bryant | [Ballot discuss] In reading this document I was left wondering whether the cure was not worse than the disease. Certainly there were a number of … [Ballot discuss] In reading this document I was left wondering whether the cure was not worse than the disease. Certainly there were a number of downsides that impacted the innocent user, thus it was not clear why this was Standards Track and not Experimental, at least until the wider community understood the impact of deployment. |
2012-04-23
|
08 | Stewart Bryant | [Ballot comment] It also struck me that in the arms race with the spammers this would likely be circumvented if it proved in any way … [Ballot comment] It also struck me that in the arms race with the spammers this would likely be circumvented if it proved in any way initially effective. |
2012-04-23
|
08 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2012-04-23
|
08 | Brian Haberman | [Ballot comment] This is a well-written document and describes a useful function. I do support Martin's DISCUSS about the status. It definitely reads like a … [Ballot comment] This is a well-written document and describes a useful function. I do support Martin's DISCUSS about the status. It definitely reads like a BCP. |
2012-04-23
|
08 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-04-23
|
08 | Martin Stiemerling | [Ballot discuss] - I'm not sure that this draft is really for 'Proposed Standard', as after reading it, it looks to me more like Best … [Ballot discuss] - I'm not sure that this draft is really for 'Proposed Standard', as after reading it, it looks to me more like Best Current Practices. The abstract hints to it: "This memo describes the art of email greylisting, the practice of ..." - A question for clarification: Section 5. point 2: The minimum default window is one minute. This seems to be rather short in respect of clock skew between different hosts and when messages are re-scheduled for delivery on hosts. Has this been tested/checked in real deployments |
2012-04-23
|
08 | Martin Stiemerling | [Ballot comment] - Section 1: "this can justify providing degraded service, until there is a basis for provider better service." I cannot parse the … [Ballot comment] - Section 1: "this can justify providing degraded service, until there is a basis for provider better service." I cannot parse the 'provider better service'. - Section 5: The text before the list of practices says those items are RECOMMENDED, but a number of items is about SHOULD and SHOULD NOT. Not a big issues, but logically not clean, i.e., are they RECOMMENDED or does SHOULD apply. Probably, it might be good to have two lists, one for RECOMMENDED and the other for the SHOULDs. |
2012-04-23
|
08 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2012-04-22
|
08 | Murray Kucherawy | New version available: draft-ietf-appsawg-greylisting-08.txt |
2012-04-22
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Donald Eastlake. |
2012-04-22
|
07 | Pete Resnick | [Ballot comment] 2.5 Some implementations do filtering here I think you meant, "Some implementations do greylisting here". There's no filtering described in this section. … [Ballot comment] 2.5 Some implementations do filtering here I think you meant, "Some implementations do greylisting here". There's no filtering described in this section. o identifiers in the message, such as the contents of the RFC5322.From or RFC5322.To fields; Change "message" to "message header" or "message content" or equivalent. I think there is the potential to confuse envelope here. 2.6 I think you mean "spam", or maybe "spam senders", but not "spamware" in this paragraph. There is nothing about an IP address that identifies spamware, but it certainly might identify a sender of spam. 4.2 Some clients do not retry messages at all. and Some SMTP implementations make the error of treating all error codes as fatal; I think it's worth adding "in violation of [SMTP]". It should be clear that you are only losing email from clients that are already not playing by the rules. |
2012-04-22
|
07 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2012-04-19
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Kathleen Moriarty |
2012-04-19
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Kathleen Moriarty |
2012-04-17
|
07 | Murray Kucherawy | New version available: draft-ietf-appsawg-greylisting-07.txt |
2012-04-13
|
06 | Barry Leiba | Ballot writeup was changed |
2012-04-13
|
06 | Barry Leiba | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-13
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-04-10
|
06 | Pearl Liang | IESG: IANA has reviewed draft-ietf-appsawg-greylisting-06.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any … IESG: IANA has reviewed draft-ietf-appsawg-greylisting-06.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. |
2012-04-05
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Kathleen Moriarty |
2012-04-05
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Kathleen Moriarty |
2012-04-03
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2012-04-03
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2012-03-31
|
06 | Barry Leiba | PROTO writeup: The Applications Area Working Group (appsawg) requests the publication of draft-ietf-appsawg-greylisting as a Proposed Standard Applicability Statement. (1) What type of RFC is … PROTO writeup: The Applications Area Working Group (appsawg) requests the publication of draft-ietf-appsawg-greylisting as a Proposed Standard Applicability Statement. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The title and header describe the document as an Applicability Statement and a Standards Track document, respectively. The document describes how to apply the SMTP protocol for a specific use case. The document started life as a BCP, but seemed to fit better as an AS. One participant mildly objected to the change, thinking that this doesn't fit the meaning of AS. The sense is that AS is the right approach, but there wasn't a lot of discussion on the point. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Preferred techniques for handling email abuse explicitly identify good actors and bad actors, giving each significantly differential service. In some cases an actor does not have a known reputation; this can justify providing degraded service, until there is a basis for provider better service. This latter approach is known as "greylisting". Broadly, the term refers to any degradation of service for an unknown or suspect source, over a period of time. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was nothing of note. Because this is documenting existing practice, there was broad agreement no real debate about the technical details. Document development was mostly a matter of wordsmithing and clarifying, to make sure the text was accurate and complete. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This technique is quite widely implemented, and has been discussed in the community for some time. This is documenting that implementation, demonstrating how to apply SMTP to this use case. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has had good review from the community, and is ready for publication. The shepherd has reviewed it and has no issues with it. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document describes existing usage of SMTP in a specific usage scenario. I expect and welcome the usual SecDir review. I also encourage an OpsDir review, though no significant operational problems have occurred as this technique has been in use in the field. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? 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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. There are no IPR disclosures related to this document, and no one involved with the document is aware of any issues in this regard. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. See 7. (9) 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 working-group consensus is solid. The email community consensus is likewise solid, and quite broad. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? None. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There is a normative reference to RFC 5598 (Internet Mail Architecture), an Informational document. It is in the downref registry. (16) Will publication of this document change to the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any other document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). No actions are requested of IANA, and the IANA Considerations section says so. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language is used in this document. |
2012-03-31
|
06 | Barry Leiba | Placed on agenda for telechat - 2012-04-26 |
2012-03-31
|
06 | Barry Leiba | Ballot has been issued |
2012-03-31
|
06 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-03-31
|
06 | Barry Leiba | Created "Approve" ballot |
2012-03-31
|
06 | Barry Leiba | Ballot writeup was changed |
2012-03-30
|
06 | Cindy Morgan | Last call sent |
2012-03-30
|
06 | Cindy Morgan | State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Email Greylisting: An Applicability Statement for SMTP) to Proposed Standard The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Email Greylisting: An Applicability Statement for SMTP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-03-30
|
06 | Barry Leiba | Last call was requested |
2012-03-30
|
06 | Barry Leiba | Last call announcement was generated |
2012-03-30
|
06 | Barry Leiba | Ballot approval text was generated |
2012-03-30
|
06 | Barry Leiba | Ballot writeup was generated |
2012-03-30
|
06 | Barry Leiba | Shepherd writeup is in the tracker. |
2012-03-30
|
06 | Barry Leiba | State changed to Last Call Requested from AD is watching |
2012-03-30
|
06 | Barry Leiba | Changed protocol writeup |
2012-03-30
|
06 | Alexey Melnikov | Changed protocol writeup |
2012-03-30
|
06 | Alexey Melnikov | IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2012-03-29
|
06 | Alexey Melnikov | I verified that my shepherd review comments were addressed and I am now requesting IESG processing. |
2012-03-29
|
06 | Barry Leiba | Responsible AD changed to Barry Leiba from Pete Resnick |
2012-03-25
|
06 | Murray Kucherawy | New version available: draft-ietf-appsawg-greylisting-06.txt |
2012-03-23
|
05 | Barry Leiba | Changed shepherd to Alexey Melnikov |
2012-03-23
|
05 | Barry Leiba | IETF state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2012-03-09
|
05 | Barry Leiba | Changed protocol writeup |
2012-03-09
|
05 | Barry Leiba | IETF state changed to In WG Last Call from WG Document |
2012-03-09
|
05 | Barry Leiba | WGLC ended, changing shepherd to Alexey |
2012-03-09
|
05 | Barry Leiba | WGLC ends 23 March |
2012-03-09
|
05 | Barry Leiba | Changed shepherd to Barry Leiba |
2012-02-22
|
05 | (System) | New version available: draft-ietf-appsawg-greylisting-05.txt |
2012-02-17
|
04 | (System) | New version available: draft-ietf-appsawg-greylisting-04.txt |
2012-02-15
|
03 | (System) | New version available: draft-ietf-appsawg-greylisting-03.txt |
2012-02-04
|
05 | Pete Resnick | Draft added in state AD is watching |
2012-01-31
|
02 | (System) | New version available: draft-ietf-appsawg-greylisting-02.txt |
2012-01-20
|
01 | (System) | New version available: draft-ietf-appsawg-greylisting-01.txt |
2011-12-06
|
00 | (System) | New version available: draft-ietf-appsawg-greylisting-00.txt |