Subject: RE: Drive Towards Consensus

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Jun 2004 08:03:26 -0700

> use the modifier: smime=always
> 
> > 	* express the message digest of the signing certificate
> 
> use the modifier: smime.certdigest=<location>
> 
> > 	* express the algorithm supported.
> 
> use the modifier: smime.alg=rsa
> 
> 
> Or, just use:  smime-info=<location>

Which illustrates my point, you need structures and so you have cobbled
together an ad-hoc internal syntax to meet this need.

With XML I can simply define the data structure and the compiler will
construct the parser for me.

What you are trying to do here is to constrain the problem to the size of
your tool. That is not a very good approach when you are trying to deal with
a problem with a legacy system.

---

From: Greg Connor <[email-masked]>
Date: Tue, 22 Jun 2004 08:33:06 -0700 (PDT)

> a problem with a legacy system.

By "a problem" you mean "a problem other than the one the tool was designed to 
solve," is that correct?  :)

Just trying to put the question in context of "how much and what kind of 
extensibility do you want?"

--
Greg Connor
[email-masked]

Everyone says that having power is a great responsibility.  This is a lot
of bunk.  Responsibility is when someone can blame you if something goes
wrong.  When you have power you are surrounded by people whose job it is
to take the blame for your mistakes.  If they're smart, that is. 
                -- Cerebus, "On Governing"

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 22 Jun 2004 21:27:35 +0200

wayne wrote:

>There are also some not very technical/rational reasons:
>
>* Many mail admins don't like/understand XML.
>  
>

I do know so many mail admins who don't like/understand DNS.
Therefore we shouldn't use DNS.

>* XML is promoted by MS a lot, and many mail admins don't like MS.
>
>  
>

Correct. I don't like MS either.

As far as I know MS promotes the use of e-mail, computers, and internet.

We should stop using e-mail, computers and internet.

Hadmut

---

From: wayne <[email-masked]>
Date: Tue, 22 Jun 2004 13:35:36 -0500

Ok folks, I'm way over the 3-post/day suggested limit, so this is my
last post for a while.

In <[email-masked]> "Hallam-Baker, Phillip" <[email-masked]> writes:

[quoting out of order:]
> a problem with a legacy system.

Yes, I am trying to constrain the problem to the size of the tools I'm
using.  In particular, I'm using DNS.

Once upon a time, the "exp=" modifier was part of the main SPF
record. (exp= provides text that explains why an email was rejected by
SPF.)  Since the explanation text is often very long and since not
everyone would want to see it, I argued that it should be put into a
separate location.

Likewise, most of these extensions are not going to be wanted by
everyone and some are quite large.  Adding short pointers to this info
in the main SPF record is, IMHO, the way to go.

>> [long list of "use the modifier" snipped]
>

I never said that the syntax had to be different.  You did not give
enough details about what you wanted for me to show an exact
translation.

There are lots of very solid technical reasons to not want XML:

* The records *are* slightly larger, especially with the original
  Caller-ID version of the spec.  Since the number of bytes is so
  limited, this is a problem.  Not a killer problem in and of itself,
  but you can't dismiss it either.

* In order to save bytes, the XML has to be scrunched together, making
  it very hard to read and modify.  Whitespace makes things much more
  readable, and SPF uses whitespace.

* In order to save bytes, most of the parsing isn't done via XML, you
  still have to have a complete SPF parser in order to do anything.
  You still have all the problems with creating an ad-hoc parser, but
  you have added all the problems of using an XML parser.

* XML solves the syntax extension problem, but not the semantic
  extension problem.

* The XML parsers are often very big, compared with the MTAs.  When
  you double the amount of code, as in the case of qmail and libxml,
  you are more than double the chances of a security hole or allow for
  some sort of abusive XML document.

* Two syntaxes means two different code paths that have to be tested.

* Two syntaxes means that people who want to publish something have to
  make a confusing decision right off the bat.  Is one better than the
  other?  Why both?  Which should I choose?

* Two syntaxes means that anyone who needs to diagnose a problem with
  the MARID records has to understand both.

These latter two reasons have somewhat overshadowed the more
technical reasons.  I think some people assume that when the technical
points are being raised, they are really to hide the irrational
reasons and get pissed off by this.  This, in turn, pisses the people
who feel they have raised valid technical concerns and are being
dismissed for being "irrational."

XML is a great tool, but it is not a great tool for all jobs.

-wayne

---

From: <[email-masked]>
Date: Tue, 22 Jun 2004 16:05:09 -0400

I also know numerous mail admins (many MCXX certified) who don't understand even the simple concepts
of the bare SMTP protocol.  (Probably because most of them don't get taught what's under the hood).
But when I encounter this, I can teach them the necessities for problem solving (telnet port 25, use
simple SMTP commands for diagnosis).

I cringe at the thought of having to teach someone how to problem solve and debug a bad SPF record
in XML.  It would be bad enough with SPF v1, a person would have to learn SPF theory and then apply
it.  But with XML first they would have to be taught XML and only then could we get to the real
topic at hand which is the SPF theory.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Hadmut Danisch
> Sent: Tuesday, June 22, 2004 3:28 PM
> To: IETF MARID WG
> Subject: Re: Why not XML
>
>
>
> wayne wrote:
>

