Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use

From: "Michel Py" <[email-masked]>
Date: Fri, 11 Jun 2004 12:09:14 -0700

> william(at)elan.net wrote:
> [..] I was joking because while this may seem like a way out,
> in no way do I think it should be done or that it'll ever fly
> by IETF top guys. We should never attempt to completely take
> over somebody else record, that is a very bad precident for IETF. 

Then, which one out of the three alternatives I posted yesterday would
you recommend (or add your own)?

1. We do it quick and dirty with TXT.
2. We do it right and slow with a new RR type.
3. We say that we'll go with 1 as a temporary
   measure and with 2 in the long run.

Michel.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 11 Jun 2004 16:53:58 -0700 (PDT)

>    measure and with 2 in the long run.

I'd prefer #2 actually.
I think it would not be as slow as you predict because greater majority 
of mail operators are not using microsoft os (> 80%) and will be able to 
use new MARID record type quite quickly. Having situations that unix folks 
are able to do it while microsoft can not will put greater pressure on 
microsoft (plus their charimans's comments that spam problem would be 
"solved" by 2006) and might even cause to have patch for dns resolver & 
dns server released before next OS.

That said I'd be ok with option #3.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 12 Jun 2004 14:04:30 -0400

My input on the issue of TXT vs. RR.

When it comes to DNS, I am not enough of a cog to know the technical issues
related to TXT vs. RR.

However, from a developer standpoint,  unless there will be some
programmatic algorithm to automate the process of determining which is used
to query a domain policy, there should be ONE record type, not two.  Again,
if there will be two, the logic needs to be in place to automatically
determine what is to be use.  The last thing you want is for a MARID client
to be doing two or more different record lookups.

Personally, I have trouble understanding why anyone would start a new design
with a "kludge" concept. But again, I don't know why the TXT vs. RR is an
issue.  Maybe would be kind enough to sent me a personal message with the
basic issue between the two.

Finally, I hope I am not being redundant but I would like to point out again
that the majority of the mail is spam and while MARID made help protect the
spoofing of domains, most lookups will be failures (NXDOMAIN or none).  This
efficient issue should not be ignored.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message ----- 
From: "william(at)elan.net" <[email-masked]>
To: "Michel Py" <[email-masked]>
Cc: "MARID" <[email-masked]>
Sent: Friday, June 11, 2004 7:53 PM
Subject: RE: Alternative to TXT or new RR was: Comments on
draft-ietf-marid-core-01 xml use

---

From: Luis Bruno <[email-masked]>
Date: Mon, 14 Jun 2004 18:19:52 +0100

I'd like to hear comments on this, even flames or pointers to threads
I've missed. If this discussion is in any way out of order now, I
apologise; but do tell me to shut up in that case.

Hector Santos wrote:
> I don't know why the TXT vs. RR is an issue.

From my point of view, creating a new RR type is the correct approach.
The problem lies with Microsoft's existing design, which makes the
deployment of a new RR type harder.

It's actually a moot point; my personal peeve is the representation of
the MARID information: you could place the binary information in a TXT
record, as I see it.

I'd like to have the MARID information in a binary representation; the
current design favors a textual representation, with a lot of overhead.

I'll use hotmail.com as an example. You can see the information at:
http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com
[37 records snipped]

The information occupies 537 bytes without tags.
In binary, that would be 185 bytes: 5 binary octets * 37 records.

The work on representing prefix lists has already been made by RFC3123.
As I see it, it supports the SPF a, mx, ip4 and ip6 mechanisms. Each
of the prefixes in that list can be negated.

I think this is a better way to publish the MARID information. If we use
TXT for that or not, it seems irrelevant. As I understand it, we could
use TXT to publish binary information: RFC1035 seems to allow arbitrary
information in TXT RDATA.

-- 
Luis Bruno                                UTM: 29T 629481E 4511776N 576m

---

From: wayne <[email-masked]>
Date: Mon, 14 Jun 2004 14:34:26 -0500

> current design favors a textual representation, with a lot of overhead.

libspf-alt currently byte-compiles all SPF records into a compact,
network portable, binary format that requires no text parsing.

> In binary, that would be 185 bytes: 5 binary octets * 37 records.

Hotmail's email policy in:

XML: 1040 bytes  
SPF: 776 bytes (XML * 1.32)
byte-compiled:  240 bytes (XML * 4.33, SPF * 3.23)

-wayne

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 14 Jun 2004 23:08:35 -0700

On 6/14/2004 10:19 AM, Luis Bruno sent forth electrons to convey:

>I've missed. 
You missed the discussion (probably including posts from wayne) about 
how the simple format of SPF made it easier to deploy and the stats 
showing how many domains had deployed SPF vs. CID. (something like 
30,000 vs. sixty).  Also discussed: New RR support in deployed clients 
is poor and in servers is fair but not great. The former is easily fixed 
by having the client embedded in the MARID implementation.  The latter 
is not easily fixed. A third problem is firewalls that block queries of 
the new RR becaue they don't recognize it.  (Any known cases of 
firewalls that do this? Cisco PIXes don't; they just block (by 
configurable default) DNS packets larger than 512Bytes.)