Why on earth are we even discussing this?
There is no difference whatsoever between a 1 byte packet and a 500 byte
packet. Either data fits in a packet or it does not. Only the number of
packets has significance when considering the impact on the network.
The hotmail policy is an outlier, there are perhaps ten ISPs of similar
scope. Nobody disputes the fact that most policies will easily fit in a
single packet - even without dns extensions.
Once read the hotmail policy will be cached for at least 24 hours.
If AOL has a thousand servers accepting mail then worst case the difference
between binary and text amounts to 1 packet a day on their external network
and maybe a couple of thousand on their internal network. Thats less than a
single powerpoint attachement.
This is control information we are discussing here. This is a tiny fraction
of the message data volume.
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Luis
Bruno
Sent: Monday, June 14, 2004 1:20 PM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: Alternative to TXT or new RR was: Comments on
draft-ietf-marid-core-01 xml use
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