---

From: Greg Connor <[email-masked]>
Date: Tue, 22 Jun 2004 21:54:35 -0700

The appearance of Hadmut Danisch in the In Favor Of XML camp is definitely 
a blow to the anti-XML team.  This, coupled with the support of Phillip 
Hallam-Baker is almost enough to make the anti-XML team lose hope.

Here Hadmut demonstrates a typical argument method in the Not Based On 
Logic categorym that of making fun of an argument he disagrees with.  The 
listener may be swayed into thinking that if the argument can be mocked, it 
must not have been serious in the first place.

> Therefore we shouldn't use DNS.

Here is another example of the non-logical argument technique called 
"mocking".

"Many mail admins don't like cheese.  Therefore, MARID should be made out 
of bread!"

> We should stop using e-mail, computers and internet.

Hmm, that one will be tough to top.  But I will try.  How about:

"MS promotes shareholder value.  Therefore we should reject capitalism, 
move to a commune, and weave MARID records on the same loom we use to weave 
clothes made of our own hair."

Now.  All joking aside, I have a great deal of respect for Hadmut and his 
work... we probably would not have arrived where we are today without him. 
But, the arguments being made here are not logical ones.  In fact, Hadmut's 
message here is an *excellent* example of someone reacting emotionally (and 
making an emotional argument) rather than reacting with logic.

Surprised?  You shouldn't be... because the whole XML issue is VERY 
emotionally charged.  We are all reacting emotionally to it, and you had 
better believe our customers will react emotionally to it as well.  We 
ignore this point at our peril.  Will our customers have an emotional 
reaction to XML?  If so, no army of technical experts will change that 
reaction.

What if it's true, that more admins will adopt it if the record is easy to 
read with the unaided eye and easy to write with the unaided hand?  Is that 
even a consideration for the "make it future-proof" crew?  Would people on 
this team prefer to create something that expands in 8 directions and comes 
with a flip-out compass and a toothpick?  If it will get used by fewer 
domains for totally non-technical reasons, is that important?

In some years in the industry, I have noticed that a lot of really, really 
smart, really intelligent people will be unable to deal with emotions on 
any level.  Of course they have them, but they will deny it and provide 
lengthy, detailed, technical explanations as to why they believe the way 
they do.  The stronger the feeling, the more verbose the so-called logical 
explanation.  These individuals will even use cunning wit to attack someone 
else ruthlessly, with no way to explain bad behavior other than "Well, he 
was wrong."  (Inconsiderate, even rude behavior such as Hadmut resorted to 
here is a sign of an emotional reaction in progress.)

At the same time, these incredibly smart individuals will often be 
dumbfounded and helpless when faced with someone else who *admits* to 
having an emotional reaction.  Explaining how you feel to someone who deals 
on an intellectual plane 99% of the time is like speaking a different 
language -- they either cannot comprehend, or dismiss it is not logical, 
therefore stupid.

On an emotional level, here are two possible reactions that people might 
have to XML.

1. Ooooh, shiny.  I'll bet it goes fast.  I would really like an excuse to 
take that syntax for a test drive.  (Let's call this the "engineer's 
reaction")
2. Yuck, that's ugly.  And 20% longer.  I sure hope it works right the 
first time because I sure don't want to debug it.  (Let's call this the 
"sysadmin's reaction")

We have to be ready to deal with BOTH reactions, and since they are 
emotional reactions, we can't explain them away.  We can get around them, 
but not with engineering powers... the power to change an emotional 
reaction is reserved only for the marketers :)

You know, I'll admit that I'm reacting emotionally too.  I'm no different. 
But, I guess I need to heed my own advice and take a step back.  If we have 
near-agreement on semantics, identities, and features and then totally lose 
all unity and team spirit over something as simple as syntax, we are 
guaranteed to look silly and be irrelevant in 5 years, probably less.  This 
outcome would be much worse than publishing a standard that needs revision 
within a year and is obsolete in three.

So.  Who is ready to compromise?

--
Greg Connor <[email-masked]>

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 23 Jun 2004 08:43:11 +0200

Greg Connor wrote:

>
> The appearance of Hadmut Danisch in the In Favor Of XML camp is 
> definitely a blow to the anti-XML team.  This, coupled with the 
> support of Phillip Hallam-Baker is almost enough to make the anti-XML 
> team lose hope.
>
> Logic categorym that of making fun of an argument he disagrees with.  
> The listener may be swayed into thinking that if the argument can be 
> mocked, it must not have been serious in the first place.
>
> ...

> Now.  All joking aside, I have a great deal of respect for Hadmut and 
> his work... we probably would not have arrived where we are today 
> without him. But, the arguments being made here are not logical ones.  
> In fact, Hadmut's message here is an *excellent* example of someone 
> reacting emotionally (and making an emotional argument) rather than 
> reacting with logic.
>

This was not meant to be logical.
This was not meant to be an argument at all.

This was meant to be irony and sarcasm. I wanted to point out on which 
lousy level this
discussion is made. If you didn't realize this and still took this as an 
argument, you confirmed
my point of view. While you were blaming me for beeing emotional, It was 
you who gave a
purely emotional reaction. You were supposed to laugh and cool down.

Maybe you have realized that I didn't participate in this discussion for 
a long time. Guess why?

Because this is an endless loop. An emotional loop. Caused by SPF.

Why?

Because SPF has never been a technical invention. SPF is only a public 
relations coup of
a few people who were hijacking an idea to bring themselves in front of 
the cameras
and the newspapers. I have spoken with several journalists who were 
intentionally misinformed.
If you don't believe this, just have a look at the ASRG history.

And that's the reason for emotions. What is the main property of SPF? 
Nothing but a
slightly changed syntax. If we don't stick to SPF syntax, what will 
remain of the SPF hype?
Roughly nothing. That's the reason why so many people desperately defend 
SPF syntax
against any progress. They try to enforce SPF syntax, because that's all 
SPF consists of.

Think about it. Your overreaction to my sarcasm was very meaningful.

OK, let's come back to technical arguments.

A/The major argument for using SPF is readability. I confirm that 
readability is
a very strong and important argument.

But is this correct? No, it isn't. Why not?

Because it ignores the fact that DNS records are not readible by default.
Readibility of SPF is based on wrong assumptions. It is based on abusing
TXT records. The readibility argument includes a lot of ignorance of 
technical
facts. Most people don't seem to be aware of layer models.

Have you ever seen DNS records from inside? How DNS records are
encoded? They are not readible. They are binary encoded.

If you can easily read what nslookup/dig spit out, then this is not a
property of DNS records. It is because the dns library includes
encoders and decoders for every single DNS record type. What you
see is a result of a decoding process, not the DNS record itself. Even
TXT records require some encoding. It's extremely simple, but it
is there.

What does that mean? The whole argument of readibility is pure nonsense.
Based on wrong assumptions and ignorance of technical details.

What do you believe? Why did I put both a syntax and a binary encoding
in the RMX drafts? Because you have to cover both, the external
representation and the internal encoding. That's what we have to deal
with in context of DNS, whether you like it or not.

Of course, you can decide to abuse TXT records or invent a new
MARID record type with exactly the the same simple encoding as TXT
records. But that itself is a step of engineering most people never thought
about. This MARID/SPF/... discussion is a religious controversy, not a 
technical
development process.

How do we make it any better?

I propose to start beeing aware of having to do two different jobs:

- Define an internal encoding

- Define an external representation

(This requires to understand how DNS works, which is significantly
more than just being able to abuse TXT recors...)

I'd propose an example. You don't need to stick to it, it's merely
to explain what I am talking about.

- First, define an abstract semantics. This is almost done.
  Define that MARID records can authorize IPv6 addresses,
  IPv4 ranges,etc.

- Second, define an internal encoding.
  I'd prefer ASN.1/DER

  DER decoders are not that difficult, because in contrast
  to XML you can work with a simple one byte lookahead.
  DER de- and encoders can be extremely small and
  compact. (And I don't know that anyone ever seriously complained
  that SNMP, X.509,... are encoded in ASN.1).

- Define an external representation. This is what nslookup or
  dig spit out when displaying a query result or what bind
  eats when reading a zone table. If you don't understand what
  I am talking about, have a look at the bind sources or the
  RMX implementation example available at danisch.de

  Why not having two external representations?

  You are free to express the ASN.1 encoded information in
  any readible syntax, both SPF or XML, for zone tables,
  for human readibility, for printouts, for storage, as a
  mime type, whatever you want.

  This way you can have two different representations without
  having two different types of records.

  Those who love SPF can have there DNS library compiled
  that it displays MARID records as SPF. Has advantages on
  command line tools.  And others, including
  the MS world, can use XML representation.  Good for
  programming languages.

  Important is that we have two representations, but only 
  a *single* encoding. Only one type of DNS records. That's it.
  SPF or XML is not a matter of the record itself. It's a matter
  of the program you use to display the record.

- MARID interpreters, those which are built into MTAs, can
  work directly on the encoding, e.g. ASN.1. This is
  actually easier or actually not more complicated than
  parsing SPF. You have automated tools for those who
  don't know ASN.1. And if you do, it is also a simple
  afternoons job to write a parser on your own in
  any available language.

So in my eyes, this would be the best solution as long as we
are bound to store MARID records in DNS (if not, see RMX++ proposal).

regards
Hadmut

---

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

>   some sort of abusive XML document.

Well, clearly, only an XML parsing application is vulnerable to an abusive
XML document (whatever that is). That said, claiming that linking with a
XML parsing library will "more than double" the chance of a security hole
seems a little wild. I'd be very surprised if XML MARID documents exercised
every single line of code in your XML library, so the absolute size of the
library isn't necessarily significant, is it?

If this kind of security is a such concern for you, the risk is easily
mitigated by sensible application design (e.g. don't link it in, have a
helper app). I don't see how it can be a show-stopper for XML, for us here.

---

From: Sean Comeau <[email-masked]>
Date: Wed, 23 Jun 2004 03:41:22 -0700

> OK, let's come back to technical arguments.

excellent!

> But is this correct? No, it isn't. Why not?

it is one reason. simplicity of the code that needs to be added to MTAs 
and making sure the records fit into 512 bytes is another. Your suggestion
is the best in all these areas. 

> - Define an external representation

[...]

I fully agree with you. That is clearly the proper way to do it. 

The original idea was to use TXT records first, make implementations 
that can use those available then hope that because the TXT records 
are in widespread use and because using TXT records that way is such 
an ugly kludge a new RR type would be created and the TXT record would 
go away. But people seemed to feel that getting everyone to upgrade
their nameservers in addition to their MTAs would be an impossible
task. 

Maybe this standard should ignore the TXT record after all and require
a new MARID record. I'd be very happy with that solution.

---

From: "Michael R. Brumm" <[email-masked]>
Date: Wed, 23 Jun 2004 04:57:03 -0600

Hadmut Danisch wrote:
>Because SPF has never been a technical invention. SPF is only a 
>public relations coup of a few people who were hijacking an idea 
>to bring themselves in front of the cameras and the newspapers. 
>I have spoken with several journalists who were intentionally 
>misinformed.

I'm sure it came as a complete surprise to me that the SPF implementation I worked on for over a month was just a "public relations coup" and has "never been a technical invention".

And intentionally misinformed journalists? Isn't that a bit redundant? Can a person actually be guilty of misinforming journalists, or does it occur naturally?

>Readibility of SPF is based on wrong assumptions. It is based on 
>abusing TXT records.

Abusing TXT records? Is this your "irony and sarcasm"? I honestly can't tell.

>encoded? They are not readible. They are binary encoded.

Using a binary encoding was thrown around a bit in the SPF community. There are plenty of obvious reasons why this wasn't seriously considered. There are already thousands of posts on why the TXT record is the best DNS record solution in the near-term, so I won't get into that. And expressing SPF as binary data in a TXT record makes a lot less sense than just using the SPF syntax.

Obviously, the best technical solution would be a binary representation in a newly allocated RR type. However, this is not a practical solution for at least two more years. It really is too bad that RFC 3597 did not come out much earlier.

>If we don't stick to SPF syntax, what will remain of the SPF
>hype? Roughly nothing. That's the reason why so many people 
>desperately defend SPF syntax against any progress. They try 
>to enforce SPF syntax, because that's all SPF consists of.

An alternative reason for people defending the SPF syntax might be that it has already progressed through an extensive community discussion, testing, validation, revision, and a significant deployment. That seems like a lot for something that consists of nothing more than a syntax.

IMHO, if we don't come up with something soon, SPF will become the defacto-standard (arguably, it already is) without IETF ratification.

We can make grand statements, facilitate discussion, and pass resolutions, but if a large enough constituency decides that the IETF has neglected action, then the void will be filled. I hope we have the wisdom to avoid this type of embarrassing and shameful situation.

Michael R. Brumm

---

From: John Levine <[email-masked]>
Date: 23 Jun 2004 13:33:02 -0000

> I'd be very surprised if XML MARID documents exercised every single
> line of code in your XML library, so the absolute size of the

Bad guys can publish any complex and hostile MARID documents they
want.  Typical MARID documents are indeed likely to be pretty simple,
but if word gets around that there's a bug in an XML library, how long
will it take until there's MARID data to exploit it?  Minutes, I'd
guess.

---

From: Luis Bruno <[email-masked]>
Date: Wed, 23 Jun 2004 14:32:42 +0100

Sean Comeau wrote:
> But people seemed to feel that getting everyone to upgrade their
> nameservers in addition to their MTAs would be an impossible task. 

Not to defend Microsoft's existing design but I was under the impression
that we're using TXT because of bad design choices by the DNS team at
Microsoft.

Specifically, they can't query for a new RR type when behind an ISA
firewall.

> Maybe this standard should [...] require a new MARID record.

That's the "clean" approach. However, I don't know how hard that is for
the sysadmins. The MTA must be upgraded, that's a given. Would upgrading
DNS be a showstopper?

You should be able to put structured, binary data in TXT anyway; that's
how I read the RFC, anyway.

Cheers,
-- 
Luis Bruno                                UTM: 29T 629481E 4511776N 576m
"14) Always remember that Windows NT administration is to Unix and WAN
administration, as _Herbie The Love Bug_ is to _Citizen Kane_. Respect
your elders and don't trivialize their work." -- Christian Wagner's Tips

---

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

> Specifically, they can't query for a new RR type when behind an ISA

If so, then ISA is broken. 

Should we define a badly designed protocol just to 
workaround broken firewall software? That's a joke...

Hadmut

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 23 Jun 2004 08:11:50 -0700

> workaround broken firewall software? That's a joke...

Alas, yes.  That is reality.  There are too many deployed ISA systems.  
Oh well....
The same is true for SPF's original choice of TXT vs. a new RR type: 
There are too many deployed DNS infrastructures that can't handle a new 
RR type easily.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: Luis Bruno <[email-masked]>
Date: Wed, 23 Jun 2004 16:19:18 +0100

Luis Bruno wrote:
> The MTA must be upgraded, that's a given. Would upgrading DNS be a
> showstopper?

I meant: Would upgrading DNS servers be a show stopper?

---

From: Luis Bruno <[email-masked]>
Date: Wed, 23 Jun 2004 16:16:51 +0100

Hadmut Danisch wrote:
> Should we define a badly designed protocol just to workaround broken
> firewall software? That's a joke...

Yes, the design is a joke. Of course the design is an error; but I've
made worse ones in simpler stuff, so I won't flame them.

However, we can put the information in TXT, and encode it the same way
we would for a new RR type. Should we? I think we should not, but if it
doesn't cost us much...

I'd rather see Microsoft fixing their stuff.

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 23 Jun 2004 08:20:03 -0700

On Jun 22, 2004, at 11:43 PM, Hadmut Danisch wrote:
> a few people who were hijacking an idea to bring themselves in front 
> of the cameras
> and the newspapers.
Okay, assuming you mean Meng, and myself in this group, I am very 
insulted.  How dare you imply that the countless hours of work we have 
put into this are for self-aggrandizement.  I don't get paid for this 
work, nor do I even work for a company that sponsors my involvement.  I 
volunteered my efforts to help a build a tool for everyone.

> OK, let's come back to technical arguments.
Sorry, I can't right now.  I'm far too upset by what you've said above. 
  I am stunned that you would proceed in such a unprofessional manner, 
and in the public forum of a standards body working group.

If your goal was to stymie any rational discussion, you've succeeded.

	- Mark Lentczner

Mark Lentczner

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 23 Jun 2004 18:00:47 +0200

>I'm sure it came as a complete surprise to me that the SPF implementation I worked on for over a month was just a "public relations coup" and has "never been a technical invention".

Just spending a month of time doesn't necessarily turn anything into a 
technical invention.

>And intentionally misinformed journalists? Isn't that a bit redundant? Can a person actually be guilty of misinforming journalists, or does it occur naturally?

Oh yes, a person can intentionally tell the untruth in order to cause 
the journalist
to write the untruth. This is what happened.

>Abusing TXT records? Is this your "irony and sarcasm"? I honestly can't tell.

Ask the DNS people. They'll explain.

>
>Obviously, the best technical solution would be a binary representation in a newly allocated RR type. However, this is not a practical solution for at least two more years. 
>

Thank you very much for confirming this as the best technical solution.
This is exactly where all this discussion started, this is what RMX is.
RMX was and is a binary representation in a newly allocated RR type.

May I remember you that SPF started as a plagiarism of RMX and
was explicitely announced as such? The only "invention" of SPF was to
not use a new RR type and to not use binary representation (which was,
if I remember well, taken from another proposal).

For the purpose of discussion, let's assume that your estimation about
two years is correct: RMX is almost two years old by now. SPF is a 
little bit
more than one year old. The SPF circus caused a severe delay in the 
evolution of
such a mechanism, a delay of about a year right now.
SPF was the idea to use plaintext in TXT records.

And now you say that the best technical solution would be a binary 
representation in a
newly allocated RR type, as RMX proposed from the very beginning, but we 
can't do this
anymore because we now lack that time we've lost through the SPF circus 
proposing
a different way that you now consider as worse?

Don't you say that SPF prevented exactly that what you yourself call
"the best technical solution"?

Is that what you call a technical invention?

Hadmut

---

From: Andrew Newton <[email-masked]>
Date: Wed, 23 Jun 2004 12:16:54 -0400

> If you don't believe this, just have a look at the ASRG history.

Hadmut,

This is clearly in violation of the code of conduct I asked all 
participants to observe, just 6 days ago:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html

Consider this your first and last warning.

-andy

---

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

Mark Lentczner wrote:

> insulted.  

And I felt insulted by what newspapers were writing.

But I didn't mean you. And I didn't mean Meng in first place.

If you don't know whom I was talking about then you simply don't know 
what happened
in the "history".  Maybe you should be better informed before 
considering yourself
as being insulted.

> How dare you imply that the countless hours of work we have put into 
> this are for self-aggrandizement.

I dare. Because I have spent not less hours of work, and I didn't get 
paid either.

> I don't get paid for this work, nor do I even work for a company that 
> sponsors my involvement.  

I don't get paid for this either, and I do not get sponsored.
I even paid the flight to and the stay in San Francisco just for being 
fooled at the
IETF last year at a time were I was unemployed, just to see other people 
placing
themselves in front of the cameras an microphones by giving false 
information.
And I will pay again the flight to IETF in August and will give my 
vacation days without
beeing sponsored. I have spent several months of work and discussion.
So don't tell me about beeing insulted.

> Sorry, I can't right now.  I'm far too upset by what you've said 
> above.  I am stunned that you would proceed in such a unprofessional 
> manner, and in the public forum of a standards body working group.

So everybody who questions SPF or misinforming the press is unprofessional?
Inform yourself about the history of SPF before you raise such claims.

Do you know that some of the SPF defenders claimed that plagiarism was 
legitimate
because I had failed to do proper marketing for RMX? And you are feeling 
upset?

Hadmut

---

From: Greg Connor <[email-masked]>
Date: Wed, 23 Jun 2004 10:41:52 -0700

Hello,

I appreciate your taking the time to write a reasonable reply.  It is 
evident that we all feel strongly about this issue (and others) so the best 
we can do is to be clear about our thoughts, feelings, beliefs and 
intentions, which it looks like you have done.

Here is a quick response to cover a couple points you raised.

--Hadmut Danisch <[email-masked]> wrote:
> lousy level this discussion is made. If you didn't realize this and still
> took this as an argument, you confirmed my point of view. While you were
> blaming me for beeing emotional, It was you who gave a purely emotional
> reaction. You were supposed to laugh and cool down.

I understand what you mean.  I probably wasn't very clear and I apologize.

What I meant to say was, making fun of someone else's post is considered 
rude.  If you make someone else the butt of a joke, it's funny, but it's 
also somewhat inappropriate behavior for a polite civilized list.  It's 
also a warning sign to indicate that someone is reacting emotionally, 
though there may be other reasons someone might behave rudely that don't 
have to do with emotions, they are often associated.

> relations coup of a few people who were hijacking an idea to bring
> themselves in front of the cameras and the newspapers. I have spoken with
> several journalists who were intentionally misinformed. If you don't
> believe this, just have a look at the ASRG history.

This is a common reaction to SPF among technical folks who are aware of its 
history.  I would like to take a moment to address it.

SPF is not just a cool idea, it is a number of cool ideas, very few of 
which are original.  It owes its origins to a number of good ideas like 
RMX, DMP, etc.  Its users ought to be grateful to those intrepid inventors 
such as yourself, and you, Gordon, Andrew Church, Paul Vixie and others who 
came up with great ideas ought to be proud of yourselves.

However, the success of SPF is not built on ideas alone.  The success of 
SPF is built on hard work.  It takes hard work to create running code for 
MTAs.  It takes hard work to have discussions with stakeholders and make 
decisions on what to change.  It takes hard work to create web pages and 
revise them.  And it takes hard work to evangelize and market the great 
ideas so that people will be compelled to try something different and a bit 
risky.  Talking to reporters is also hard work.  Just having a great idea 
is not enough -- if the problem of forgery could be solved by brilliant 
minds thinking about it, it would be solved already and we would not be on 
this list.  But there comes a time in the life cycle of a great invention 
when *someone* starts digging the trenches.

So, if you and Gordon are the fathers of modern LMAP, Meng Weng Wong is its 
mother.  Of course you care about the little LMAP, but are you willing cook 
and clean for it and change its pants?

THAT is why I have a great deal of respect for SPF and for Meng 
specifically.  He has taken a handful of really good ideas and turned them 
into a PRODUCT which can be marketed and sold.

> Nothing but a slightly changed syntax. If we don't stick to SPF syntax,
> what will remain of the SPF hype? Roughly nothing. That's the reason why
> so many people desperately defend SPF syntax against any progress. They
> try to enforce SPF syntax, because that's all SPF consists of.

I agree that some SPF supporters are having an emotional reaction to XML. 
However, your emotional reaction to SPF is equally irrational.  Can you 
definitely say beyond a doubt that you support XML for well-considered 
logical reasons, and NOT because you have an emotional investment in seeing 
SPF fail?

Let's get everything on the table and let's all be clear about our agendas. 
My agenda here is not to push SPF syntax on people, though I admit that I 
like SPF syntax and I have a negative reaction to XML because I think it's 
the wrong tool for the job, but I'm willing to be proved wrong and if XML 
is the end result of this group, I will support it, because I think MARID 
is more important than its syntax and can succeed even with a bad choice of 
syntax.

I am willing to set aside my emotional reaction, BUT, if we are trying to 
sell MARID to ordinary users, we MUST take their emotional reaction into 
account.  If we produce a wonderful, architecturally sound, technological 
marvel and people don't want to adopt it, how would people like that 
outcome?

...
> with in context of DNS, whether you like it or not.

It's a wonderful idea and we should strongly consider that.  I would prefer 
the TXT to be human-readable and the new RR type that we create to be 
binary... would that work for you?

Of course we would have to update the dns tools to display the data 
correctly, but that can be done at the same time as the new RR is added. 
Plus, we can tell the DNS server what additional records to serve along 
with it, etc.

The only drawback there is, what if the DNS tools don't understand the new 
binary format, when it comes time to revise things?  Can we come up with a 
binary format that is as flexible as XML?

...
>
>   Important is that we have two representations, but only   a *single*
> encoding. Only one type of DNS records. That's it.   SPF or XML is not a
> matter of the record itself. It's a matter   of the program you use to
> display the record.
>
...
> are bound to store MARID records in DNS (if not, see RMX++ proposal).

Excellent idea.  Let's move forward with that.

What would you think about, for ease of deployment pre-bind-10, maybe 
having the TXT record be SPF format and the _ep record being XML format? 
I'm just concerned that people will not be able to type binary into their 
zone files.

Thanks again
gregc

---

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

Greg Connor wrote:

> having the TXT record be SPF format and the _ep record being XML 
> format? I'm just concerned that people will not be able to type binary 
> into their zone files.

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):

MARID records in DNS should be encoded as raw bit/byte sequences. I would
keep the encoding out of the DNS internals. If it has not structure, then
DNS relays and caches do  not have to de- and reencode (what they do,
why I had to learn that my early RMX proposals, which made use of
DNS compression, would not work). Keeping the record opaque for
DNS internals keeps the processing overhead low.

