Keith Moore wrote:
One 'interesting' aspect of an interop test for greylisting is that it would
only affect servers. Greylisting is supposed to be backward compatible with
standards-conforming clients. What you would want to establish via
interoperability testing is that a server that implements greylisting per the
RFC doesn't degrade interoperability with existing, properly-implemented,
clients.
I don't have a strong opinion of BCP vs. standards-track for this. I think
that if it's desirable to publish an RFC on this topic (which I doubt), either
BCP or PS would suffice. But I do think that if it's going to be published as
PS, the document needs to define testing criteria for advancement.
The only factor I see that can come close to degrade testing idea:
- a compliant MTA does retry per SMTP, but
- before the Greylisting blocking time.
A key issue, if you need a reminder is the blind MTA world of varying
degrees in blocking times and this is why we need a mechanical
client/server automaton as oppose to a BCP which will end up being
most likely a subjective "Rough Concensus" of the stronger IETF keys
and participants making a "Best for all world" compromise offering of
TIME that will not resolve the central issue:
BCP TIME < GL Blocking Time => wasted attempts
BCP TIME > GL Blocking Time => Delayed deliveries.
This has long been measured and of recent measure with internal
testing of the proposal showing the proof of concept has been a 100%
success in achieving a minimum of 2 attempts at precisely the delay
time the server suggested.
--