Email Greylisting: An Applicability Statement for SMTP
draft-ietf-appsawg-greylisting-09
Yes
(Barry Leiba)
No Objection
(Ron Bonica)
(Sean Turner)
(Wesley Eddy)
Note: This ballot was opened for revision 06 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2012-04-25 for -08)
Unknown
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./
Barry Leiba Former IESG member
Yes
Yes
(for -06)
Unknown
Pete Resnick Former IESG member
Yes
Yes
(2012-04-22 for -07)
Unknown
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.
Robert Sparks Former IESG member
Yes
Yes
(2012-04-23 for -08)
Unknown
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
Benoît Claise Former IESG member
No Objection
No Objection
(2012-04-25 for -08)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(2012-04-23 for -08)
Unknown
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.
Martin Stiemerling Former IESG member
(was Discuss)
No Objection
No Objection
(2012-04-26 for -08)
Unknown
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!
Ralph Droms Former IESG member
No Objection
No Objection
(2012-04-26 for -08)
Unknown
Thanks for addressing my comment.
Ron Bonica Former IESG member
No Objection
No Objection
(for -08)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2012-04-24 for -08)
Unknown
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
Sean Turner Former IESG member
No Objection
No Objection
(for -08)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-04-24 for -08)
Unknown
- 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.
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2012-04-24 for -08)
Unknown
Thank you for the explanation.
Wesley Eddy Former IESG member
No Objection
No Objection
(for -08)
Unknown