[apps-discuss] Comments on draft-ietf-appsawg-greylisting-03

[SM <[e-mail]>]

Hi Murray,

Here are some comments on draft-ietf-appsawg-greylisting-03.  The 
title of the document is "An Applicability Statement for SMTP".  If 
we ignore that greylisting is a antispam technique that reuses one of 
the properties of SMTP, that might be appropriate.

In Section 1:

   '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 known as
    "greylisting".'

The last sentence seems incomplete.  The above is one way to look at 
greylisting.  Another way would be to describe the SMTP angle which 
is to relying on SMTP retries to "reject" mail delivery on the first 
try if the SMTP client is not known to the SMTP server.  That is 
mentioned in Section 1.1.  I suggest having the Background Section first.

   'Greylisting exploits this by rejecting  mail from unfamiliar
    sources with a "soft fail" (4xx) [SMTP] error code'

"soft fail" is an euphemism of Section 4.2.1 of RFC 5321. 
:-)  maemuki ni kento sasete itadakimasu.

  'Another, less well-developed, application of greylisting is
   to delay mail from newly seen IP addresses on the theory that, if
   it's a spam source, then by the time it retries, it will appear in a
   list of sources to be filtered, and the mail will not be accepted.'

This is actually one of the first and well-developed application of 
greylisting (see 
http://projects.puremagic.com/greylisting/whitepaper.html ).  I 
recommend adding a reference to the paper as the author proposed the technique.

Section 2.l is titled "Connection-level greylisting".  This technique 
is used by a well-known provider.  It makes debugging difficult as 
421 is a forced shutdown when the SMTP service is unavailable.

Section 2.4 mentions "the return email address" for the tuple.  RFC 
5321 uses the term "reverse-path".  BTW, instead of "other 
recipients", you could use "recipients".

I don't know about the effects of "greylisting" in response to 
DATA.  In Section 2.5, the dot could be referred to as the end of 
mail data indicator.

In Section 3:

   "The most obvious benefit with any of the above techniques is that
    spamware does not retry, and is therefore less likely to succeed,
    absent a record of a previous delivery attempts."

Some "spamware" do retry nowadays.

In Section 4.2, I suggest using "SMTP client" instead of "client".

In Section 5:

   "To accommodate those senders that have clusters of outgoing mail
    servers, greylisting servers MAY track CIDR blocks of a size of
    its own choosing, such as /24, rather than the full IP address."

As a note, there are some odd cases where mail from the cluster may 
come from outside a /24 (IPv4).  I suggest mentioning that it's the 
full IPv4 address.

   " There is no specific recommendation as to the specific choice of 4yz
    code to be returned as a result of a greylisting delay."

I prefer a recommendation about the choice of code as this is a 
policy reason (see Section 4.2.2 and 4.3.2 of RFC 5321).

RFC 5598 should be a normative reference as it is mentioned in Section 1.2.2.

The draft is well-written.  It is ready for a Last Call.

Regards,
-sm