Greg,
I have been sending Hadmut a few ideas along these lines. I am not sure
how he feels about them though.
Basically it would work like this:
The original record would have two parts. A pointer to a MARID record
and the "Human Readable" version of the SPF or XML record.
The MARID record would have the binary SPF/XML data.
But wait... there is more...
I actually envisioned putting caching DNS on all the MTA's and putting
a Huffman Compressed version of the "Human Readable" SPF/XML on the
MARID record.
When the MTA looked up the MARID record, it would decompress the
Huffman code and store it in plain text in the local cached DNS. This
way perl parsers, XML readers, Java snippets would be able to use the
locally cached DNS file in plain text. The only time the Huffman
decompression would have to be used is when the record cache expired or
a new domain was looked up. The reasoning behind using the Huffman
compression is that it is simple, available for every operating system,
speedily decompressed, easily parsed, and very large records can still
be sent using UDP. (Not breaking DNS)
The "Human Readable" record stored in the non-MARID DNS record is not
used in the actual mail delivery but should be required to be there. It
doesn't really matter if it is correct or not because the local MTA's
DNS would have a "Human Readable" record in its cache anyway.
I suppose if you really wanted to be paranoid you could write a milter
that compared the two "Human Readable" records after the fact. Or you
could go as far as including the HASH of the "Human Readable" version of
the Huffman compressed record included in the pointer so that the MTA
could check the HASH against the decoded versions hash.
The only issue that I see with this is A) Requiring some sort of DNS on
all the MTA's and B) Decompressing the Huffman compressed data in
stream.
Anyway... just an idea.
Regards,
Damon Sauer
-----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 Greg Connor
Sent: Wednesday, June 23, 2004 7:47 PM
To: IETF MARID WG
Subject: Could binary encoding really be the answer?
Team-
I am sending my third and final message of the day, in order to express
support for Hadmut's suggestion of a binary encoding. I think this is a
good idea, and I believe it combines the best of various worlds
(extensibility, economy, etc).
Here are some highlights.
1. Records can be composed in SPF, XML, or with a wizard. Whatever the
input, the DNS format transmitted over the wire is a binary encoding.
MTAs
need to understand the binary and that's it.
2. DNS servers are not required to read other format, but they can. If
they do, you can enter either SPF or XML text in the zone file. DNS
tools
like dig can display one or both formats.
3. The new binary format applies to the new MARID RR. I would probably
want to keep using SPF format in the TXT records in the short term,
because
I'm not entirely sure of my ability to type binary data into a zone
file.
TXT records in SPF format are referred to as "legacy format" records.
Use
of TXT records may be deprecated at some future time when the new RR is
widely available.
I think this allows for extensibility and reuse of other standards, like
the XML team wants, and it also allows for byte economy like the DNS
core
folks want, and MTA independence that the MTA writers want.
I am not sure how Microsoft is going to like this proposal... on the one
hand we are approving XML for use in composing the records, which is
good,
but on the other hand we are defining a new RR and MS needs to fix their
servers to understand the new RR. This can take however long it's going
to
take, and the TXT record is available now, but not in XML.
The way I see it, it will be tough for MS to have it both ways: they are
probably not going to win approval for a new data format (MARID XML) AND
also avoid the work of deploying a new RR.
Feedback? Comments? Flames?
Hadmut's previous message any my previous reply follows here (in case
you
were ignoring the other thread :)
--Greg Connor <gconnor(_at_)nekodojo(_dot_)org> wrote:
--Hadmut Danisch <hadmut(_at_)danisch(_dot_)de> wrote:
After spending a few more minutes to thing about it, I'd currently
propose this (which, I admit, would also require the gods of DNS to
move a little bit forward to accept it):
...
An MTA would receive the record as it is, as a bit/byte sequence.
DNS does not care about it's structure. The MTA then simply passes
this record to the MARID interpreter, together with other parameters
(peer IP address, sender address,...). The MARID interpreter then
disassembles the ASN.1 encoding.
This way anything is completely covered in the MARID interpreter.
All DNS parts don't depend on any detail.
I would agree with this. I like the idea of being able to go forward
without waiting for DNS upgrades.
Given a choice I would probably lean toward the TXT record being one
of
the human-readable representations, and the new RR being the "binary"
form, but I don't have a strong feeling and I'm willing to be talked
out
of it :)
Question for the DNS/bind gurus out there. Is it possible to put
stuff
in your zone file using TYPE1234 notation, even if the bind version
doesn't support it? We would probably want to go with TXT at first
but
when we have an RR type it would nice to start using it... I'm not
sure
if this is possible.
Now give it eye sugar:
Allow the DNS encoder (i.e. bind reading the zone file) to not only
understand base64 text representations, but also other
representations, like SPF, XML, or whatever future might bring.
In the same library, allow MARID records to be converted into
any of a list of representations: base64, SPF, XML.
This way, it will *always* work with base64. That's the fallback
solutions. If you can't upgrade your DNS software, it will always
work.
Good. Also, when we get around to publishing a new RR and rolling
support for it into various DNS servers, we can make a recommendation
for
other "additional" records that can be stuffed in the response packet.
For example, if the a: mx: or include: mechanisms are used, the
additional section could include the A, MX, or other MARID record in
the
first reply packet. This is of course optional for the DNS server,
but
as long as we are working on a new RR in DNS we might as well make
recommendations on additional records too.
If you extend the MARID records, it depends on wether the extension
is marked critical or not (see my former posting). Non-critical
extensions allow slow upgrades. Or even no upgrades.
And then you have time to extend SPF or XML syntax and upgrade
the conversion library. Until then, base64 always works. Just hack
a perl script to encode new record types.
Good stuff. Thanks.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
*****
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from all computers. 113