> From: Paul Wouters <[email protected]> > 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 protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
