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

From: Vernon Schryver <[email-masked]>
Date: Wed, 21 Dec 2016 21:19:01 GMT

> From: Paul Wouters <[email-masked]>

> 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    [email-masked]