[Top] [All Lists]

Re: draft-kucherawy-greylisting-bcp

2011-10-26 11:29:15

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.


Pete Resnick<>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102