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

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave CROCKER
> Sent: Thursday, February 16, 2012 6:13 AM
> To: SM
> Cc: [e-mail]
> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03
> 
> > The last sentence seems incomplete.
> 
> should be 'is known as'.

Fixed.

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

In line with Tony's suggestion, I've removed the text alleging that this goal of greylisting is "less well-developed".  In my experience, though, it's not "the" reason people deploy greylisting these days, hence that language.

I think I prefer the current section ordering.  The Introduction lays out the general subject area, and then the Background starts presenting the "how'd we get here?" material.

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

Done.

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

Done.

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

How does that impede debugging?  A server that doesn't go the 421 route is not guaranteed to give you more information.

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

Done, and fixed "recipients".

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

Done.

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

My point there is actually to say there's no effective difference between 421 and any other 4yz in this context.  But that said, I'd be happy to discuss suggestions others might have.

What about saying 421 for sites that want to kill the connection immediately, and 450 otherwise?

-MSK