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

[SM <[e-mail]>]

Hello,

[replying to both Dave and Murray's messages]

At 06:12 16-02-2012, Dave CROCKER wrote:
>Since the class of error codes is officially "Transient Negative 
>Completion" I'm inclined to suggest having the text say "transient 
>(soft) fail".

I'm ok with that.

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

Thanks to Tony Finch for the reminder about sauce.

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

I forgot about that.

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

Ok.  I don't mind if Murray just goes for the /24 to keep matters simple.

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

I'll comment below.

At 10:57 16-02-2012, Murray S. Kucherawy wrote:
>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.

Ok.

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

See comment below.

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


 From RFC 5321:

   "450  Requested mail action not taken: mailbox unavailable (e.g.,
    mailbox busy or temporarily blocked for policy reasons)"

The 450 code is listed for RCPT and end of data 
indicator.  Greylisting fits "policy reason".  I'll suggest using 450 
to keep this separate from non-policy conditions.  That code does not 
fit it for connection establishment as the SMTP server kills the 
connection.  There would have to be some text for the 421 
exception.  I have a strong preference for not encouraging the 421 
(debugging comment) as it is hard to tell whether there is a problem 
or if this is policy stuff.

At 11:15 16-02-2012, Murray S. Kucherawy wrote:
>I think a specific use of a TS to implement a technique falls within 
>the definition of an AS.

An Applicability Statement is about setting or adapting requirement 
levels for a specific use.  I don't think that providing degraded 
service qualifies for it.

>OK, though I think it's a bit odd to make an Informative document 
>into a normative reference.

As it is already in the down-ref registry, there shouldn't be any 
process issue.

Regards,
-sm