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

[Dave CROCKER <[e-mail]>]

On 2/15/2012 9:30 PM, SM wrote:
> 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.

should be 'is known as'.


  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.

rejection is the goal that is most discussed, but note that this is also a way 
to slow down incoming mail selectively.


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

Since the class of error codes is officially "Transient Negative Completion" I'm 
inclined to suggest having the text say "transient (soft) fail".


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

Since this is non-normative material, it's generally good to be especially 
inclusive.  Including both your and Tony's citation nicely establishes 
relatively long history for the mechanism.


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

hmm.  the email architecture document uses the term return address and that term 
matches the actual semantics of the address better than the RFC821 label that 
RFC5321 uses.  To add explicit linkage, I'll suggest "the return email address 
(rfc5321.MailFrom)"


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

Although it is unlikely that such topologically diverse 'clusters' will 
demonstrate the kind of hand-off for sending of mail, you are right that it is 
possible. So the text should just add "This heuristic will not work for clusters 
having machines on different networks."


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

DO you have a preference for which value should be recommended?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net