[DNSOP] Also, the irony of a message about censoring being censored

Vernon Schryver <vjs@rhyolite.com> Wed, 21 December 2016 21:19 UTC

Return-Path: <vjs@rhyolite.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDFD1295EE for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 13:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spHAqva4vNB5 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 13:19:16 -0800 (PST)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D419F1295C4 for <dnsop@ietf.org>; Wed, 21 Dec 2016 13:19:15 -0800 (PST)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id uBLLJ1UP058933 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Wed, 21 Dec 2016 21:19:01 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id uBLLJ1o6058932 for dnsop@ietf.org; Wed, 21 Dec 2016 21:19:01 GMT
Date: Wed, 21 Dec 2016 21:19:01 +0000
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201612212119.uBLLJ1o6058932@calcite.rhyolite.com>
To: dnsop@ietf.org
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Oz_Sk2MH3fiMmpCVAtlZ0K-tH5s>
Subject: [DNSOP] Also, the irony of a message about censoring being censored
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2016 21:19:20 -0000

> From: Paul Wouters <paul@nohats.ca>

> So my message to the dnsop list which also was sent to Vernon Schryver
> just got bounced back to me. The Irony.
> 
> Luckilly, there was a URL in there instead of just an RPZ policy number
> encoded in a serial number, so I could look up the reason for this
> block:
> 
>  	The DCC Reputation database has reports of 201 mail messages in the
>  	last 30 days from mx.nohats.ca [193.110.157.68], of which 94 were bulk,
>  	for a DCC Reputation of 46%.
> 
> It seems this system has concluded that my nohats.ca domain is an active
> participant on many email lists, and therefor I must be a spammer?
> 
> Censorship tools are often misused or badly configured. It is important
> that we see more than BOGUS answer or a SERVFAIL for those who want to
> figure out what the outage is and how to fix it.

- For about 24 hours ending well before Paul Wouters sent copies his
   message, I had misconfigured experimental RPZ+mail code.  I've
   looked through logs, but found no rejected RPZ related messages
   that were not duplicated in this mailing list.  If I missed any, I
   hope they'll be retransmitted.

- Those RPZ SOA RRs contain more than a policy/serial number.

- Spam is unsolicited bulk mail, but not all bulk mail is spam.  

- As far as I know, Paul Wouters has not been censored, not even
   at Rhyolite Software, LLC, except perhaps in the sense that I saw
   nothing in his messages that required a response from me.

- Sending individual submissions to a mailing list does not give an IP
   address a DCC Reptuation for bulk mail.  It's the reflector that gets
   the DCC Reputation.

- DCC Reputation data is discarded after 30 days and heavily compressed
   after a day, so I can only say that 193.110.157.68 sent a total of 94
   bulk but not necessarily unsolicited messages to systems using DCC
   Reputations on 12/03, 12/05, 12/08, 12/15, 12/17, and 12/18.

- I don't want duplicate copies of public mailing list messages.
   If I'm too stupid to understand the first time, then I'm unlikely
   to figure out a duplicate copy.  I've also seen confusion and
   hard feelings result from long delays through IETF reflectors
   and "courtesy" copies, as the private halves of pubic/private
   dicussions race ahead and other participants feel cut out.

> ...
> If the goal is to block the answer, I think it would be much better to
> move the original Answer RRTYPE into the Authority Section and use an
> ENDS0 bit to signal RPZ was applied. That way, clients that understand
> RPZ can see the censored results and do smart things - including ignoring
> or accepting the censor - and clients that do not support understanding
> RPZ will still be prevented from seeing the censored results for their
> security.
> 
> Possibly an additional RRTYPE with a URL to a page explaining the
> ...

I have nothing to say about those proposals except to observe that
are irrelevant to the current RPZ draft.


Vernon Schryver    vjs@rhyolite.com