Email Greylisting: An Applicability Statement for SMTP
RFC 6647

Note: This ballot was opened for revision 06 and is now closed.

(Adrian Farrel) Yes

Comment (2012-04-25 for -08)
No email
send info
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 Yes

(Pete Resnick) Yes

Comment (2012-04-22 for -07)
No email
send info
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) Yes

Comment (2012-04-23 for -08)
No email
send info
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

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-04-24 for -08)
No email
send info
Thank you for the explanation.

(Benoît Claise) No Objection

Comment (2012-04-25 for -08)
No email
send info
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.

(Ralph Droms) No Objection

Comment (2012-04-26 for -08)
No email
send info
Thanks for addressing my comment.

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2012-04-24 for -08)
No email
send info
- 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.

(Brian Haberman) No Objection

Comment (2012-04-23 for -08)
No email
send info
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.

(Russ Housley) No Objection

Comment (2012-04-24 for -08)
No email
send info
  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

(Martin Stiemerling) (was Discuss) No Objection

Comment (2012-04-26 for -08)
No email
send info
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!

(Sean Turner) No Objection