Re: IP-based reputation services vs. DNSBL (long)

[Eliot Lear <[e-mail]>]

Keith,
> 1. Would declining to publish as a standard harm or hurt the
>> community?  Would refusing to publish as a standard stop implementations
>> or merely create potential interoperability issues that could lead to
>> more legitimate messages being dropped?
>>      
>
> How are either of these questions relevant to the criteria in RFC 2026?
>    

Since the request to advance in this case is for PS, there is a 
relatively low threshold to move the thing forward, as documented in 
Section 4 of RFC 2026.  Section 6 of RFC 2026 requires the IESG to use 
its collective judgment in reviewing requests for advancement.  I am 
attempting with both questions to provide guidance to the IESG as to how 
to how they might judge.

> The working group could analyze the requirements of a reputation service
> based on IP address, determine whether and how any newly discovered
> requirements could be met using DNS, and fill in any details that are
> missing from the informational specification that are needed for
> reliable and robust interoperation _of the mail transport system_ when
> using DNSxBLs.
>    

That's all rather nebulous, Keith.  You then go on to cite examples 
which in fact are addressed very specifically in the draft, and so I 
suspect they are merely pretenses for what is really irking you, which 
you have stated repeatedly, first in your initial message on this thread:

> Under no circumstances should any kind of Blacklists or Whitelists be
> accepted by IETF as standards-track documents.  These lists are
> responsible for huge numbers of illegitimate delivery failures.  We
> should no more be standardizing such lists than to be standardizing spam.
>    

and then in response to my note:

> My belief is that among the goals of standardizing this practice would
> be:  To improve transparency and accountability of DNSBLs to end users
> over what it is now, to improve security and reduce the potential for
> use of DNSBLs for attack (including both DoS attack and thwarting of
> spam blocking), to improve consistency in reporting between different
> DNSBLs.
>    

And what makes you think a technical standard would do that when it 
never has in the past?  Once again, I think you are overstating the role 
of this organization.  The choices a DNSBL makes to list someone are 
entirely its own.  The choice to use a given DNSBL is entirely that of 
the MTA administrator.  You cannot specify a standard to force a DNSBL 
to disgorge its logic.  When we have tried this in the past we ended up 
with superfluous information undermining confidence in any useful 
information that may be out there.  One need look no further than the 
value of old WKS records.

>
> I hope the IESG will respect our established process, and recognize that
> (a) there are indeed technical omissions in this document, and (b) the
> document as currently written does not have rough consensus of the IETF
> technical community, as shown already by the expressed concerns of
> several contributors to this list.
>    

(a)  You complained about a lack of discussion on TTLs, which is in fact 
in the draft.  You complained about a lack of security considerations, 
which is in fact in the draft, and you complained about TXT records not 
being required, when in fact the draft makes use of a SHOULD.  It is not 
clear to me that a MUST meets the criteria listed in RFC 2119.

(b)  I count three or four very vocal opponents versus an enormous 
installed base.  But even were it more, I would hope the IESG wouldn't 
only use rough consensus to move forward, but also their judgment, for 
which we pay them so much ;-)  And that leads to my questions, which can 
be summed up as follows:

    * Are we better off with or without a proposed standard in this space?
    * Is this document the right document to base that standard on?
    * Is there sufficient benefit to be had by creating a working group?


For the record, my answer to these questions are Yes, Yes, and No.  I 
believe the onus is on those who would want a working group to come up 
with at least a plausible outcome that could improve the document.  Thus 
far I've heard no such thing, and there are risks for delaying 
publication, one of which would be calling into question the IETF's 
relevance.

Eliot

ps: for the astute, we are nearly back to a NAT argument.  The IETF 
version of Godwin's Law may apply.

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf