Subject: XML/SPF colaberation

From: "Sauer, Damon" <[email-masked]>
Date: Wed, 23 Jun 2004 08:53:47 -0500

This battle seems to be taking more and more casualties from both
sides.
People who were working closely together are now on opposite sides of
the fence.

 I am reading as much as I can and with either scheme I can't see where
this would not, at minimum, double the load on the DNS system.

 So if we are going to go down that path, I would like to submit a "What
if" that could work for both proposals.
It will require a change in code, but hopefully not a huge one.

 Could the record first have a pointer in DNS that would tell it where
to look and how many bytes the record is?

MAIL FROM: [email-masked]
DNS lookup joejobs.com returns _MARID.joejobs.com/SPF/512
This tells the mail system that the record for joejobs.com is at
_MARID.joejobs.com, the record is an SPF record and expect the record to
be 512bytes long.

 It will require a second DNS lookup to the MARID record, but it will
allow a choice of schema and help resolve the issue of buffer-overflows.

 I have not thought this through this at all. Just came to me.

Regards,
Damon Sauer

*****
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

---

From: [email-masked]
Date: Wed, 23 Jun 2004 16:28:36 +0200

> this would not, at minimum, double the load on the DNS system.
...
> to look and how many bytes the record is?

That's exactly the problem I tried to solve with RMX++. 

But nobody listens. Everyone is absolutely bound to the 
fixed idea of storing everything in DNS, no matter whether
DNS is suitable or not. Nobody cares about how DNS works
internally. Just (ab)use the TXT records as an arbitrary storage
system. Did anyone ever listen to the DNS people who said 
"Don't do that"? Did anyone care about any other service
than e-mail? Did anyone care about capacity of DNS servers?
They say they don't want a new RR type to avoid the need
of upgrading, therefore TXT is needed. 

Has anyone ever made a calculation about how much the 
average DNS traffic and storage will grow and how many
DNS servers will need a hardware upgrade instead of just
a software upgrade?

Has anyone ever cared about the fact that DNS records are
internally binary packed and that they usually do not
store as text what we see when calling nslookup/dig?

This whole SPF vs. XML discussion is ridiculous. 
This is not a technical discussion. 
This is a religious matter.
This is SPF marketing.

Hadmut

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 23 Jun 2004 11:41:02 -0400

----- Original Message ----- 
From: <[email-masked]>
To: "Sauer, Damon" <[email-masked]>
Cc: "IETF MARID WG" <[email-masked]>
Sent: Wednesday, June 23, 2004 10:28 AM
Subject: Re: XML/SPF colaberation

> store as text what we see when calling nslookup/dig?

I don't enough about the DNS server side, but the traffic concerns has been
thee numero uno issue I had with this whole LMAP/DNS concept since day one.
I mean, it was pretty obvious once you got into it:

Remember, the MAJORITY of the mail is spoofed, nearly 60-80% by most
industry standards which matches exactly what we see.   So for 60-80% of
your transactions, you will be exerting a high level of DNS activity
resulting in NXDOMAIN or No Records.

When we finished our system, it was still not ready for release because the
overhead was still too high.  Once we implicated what I deem an Important
concept recommended and writing in RFC 2821,  we reduced the overhead by
nearly 35%!  With this and additional reduction items that minimized all DNS
lookup requirements, we finally released the product.  Said one linux
developer, "he seen other systems using the same anti-spam features, but
your method is more efficient."

So efficiency is very important people.  But having spoken to some people
who seem to have some DNS background, they gave me the idea, this LOOKUP
overhead is a non-issue.   I kept scratching my head about this because it
can't see how it can not be an issue.

> This is a religious matter.

I Agree.  We need to take our time and do this right.

---

From: Luis Bruno <[email-masked]>
Date: Wed, 23 Jun 2004 17:00:02 +0100

> resulting in NXDOMAIN or No Records.

Or, if this effort is successful, you get cache hits...

... if it's still cached, that is. Bigger records will result in more
cache churn, if I understand DNS correctly.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 23 Jun 2004 19:24:29 +0200

[email-masked] writes:
>>   Could the record first have a pointer in DNS that would tell it 
>>   where to look and how many bytes the record is?
>
> But nobody listens. Everyone is absolutely bound to the fixed idea of 
> storing everything in DNS, no matter whether DNS is suitable or not.

Seconded. But I don't think that can be changed - it's what the vast 
majority of the working group wants.

