Re: draft-kucherawy-greylisting-bcp

On 10/26/11 10:42 AM, Dave CROCKER wrote:
> On 10/26/2011 5:33 PM, Pete Resnick wrote:
> > On 10/26/11 10:18 AM, Dave CROCKER wrote:
> > > Greylisting is not a protocol, according to any definition I know.
> > >
> > > There is no way to test "interoperability".
> > Rubbish. I can assure you that if someone implemented greylisting in 
> > such a way
> > that "legitimate" mail stopped being delivered, because they set the 
> > greylist
> > timeout too long or...
> You have just defined an interoperability criterion that includes all 
> sources of software misbehavior, daemon sleep times, and anything else 
> that can cause delays.
I notice you conveniently snipped my example of using a status code that 
caused trouble. But yes, timeouts are commonly put into standards track 
documents, and reasonably so. Implementation parameters do cause 
interoperability problems and many of those are observable from the net. 
I have no idea how you can claim these aren't "interoperability criteria".
Let's go back to my initial claims: If it implementation experience 
would cause changes to the instructions we give in a document to 
implementers, then it deserves to be on the standards track. If it's a 
"protocol, service, procedure, convention, or format" [2026, 3.1], it 
belongs in a technical specification. If it gives implementation 
instructions (values for parameters, how the protocol ought be 
implemented, etc.), then it belongs in an applicability statement. Both 
TSs and ASs go on the standards track.
> > Greylisting is far more obviously a protocol with testable 
> > interoperability than is, say, RFC 5234 or 5322.
[To clarify: I am not committed to greylisting being a protocol. I'm 
just saying it looks more like a protocol than do 5234 or 5322. It is 
the claim that there is no way to test interoperability that I reject..]
> 5322 and other format specs explicitly entail parsing and processing 
> (and in the case of From: and Reply-to:, replying) by the remote 
> engine.  That's essential interoperability.
How does one "test interoperability" in the case of parsing that is 
going on in a local implementation like 5322? How is that different than 
greylisting? And for ANBF...?
> In other words, formats are inherently bilateral.  Greylisting is 
> unilateral.
Formats are bilateral, but only in the sense that both sides have a 
common understanding of the semantics of the parsed format. Greylisting 
is bilateral for those who actually participate: That is, if I receive 
4xx status code, I know to wait a while and resend. Successful delivery 
happens if we both do our parts correctly. It is certainly the case that 
if I am a poorly implemented SMTP client, I will not try again and my 
mail will not be delivered (the point of the greylisting), but surely 
greylisting still "specifies how, and under what circumstances" SMTP is 
"applied to support a particular Internet capability".  [2026, 3.2]
> The interoperability mechanism relevant to greylisting is the 
> /existing/ set of SMTP mechanisms.  Greylisting is an indirect 
> invocation of those mechanisms.
I agree. See 2026, section 3.2.

> Again:  since my view is rubbish, please define an interoperability 
> test for it.
(I don't think I am making any statement about *your* *view*. I 
apologize for this coming across as a personal attack. I used "rubbish" 
only to mean, "I strongly disagree with the statement that there is no 
way to test interoperability". I certainly did not intend any offense.)
Again, please re-read the sections of 2026 regarding ASs. The 
interoperability test is against SMTP, not greylisting itself. 
Greylisting is a way of implementing SMTP with certain outcomes. If 
implementation choices turn out to be wrong (which we can determine by 
testing the interoperability of SMTP implementations that use 
greylisting), we update the AS describing greylisting. That's what the 
standards track is all about.
pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102