John Levine wrote:
For instance, what would happen if mail servers provided feedback to
both senders (on a per message basis in the form of NDNs)
Well, since 95% of all mail is spam, and all the spam has fake return
addresses, you'd increase the amount of bogus NDNs by more than an
order of
On Thu, 13 Nov 2008, Ted Hardie wrote:
That's an example in which an A record in this zone has the standard DNS
meaning and the expectation is that you can use it construct a URI.
The other A records have a specific meaning in which the data returned
indicates that indicates something about
The whole approach here is An A record in this zone has a meaning
different from the meaning in other zones. That creates a DNS
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the types of
requests/responses.
Didn't that plan go
From: Tony Finch [EMAIL PROTECTED] On Behalf Of Tony Finch [EMAIL PROTECTED]
Sent: Friday, November 14, 2008 4:11 AM
To: Hardie, Ted
Cc: Andrew Sullivan; ietf@ietf.org
Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was
several
On Fri, 14 Nov 2008, Hardie, Ted wrote:
Since you now have two different meanings for what an A record is, you
now need two different code trees that understand what A records are,
and those code trees are not interoperable.
What do you mean by interoperable here? What would it mean for DNSBL
On Thu, Nov 13, 2008 at 06:15:53PM -0500, Keith Moore wrote:
For instance, what would happen if mail servers provided feedback to
both senders (on a per message basis in the form of NDNs) and recipients
(say, via a web page that listed messages blocked due to DNSBLs)...in
both cases describing
At 5:06 AM -0800 11/14/08, John Levine wrote:
The whole approach here is An A record in this zone has a meaning
different from the meaning in other zones. That creates a DNS
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the
At 8:17 AM -0800 11/14/08, Tony Finch wrote:
Note that I'm not arguing against a new RR type, I'm just trying to
understand the arguments against the de facto standard.
One significant advantage which I have not seen clearly articulated is
that a new RR type could combine the functions that are
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the types of
requests/responses.
Didn't that plan go out the window in 1996 with RFC 2052?
Sorry, what about SRV made RRTYPE not significant? Sorry
to be dense, but I don't
At 10:56 AM -0800 11/14/08, John L wrote:
Sorry, what about SRV made RRTYPE not significant? Sorry
to be dense, but I don't understand your point here.
A SRV record with _tcp in its name means something different from a SRV
query with _udp in its name. I suppose you could argue that's
On Nov 14, 2008, at 1:38 PM, Ted Hardie wrote:
If we are documenting practice and nothing more, then the
publication stream can move to informational and text can be added
on why a new RR, which would normally be expected here, is not being
used (essentially, inertia in the face of 15
On Fri, Nov 14, 2008 at 01:38:54PM -0800, Ted Hardie wrote:
If we are documenting practice and nothing more, then the publication
stream can move to informational and text can be added on why
a new RR, which would normally be expected here, is not being used
(essentially, inertia in the face
For instance, what would happen if mail servers provided feedback to
both senders (on a per message basis in the form of NDNs)
Well, since 95% of all mail is spam, and all the spam has fake return
addresses, you'd increase the amount of bogus NDNs by more than an
order of magnitude. No thanks.
John Levine wrote:
For instance, what would happen if mail servers provided feedback to
both senders (on a per message basis in the form of NDNs)
Well, since 95% of all mail is spam, and all the spam has fake return
addresses, you'd increase the amount of bogus NDNs by more than an
order of
Seriously, it's not obvious to me that it's *impossible* to change.
Of course it's not impossible. But the question is whether the benefit
from the change is large enough that the people who'd have to write the
software will do so.
IPv4 DNSBLs have been working just dandy with A records
Given that the well known DNSBL causing me grief totally ignores my
requests for removal, ...
I'd be interested in knowing what DNSBL it is. Spamhaus PBL?
MAPS/Trend DUL? SORBS? Something else?
All the anonymous denunciations here are getting a bit tedious.
R's,
John
John Levine in [EMAIL PROTECTED]:
David Morris in [EMAIL PROTECTED]:
Given that the well known DNSBL causing me grief totally ignores my
requests for removal, ...
I'd be interested in knowing what DNSBL it is.
Received: from email.xpasc.com (email.xpasc.com [65.85.17.142])
by
Given that the well known DNSBL causing me grief totally ignores my
requests for removal, ...
I'd be interested in knowing what DNSBL it is.
Received: from email.xpasc.com (email.xpasc.com [65.85.17.142])
by core3.amsl.com (Postfix) with ESMTP id 2CAE63A6782
for ietf@ietf.org;
On Thu, Nov 13, 2008 at 6:23 AM, John Levine [EMAIL PROTECTED] wrote:
Given that the well known DNSBL causing me grief totally ignores my
requests for removal, ...
I'd be interested in knowing what DNSBL it is. Spamhaus PBL?
MAPS/Trend DUL? SORBS? Something else?
All the anonymous
Al Iverson wrote:
I think anonymous may be a bit better in this context, because
otherwise the conversation degenerates into an argument about some
particular DNSBL, instead of a discussion about DNSBLs in general.
I think a lot of us had a pretty good idea which DNSBL is usually the
one in
On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote:
The difficulty is that the current line of argument is that because some
DNSBLs are operated badly, DNSBLs are bad.
I think that's not quite fair. My impression is that there is more
than one line of argument. Here are some
On Thu, 13 Nov 2008, Jim Hill wrote:
| dig any 142.17.85.65.dnsbl.sorbs.net +short
| 127.0.0.10
| Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?65.85.17.142;
Certainly looks to be listed incorrectly ...
| dig -x 65.85.17.142 +short
| email.xpasc.com.
That seems to satisfy all
David Romerstein in
[EMAIL PROTECTED]:
On Thu, 13 Nov 2008, Jim Hill wrote:
That seems to satisfy all the requirements for removal listed at
http://www.us.sorbs.net/faq/dul.shtml
I believe that it's listed 'correctly', per that FAQ, for one reason:
[EMAIL PROTECTED] mail]$ dig
Andrew Sullivan wrote:
On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote:
The difficulty is that the current line of argument is that because some
DNSBLs are operated badly, DNSBLs are bad.
I think that's not quite fair. My impression is that there is more
than one line of
--On Thursday, 13 November, 2008 08:18 -0800 Dave CROCKER
[EMAIL PROTECTED] wrote:
I think a lot of us had a pretty good idea which DNSBL is
usually the one in question when people are complaining
The difficulty is that the current line of argument is that
because some DNSBLs are
Andrew Sullivan wrote:
On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote:
The difficulty is that the current line of argument is that because some
DNSBLs are operated badly, DNSBLs are bad.
I think that's not quite fair. My impression is that there is more
than one line of
On Thu, 13 Nov 2008, John C Klensin wrote:
If there were a BCP on the table that would permit us to talk
about DNSRBLs that conform and those that don't, rather than
about subjective opinions of behaving badly, we would, IMO, be
having a rather different discussion.
I'm violating my normal rate limits here, but since this is the second
time today someone twitted me for this, I need to clarify.
On Thu, Nov 13, 2008 at 12:53:31PM -0500, Chris Lewis wrote:
3. DNSBLs are not in themselves bad, but the implementation of them
as described in the current
Andrew Sullivan schrieb:
As I noted (with Olafur) in our posting the other day, the problem _I_
have with DNSBLs is that they're doing fairly serious damage to the
DNS protocol. That's a fact of life given the deployed software, but
I don't think it's a good thing.
Can you please explain
On Thu, Nov 13, 2008 at 1:25 PM, Matthias Leisi [EMAIL PROTECTED] wrote:
Andrew Sullivan schrieb:
As I noted (with Olafur) in our posting the other day, the problem _I_
have with DNSBLs is that they're doing fairly serious damage to the
DNS protocol. That's a fact of life given the
On Thu, Nov 13, 2008 at 07:25:32PM +0100, Matthias Leisi wrote:
Can you please explain what this fairly serious damage to the DNS
protocol is?
The message I posted from Olafur and me the other day is supposed to
explain this already:
--On Thursday, 13 November, 2008 12:53 -0500 Chris Lewis
[EMAIL PROTECTED] wrote:
2. DNSBLs are in themselves bad, because there is no way to
guarantee that they won't contain false positives; they are
nevertheless possibly useful, but the trade-offs are
inadequeately described in the
At 10:39 AM -0800 11/13/08, Andrew Sullivan wrote:
On Thu, Nov 13, 2008 at 07:25:32PM +0100, Matthias Leisi wrote:
Can you please explain what this fairly serious damage to the DNS
protocol is?
The message I posted from Olafur and me the other day is supposed to
explain this already:
Andrew Sullivan schrieb:
http://www.ietf.org/mail-archive/web/ietf/current/msg53776.html
For the impatient, one fundamental problem is that the current
behaviour uses A records that do not contain host addresses, which is
contrary to the definition of an A record.
And this counts as
At 11:04 AM -0800 11/13/08, Matthias Leisi wrote:
The suggestion to use a dedicated RRTYPE is nice, but many others have
failed in this endeavour before.
-- Matthias
What do you mean failed in this endeavour? failed to get an RR
assigned, or failed in deployment?
On Thu, 13 Nov 2008, Ted Hardie wrote:
Thanks for the pointer. I had missed this technical comment in the
crowd, and I think it is very important indeed. By re-using RRs with
context-specific semantics, the proposal does serious harm to
interoperability.
Is there any evidence for that?
At 11:23 AM -0800 11/13/08, Tony Finch wrote:
On Thu, 13 Nov 2008, Ted Hardie wrote:
Thanks for the pointer. I had missed this technical comment in the
crowd, and I think it is very important indeed. By re-using RRs with
context-specific semantics, the proposal does serious harm to
Windows is one of the most prominent users of DNS.
I remember you could send them netbios packets and
windows would put them into the DNS cache.
Be asured they will put dnsbl into the cache and
then the famous IE will look for cnn.com on 127.0.0.1
It makes sense after all because the spammers
On Thu, 13 Nov 2008, David Romerstein wrote:
I believe that it's listed 'correctly', per that FAQ, for one reason:
CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs).
Following up to myself (bad form!), I'm mistaken. This IP was probably
originally listed because it's in
e.g. the .local TLD.
When microsoft introduced the .local TLD for rendezvous
incompatibility, their windows boxes started to query the
root-servers for nonsense like refrigerator.local
When some hearty nameserver operators fighted back, loading
a zone file for .local they brought campus networks
Dave CROCKER wrote:
The difficulty is that the current line of argument is that because some
DNSBLs are operated badly, DNSBLs are bad.
I have a strong suspicion that poor design of the DNSBL protocol (and/or
its interface to SMTP and NDNs) encourages more badness than is needed.
For
Keith Moore wrote:
Dave CROCKER wrote:
The difficulty is that the current line of argument is that because some
DNSBLs are operated badly, DNSBLs are bad.
I have a strong suspicion that poor design of the DNSBL protocol (and/or
its interface to SMTP and NDNs) encourages more badness than
42 matches
Mail list logo