There should be a canonical encoding, where you are able to
write the MARID as a base64 encoded string into the zone file.
This gives you the ability to generate the record with any program
of your choice and to encode things which are not yet part of the
SPF or XML or whatever representation.

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.

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.

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.

regards
Hadmut

---

From: Greg Connor <[email-masked]>
Date: Wed, 23 Jun 2004 12:56:08 -0700

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

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

> a perl script to encode new record types.

Good stuff.  Thanks.

---

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

>will it take until there's MARID data to exploit it?  Minutes, I'd

Yes, using XML exposes you to risks associated with possible faults in code
used to parse XML. I don't think anyone will deny this. My issue was with
the alleged magnitude of this risk. Suppose, for instance, that resolving
of external entities is never undertaken when parsing MARID-XML. So the
library code that supports this should never be executed. Hence the
MARID-XML parser is likely to be immune to exploits based on faults in this
particular code, no matter what bizarre document an 'attacker' publishes.

I'm sure it would be possible to estimate the XML library code coverage
obtained with MARID XML, look at the bug history of your library, and come
up with a good guess for the risk. I'd guess it's likely to be somewhere
between zero and 100% :-)
There's also the question of what the consequence of such a fault would be?
DOS? Spam from the attacking domain? Something worse?

Something like SPF-original might be done with a small and proven parser.
So the XML-associated risk is avoided, but at what cost?

Of course, the only way for recipients to avoid all risk in processing
MARID is not to do it. You make a strong argument for publisher execution
of the MARID statement.

---

From: Greg Connor <[email-masked]>
Date: Wed, 23 Jun 2004 16:47:28 -0700

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 <[email-masked]> wrote:

> 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:
>>
> 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.
>
>
>> is marked critical or not (see my former posting). Non-critical
>> extensions allow slow upgrades. Or even no upgrades.
>>

---

From: Aredridel <[email-masked]>
Date: Wed, 23 Jun 2004 18:35:37 -0600

> (extensibility, economy, etc).

Quick sanity check: Any preliminary measures on the savings in such a
format?

I did a couple checks, but because we're dealing with basically textual
information (domain labels) and such small packets, not much is saved in
encoding the non-domain-label information more tightly, and gzip is
ineffective on such small blocks. Even the XML overhead didn't affect it
much.

Ari

---

From: Robert Barclay <[email-masked]>
Date: Wed, 23 Jun 2004 18:52:23 -0600

Greg,
I agree that this sounds like a workable plan. This along an extremely 
similar line of thinking as what led me to my compromise proposal sent 
this morning. You have however expressed many of the points much more 
clearly. I have a few comments below where I believe a slightly 
different path is at least worthy of discussion.

Greg Connor wrote:

> input, the DNS format transmitted over the wire is a binary encoding.  
> MTAs need to understand the binary and that's it.

Works for me. But since even in the current XML most records are still 
smaller than 512 bytes it would probably be worthwhile to explore 
exactly how much network traffic this really saves if for no other 
reason than to enhance the sales pitch to DNS admins who now have to 
create these records.

> they do, you can enter either SPF or XML text in the zone file.  DNS 
> tools like dig can display one or both formats.

Is this implying that DNS servers should store both formats and 
selectively translate them to their binary representation or that if the 
DNS server is doing the translation it is up to tools like dig and 
nslookup to do the translation back to human readable?

> 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 would suggest that since in your proposal TXT is used as transitional, 
and in mine the TXT is used for experimental new extensions that it 
would not be unreasonable for that record to support both formats, 
especially since as soon as their MTA and DNS software support it a 
system can use the standardized, binary formatted MARID record directly.

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

I think the success of this group in creating a standard will depend on 
all of the various stakeholders being willing to compromise and do a 
little more work than they might strictly like to. The above approach 
seems reasonable to me.

This is just my two cents. Thanks for the clear write up.

To the group in general I will say that while I was a bit disheartened 
over the last few days over the heated and sometimes circular 
discussions, the willingness to compromise which I have seen today has 
done a great deal to raise my hopes again.

Thanks,

Robert

> 
> Hadmut's previous message any my previous reply follows here (in case 
> you were ignoring the other thread :)
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2004 18:37:04 -0700

> (extensibility, economy, etc).

Perhaps rather than just a single new record type, consider defining a
structure composed of new elements where each element is a record type.

1) An address type for CIDR notation for IPv4 and IPv6 addresses.

2) Inverse of the SRV record having a 16 bit field for encoding the
protocol being authorized and a name type used to return referenced CIDR
notation.  Add to this a 16 bit field to declare policy information. 
Allow the protocol field to be used as a selection field.  (Redefine
Class perhaps.)

3) A type of PTR record to build external reference lists with a
matching protocol field to the inverse SRV record also for selection.

This would allow these new records to find greater use than just for
MARID.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 23 Jun 2004 19:16:40 -0700 (PDT)

> matching protocol field to the inverse SRV record also for selection.

Maybe we should consider just reusing existing PTR record since it has
no defined meaning and use for domains (only meaning is for IN-ADDR tree)?

