Rbldns for text and data
Fri Jan 11 11:39:40 CET 2019
On Thu 10/Jan/2019 21:02:51 +0100 Denny Watson via dev wrote:
>>> Had it asked for ANY, it would know how to handle (or at least look for
>>> things that it could handle) in the response.
>> Yes. However, ANY is going to be deprecated:
>> (That's still a draft but it made enough noise already.)
Now it's an RFC. See attachment.
> I haven't been following this discussion, but reviewing the document
> suggests that QTYPE ANY isn't being removed from the protocol, it's just
> that you shouldn't expect it to be available when the requests hit the
> final system authoritative for the labels you query, or if it is
> available it might not contain the specific types that you might find
> interesting. This is dependent on that remote system's configuration.
You seem to be right. It'd be nice if someone will say what DNSxLs are
supposed to do, typically return A + TXT on ANY. Anyway, it seems that
omitting ANY was a premature decision of the MTA implementor. Thank you for
> Having said all of that, I want to make sure that I understand your use
> case. Assumptions follow;
> Your MTA is using A record responses to make filtering decisions -- this
> is normal, and I would suggest the more proper way of doing this. QTYPE
> A records tend to be better suited for this than TXT records.
> Your MTA is using TXT records for SMTP textual responses, or even for
> the log files.
The MTA can accept a whitelisted message even if configured to
reject-on-SPF-fail. It then adds the dnswl record to the message header, like so:
Had a TXT record been found, the header field would also have had:
Almost always that information is redundant. In this case, for example, I
already have this:
Received: from attila.bofh.it (attila.bofh.it [126.96.36.199])
by wmail.tana.it with ESMTPS; Thu, 10 Jan 2019 21:02:58 +0100
However, sometimes the Received: is obscure, and there's no PTR, so that one
cannot tell what domain is responsible for the message. In such cases,
policy.txt tells the domain name. That feature makes a successful dnswl lookup
semantically equivalent to other email authentication methods, such as SPF and
(The above Authentication-Results: field is not (yet) mentioned in the IANA
Email Authentication Parameters[*], because of the "dns.zone" which should have
been named something like "policy.zone" according to rfc7601. I'll try again
after rfc7601bis will have been published.)
> In the past, when I was managing MTAs, I didn't return the DNSBL's TXT
> responses via SMTP and instead returned URLs for my own "postmaster"
> webpage with a CGI flagged IP. This was another lifetime ago, and I
> would do silly things like reject only if on List-A and List-B, or
> List-C but not List-D, and it was easier to explain it all and provide a
> separate white-listing process for my systems outside of the reputation
> providers (DNSBLs).
I find it useful to outsource also whitelisting.
-------------- next part --------------
An embedded message was scrubbed...
Subject: RFC 8482 on Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
Date: Thu, 10 Jan 2019 18:23:34 -0800 (PST)
More information about the dev