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