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.
Paul
---------- Forwarded message ----------
Date: Wed, 21 Dec 2016 14:01:48
From: Mail Delivery System <[email protected]>
To: [email protected]
Subject: Undelivered Mail Returned to Sender
This is the mail system at host mx.nohats.ca.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<[email protected]>: host smtp.rhyolite.com[192.188.61.3] said: 550 5.7.1
uBLJ1kL1091512 bulk mail reputation; see
https://commercial-dcc.rhyolite.com/cgi-bin/reps.cgi?tgt=193.110.157.68 (in
reply to end of DATA command)Reporting-MTA: dns; mx.nohats.ca
X-Postfix-Queue-ID: 3tkPBw2xRCzG1V
X-Postfix-Sender: rfc822; [email protected]
Arrival-Date: Wed, 21 Dec 2016 20:01:28 +0100 (CET)
Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;[email protected]
Action: failed
Status: 5.7.1
Remote-MTA: dns; smtp.rhyolite.com
Diagnostic-Code: smtp; 550 5.7.1 uBLJ1kL1091512 bulk mail reputation; see
https://commercial-dcc.rhyolite.com/cgi-bin/reps.cgi?tgt=193.110.157.68
--- Begin Message ---
On Wed, 21 Dec 2016, Vernon Schryver wrote:
As I wrote on Monday, the final paragraph of section 6 on page 18 of
https://tools.ietf.org/html/draft-vixie-dns-rpz-04
says:
If a policy rule matches and results in a modified answer, then that
modified answer will include in its additional section the SOA RR of
the policy zone whose rule was used to generate the modified answer.
This SOA RR includes the name of the DNS RPZ and the serial number of
the policy data which was connected to the DNS control plane when the
answer was modified.
It's not signed, but perhaps it could be with look-asside trust anchors,
although an ever growing forest of DLVs doesn't sound good to me.
Browsers and other interested applications would have to do more than
gethostbyname() or a modern equivalent to see those SOAs. But if
browsers ever do any DANE, they'll need to do more than gethostbyname().
(perhaps that "will include" should be "MUST include")
If the goal is to block the query, I think this is fine. I would prefer
a signed response of any kind as a marker we can keep to hold the
resolver operator accountable for their blocking actions.
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
censorship would be useful to standarize as well. Having a "serial
number" of a policy is not very helpful for a user to hold an operator
responsible. It is important that we know the reason, as we've seen
many filter software doing things like filtering out the EFF or ACLU as
"porn site".
The important issue here is that DNS filtering is done for many valid
and invalid reasons. It is important that we give the consumers the
tools to see the difference. I'm fine with non-updated software/users
that cannot tell the difference to be blocked as-is for their
protection.
Paul
--- End Message ---
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