(FWIW, I tried to compute the traffic load of DNS vs. RMX++ vs. the RPC 
mechanism I've been muttering about. Assuming that spammers adapt and 
some other minor assumptions, I see no significant difference for 
participating sites.)

> This whole SPF vs. XML discussion is ridiculous.

Amen.

Arnt

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 23 Jun 2004 20:03:44 +0200

Arnt Gulbrandsen wrote:

>
> (FWIW, I tried to compute the traffic load of DNS vs. RMX++ vs. the 
> RPC mechanism I've been muttering about. Assuming that spammers adapt 
> and some other minor assumptions, I see no significant difference for 
> participating sites.)

Thanks a lot. I didn't compute it, but I roughly estimated this.

 I do not expect a big difference in traffic. But I do expect Web 
servers and HTTP proxies to
cope much better with this kind of traffic and stored data than DNS 
servers can. And
Web servers do not need any update or new protocol. They are there. 
Plenty of them.

And, as a main advantage, you could choose whether to
- put a static MARID record on the server as a file
- generate the record dynamically through a simple CGI script
- passing the parameters up to the server and do the check
  in any way you want without change of protocols or MTA
  software.

DNS servers can't do it.

I do not see this as the only possible solution. But I'd currently see 
two technical
ways to do it as I mentioned before:

- Either the "small" solution:
  Have a compact binary record in DNS. I'd prefer ASN.1. Write a coder and
  decoder for the dns library, which converts the binary from and into a 
readable
  representation of your choice. If you like it, have nslookup and dig 
print it
  in SPF syntax for readability. Or in XML for postprocessing. Give it a 
command
  line flag to choose what you want. It is like with those x.509 
certificates:
  They are binary, but you use openssl to convert them into a readable
  representation.

- Or the "big" solution (like RMX++):
  Have a Pointer in DNS giving a resource locator where to get or
  where and how to ask for the MARID record.

And there a  two hybrid solutions:

- Ask the DNS for an any record in _marid.domain...

  If you receive a MARID record, use the small version.

  If you receive SRV records, use the big one.

- Or you receive a MARID record with either regular
  entries or a special locator entry mimicing the former
  SRV model.

In this way, XML and SPF colaborate very well, because they both are
just the external representation and you can arbitrarily choose which you
want for any purpose. You have one record and can convert it to
both (or other) representations. Best of both worlds.

The SPF people get, what they want: They can simply type in SPF
statements into their zone files, except that the are of type
MAR instead of TXT. And if the dig or nslookup, they see SPF as well.
Be happy.

The XML people can do it the same way. Be happy as well.

The DNS folks get compact binary records, and, btw, the introduction
of ASN.1 into DNS. I guess these are two reasons to be happy.

And the implementors can - of course after understanding ASN.1 and DER -
implement easily, because DER allows decoding with very small, compact,
and simple routines in any language, just with a one-byte lookahead.
I believe this to be more efficient and faster than parsing SPF records
(which might require regular expressions).

And you can extend it at any time because ASN.1 is extensible.
Unknown record? Just have a critical flag like in x.509 extensions.
If you don't understand it and it doesn't have the critical flag,
just skip it. It has a length field.

Did anyone complain that XML is extensible in syntax, but the
semantics is not extensible because requiring new programs?
This problem also occured with x.509 certificate extensions.
They solved it with a single bit, the critical bit. Unknown extensions
where this bit is not set can be silently ignored.

And this way you have a very clean separation between
internal encoding and external representation. DER is
unambigous. Want to embed x.509 certificates, e.g. for
SMTP over SSL? They are already ASN.1 encoded.

And it is not a big deal to provide a reference implementation of a
MARID interpreter which does not require any external library
functions (except for fetching other DNS records and such standard
stuff).

Give MARID records a new OID, as usual in ASN.1, and you can be
sure to be able to plug it in into other protocols without major problems.

regards
Hadmut

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 23 Jun 2004 23:08:20 +0100

> This is a religious matter.

It certainly does seem like that sometimes, doesn't it. I'd guess that some
SPF evangelists believe that proselytizing by any means neccessary is vital
to getting the deployment levels up.

Some possibilities:
(a) MARID fails to be deployed extensively enough to make any difference
or
(b) MARID works, but could have been better and cheaper (and earlier).
or
(c) MARID is deployed, new world fails to materialise and everyone gets
bored of it in a few years.

Any others?