And if we need something more advanced, I already wrote how NAPTR records
may possibly be used for similar purposes and they are kind of like more 
enhanced and universal PTR.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2004 22:02:24 -0700

> enhanced and universal PTR.

I was adding this to employ an additional select mechanism to allow a
common record type to be used by more than one protocol while avoiding
the problem of special labels as related to wild cards.  If such a
select field could be added to the inverse SRV record, then having the
same mechanism would be helpful for a PTR type of record.  It may even
be helpful to add a new SRV record with this feature for the same
reasons.  Okay, this makes 5 new record types.

-Doug

---

From: "Michael R. Brumm" <[email-masked]>
Date: Thu, 24 Jun 2004 04:47:41 -0600

Michael R. Brumm wrote:
>Obviously, the best technical solution would be a binary 
>representation in a newly allocated RR type. However, this is not a 
>practical solution for at least two more years. It really is too bad 
>that RFC 3597 did not come out much earlier.

>RMX was and is a binary representation in a newly allocated RR type.

You are welcome. Now, if only we can concur on the fact that the best technical solution is not viable for several years because most DNS libraries, clients, sanitizers (firewalls, etc), and servers do not support unknown RR types.

SMTP authorization cannot wait for RFC 3597 to be widely deployed. People will not wait this long. Spam is an ever increasing burden on everyone from the postmaster down to the end-user. I'm sure I don't even have to mention this.

Hadmut Danisch wrote:
>little bit more than one year old. The SPF circus caused a severe 
>delay in the evolution of such a mechanism, a delay of about a year 
>right now. SPF was the idea to use plaintext in TXT records.

The "SPF circus" hasn't delayed the adoption of RFC 3597, and RMX has not significantly increased the adoption rate of RFC 3597. In any case, the date of RFC 3597 is "September 2003", which is less than 10 months ago. I don't see how we can expect anything as incredibly large-scale as SMTP authorization to be built on something that is so young and not widely implemented.

>representation in a newly allocated RR type, as RMX proposed from 
>the very beginning, but we can't do this anymore because we now lack 
>that time we've lost through the SPF circus proposing a different way 
>that you now consider as worse?

I don't see how we've lost any time to the "SPF circus". SPF and RMX haven't affected RFC 3597 deployment; it's been the other way around. SPF is being adopted and deployed precisely because it can be (right now) in TXT records, while RMX was hindered due to its RR type requirement.

The fact that we have a working solution now (SPF syntax in TXT records) doesn't prevent us from transitioning to an RR type in the future. I could be wrong, but I think that most of the SPF community would expect that a new RR type would eventually be allocated, and that use of the TXT record would be depreciated. What we object to is the idea that a new RR type should be immediately required and the TXT record immediately abandoned. This would prevent further adoption, and disenfranchise the large base of early adopters.

Michael R. Brumm

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 24 Jun 2004 17:51:53 +0200

>I don't see how we've lost any time to the "SPF circus". SPF and RMX haven't affected RFC 3597 deployment; it's been the other way around. SPF is being adopted and deployed precisely because it can…

I see three arguments in your posting: RFC3597, RFC3597, and RFC3597.

This issue had been discussed in ASRG and several mailing lists about a 
year ago, and had been considered
to not be a real problem, because most DNS servers already are able to 
forward unknown RR types.
RFC3597 is not a new invention, merely a description of a status quo 
already reached with newer
DNS servers. (I didn't  find this discussion yet in my RMX mail 
archives, because they are several
hundreds of megabytes)

BTW, this discussion was the reason why I had to drop the DNS domain 
name compression from
earlier drafts of RMX: I had made use of the domain name compression 
described in DNS in
my test implementation and it had good results depending on the RMX 
entry type (obviously
for those entry types containing a DNS name).

I received a hint from a DNS working group that this won't work. Guess why!

Because DNS name compression works only if every DNS relay is able to 
decode and
reencode the RR type. This compression method does not work if the DNS 
server
is forwarding the record without modification. And that's the problem: 
Most modern
DNS server already do forward unknown RR types, but due to the fact that 
they
are unknown,  the DNS servers can't de- and reencode them. Probably it 
was that
discussion about RMX records why it is stated explicitely in RFC3597 to 
not use
DNS compression for new record types. This problem would not have 
occured if
DNS servers would drop unknown types.

So I had to drop the compression from the draft just because too many 
DNS servers
already are forwarding unknown RR types, therefore a new RR type cannot 
be invented
with DNS compression.

And, btw, I made some tests with an RMX implementation, were at least the
DNS servers involved in the tests were forwarding the RMX records even
without beeing patched.

So the RFC3597 argument is not a good argument (all three of them).

Hadmut

---

From: "Hadmut Danisch" <[email-masked]>
Date: Thu, 24 Jun 2004 18:01:40 +0200

Hadmut

---

From: Sean Comeau <[email-masked]>
Date: Fri, 25 Jun 2004 15:22:23 -0700

> Specifically, they can't query for a new RR type when behind an ISA

The reason is because BIND needs to be upgraded to support a new RR
and that will take a lot more time and effort than just using something
deployed nameservers can use. 

I don't think that the broken behaviour of one particular firewall is a
compelling reason not to use a new record type.