Mailing List Archive

On Tue, Jun 08, 2004 at 10:12:28AM +0100, Gary Levell wrote:
|
| I'm in the process of building SPF & CallerID support into our email add-on product Exclaimer.
|

You should probably also subscribe to
http://www.imc.org/ietf-mxcomp/index.html to stay on top of
recent developments --- the SPFv1 protocol is at the core of
the new MARID "Sender-ID" spec now under construction.

|
| The problem lies in one of the tests whose SPF policy is
|
| v=spf1 a:/x32.com//12 a
|

that looks really weird to me. it doesn't look right. where
is that test found?

| From the ABNF spec the A mechanism is defined at:
|
| A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
|
| The test
|
| spftest spf "v=spf1 a:/x32.com//12 a"
| rec-in /.*/ SPF record in: v=spf1 a:/x32.com//12 a
| err-msg /.*/ no errors
| rec-out-auto /.*/
|
| seems to indicate that this would parse correctly yet I don't see how the /x32.com can be the domain-spec and not the IPv4 cidr-len. Is the / ignored when parsing the domain-spec?
|

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <F8613B5F9C388242BDABF11AF6ED123F69F7FC@MAIL1.dcsl.local> "Gary Levell" <gary@exclaimer.net> writes:

> As part of that job, I've been testing (like all good developers !)
> my implementation (which is from the May 16 SPF internet draft
> spec). I've built many of my own tests and also I'm attempting to
> incorporate all the good work done by Wayne from midwestcs.com but
> in doing so I've come across something that I don't understand. Can
> someone shed some light for me?

I would be very interested in any tests that you might be able to
release. The more tests, from more people, the better.


> The problem lies in one of the tests whose SPF policy is
>
> v=spf1 a:/x32.com//12 a
>
> From the ABNF spec the A mechanism is defined at:
>
> A = "a" [ ":" domain-spec ] [ dual-cidr-length ]

It seems to surprise many people, but "/" is a valid character in an
internet domain name. It is not valid as a host name, but that is a
slightly different issue. So, for example, a domain owner could
create an entry in their DNS system with something like
"london/18.foo.com" with a list of all the MTAs in the London office's
/18 CIDR block.


> seems to indicate that this would parse correctly yet I don't see
> how the /x32.com can be the domain-spec and not the IPv4
> cidr-len.

This is correct.



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <20040608183351.GL2112@dumbo.pobox.com> Meng Weng Wong <mengwong@dumbo.pobox.com> writes:

> | The problem lies in one of the tests whose SPF policy is
> |
> | v=spf1 a:/x32.com//12 a
> |
>
> that looks really weird to me. it doesn't look right. where
> is that test found?

Yes, it is designed to look weird. As far as where the test is found,
see the subject line.


To the best of my knowledge, you have never run the updated SPF test
suite on your perl implementation.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Wayne,

I'd be happy to share my tests with the SPF community. They are really a comprehensive set of tests much like your existing parser, macro, mechanism, modifier & adoption examples. We've written tests to push the boundaries of our implementation and also exercise all of our code paths. I'm really grateful for your tests as they highlighted several problems in my implementation which caused me to stop and re-evalulate my approach (specifically w.r.t recursion & DDOS attacks via a maliciously forms SPF policy) - Thanks!

Our implementation is designed to run on Win2K and above and is written as a COM component so we can (in future) wrap it with a .NET managed class.

Because of this, our test program is basically an HTML page that contains a large XML document which lists all the tests, their inputs and expected outputs and a snippet of script to automate the COM object and hand the test data over to it - no different from your perl tests really.

I've converted most of your tests to this XML document. As you probably know, a simple XSL file could be written to transform the XML back to your .pl files, or to anyone elses' favourite scripting language ready for their tests to run.

The advantage of using XML for the tests is that it is platform neutral, language agnostic, human readable and machine parseable (not that this is a plug for storing SPFv2 in XML you understand :-> ). There are also many parsers, editors and transformers for it available on all platforms, which to my mind makes huge sense when dealing with a spec that now spans the entire internet community and all it's platforms.

-Gary



This message (and any associated files) is intended only for the use of spf-devel@v2.listbox.com and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not spf-devel@v2.listbox.com you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Any views or opinions presented are solely those of the author gary@exclaimer.net and do not necessarily represent those of the company.

This disclaimer was added by eXclaimer for Microsoft Exchange 2000, a DCSL product. Please visit our web site at www.exclaimer.co.uk for more information.

-----Original Message-----

From: owner-spf-devel@v2.listbox.com on behalf of wayne
Sent: Tue 08/06/2004 20:35
To: SPF Development
Cc:
Subject: Re: [spf-devel] Question about spf tests on http://www.midwestcs.com/spf/tests/



In <F8613B5F9C388242BDABF11AF6ED123F69F7FC@MAIL1.dcsl.local> "Gary Levell" <gary@exclaimer.net> writes:

> As part of that job, I've been testing (like all good developers !)
> my implementation (which is from the May 16 SPF internet draft
> spec). I've built many of my own tests and also I'm attempting to
> incorporate all the good work done by Wayne from midwestcs.com but
> in doing so I've come across something that I don't understand. Can
> someone shed some light for me?

I would be very interested in any tests that you might be able to
release. The more tests, from more people, the better.


> The problem lies in one of the tests whose SPF policy is
>
> v=spf1 a:/x32.com//12 a
>
> From the ABNF spec the A mechanism is defined at:
>
> A = "a" [ ":" domain-spec ] [ dual-cidr-length ]

It seems to surprise many people, but "/" is a valid character in an
internet domain name. It is not valid as a host name, but that is a
slightly different issue. So, for example, a domain owner could
create an entry in their DNS system with something like
"london/18.foo.com" with a list of all the MTAs in the London office's
/18 CIDR block.


> seems to indicate that this would parse correctly yet I don't see
> how the /x32.com can be the domain-spec and not the IPv4
> cidr-len.

This is correct.



-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
--------------------------------------------------------
SpamChecked by eXclaimer on MAIL1

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Tue, 2004-06-08 at 17:23, Gary Levell wrote:
> Wayne,
>
> I'd be happy to share my tests with the SPF community.

Sharing is always welcome.

> They are really a comprehensive set of tests much like your existing parser, macro,
> mechanism, modifier & adoption examples. We've written tests to push the boundaries
> of our implementation and also exercise all of our code paths. I'm really grateful
> for your tests as they highlighted several problems in my implementation which
> caused me to stop and re-evalulate my approach (specifically w.r.t recursion
> & DDOS attacks via a maliciously forms SPF policy) - Thanks!

They sound interesting I shall have a look.

> Our implementation is designed to run on Win2K and above and is written as a
> COM component so we can (in future) wrap it with a .NET managed class.

I would recommend against that. By doing so you limit your work to a
single group of people. A significant portion of the Internet runs on
*nix based systems, and by that as a result so are MTA's.

> Because of this, our test program is basically an HTML page that contains
> a large XML document which lists all the tests, their inputs and expected
> outputs and a snippet of script to automate the COM object and hand the
> test data over to it - no different from your perl tests really.

Ok.

> I've converted most of your tests to this XML document. As you probably
> know, a simple XSL file could be written to transform the XML back to your
> .pl files, or to anyone elses' favourite scripting language ready for their
> tests to run.

I move that time is better spent doing it right once the first time.
Whilst I can appreciate that you are clearly a windows programmer, and
that despite your good intentions, and the validity of the above
statement, it makes a lot more sense to simply describe the tests in an
identical fashion to existing SPF1 records.

Any offline document IMO should simply be a big TEXT file of DNS
records. Its not an overly complex task to describe the outcome of each
of these records using simplistic key/value pairs.

> The advantage of using XML for the tests is that it is platform neutral,

That would be more true if there was actually an XML parser that didn't
crap all over its self,leak memory, be horribly written, SEGV left right
and center, be prone to exploitation, fully implement its goal, and
wasn't larger than a bloody MTA!

> language agnostic, human readable and machine parseable (not that this

Thats a tough one. I for one won't be reading any books written in XML
anytime soon, in fact, having to edit an icecast configuration file
expressed in XML made me want to tear my eyes because I would have had a
better chance of working that file successfully if I were blind.

> is a plug for storing SPFv2 in XML you understand :-> )

Fair enough, thank goodness you said that. I was beginning to loose all
hope.

> . There are also many parsers, editors and transformers for it available
> on all platforms, which to my mind makes huge sense when dealing

Which all suck, crash, bloat, puff, crap, implode, improperly implement
their goal, etc... etc.. and so on into the night.

> with a spec that now spans the entire internet community and all it's platforms.

Pardon my French here ladies and gentlemen, but fuck that! Thats
complete nonsense. XML is "meh". It has its place, this much is true,
much like any tool. HOWEVER, XML has no place in SPF, and most
certainly NO place in DNS.

The SPEC quite perfectly spanned the entire smegging internet community
and all its platforms without XML thank you. I strongly urge you to
re-evaluate the SPF syntax and you will find that not only is it
extensible, but its compact, it actually IS human readable, AND !! *KEY
POINT HERE* !! its safe to put into DNS. Why? Because AOL can describe
their ENTIRE network inside of a SINGLE DNS record. Now thats fucking
impressive. You show me that with your precious XML crap and I'll sing
Hit me Baby One more Time in a fucking Diaper in the middle of rush hour
with a bumper sticker professing my love for XML.

Now that being said, I seem to have slipped into an angry undertone...
I'm sure everyone here appreciates your work, and if not at the very
least not only your effort, but that you took the time to share it.
Don't take me too seriously, but please don't preach XML in here, I'll
end up vomiting everywhere. XML is the WRONG tool for the job here.
You can twist and manipulate it all you please, but its like telling
everyone you drive Boeing 747 to work because its got wheels and it gets
you from A to B. However true or possible that is, its completely
nonsense to do it.

Cheers,

James

--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Gary,

On Tue, 2004-06-08 at 17:23, Gary Levell wrote:

> I'd be happy to share my tests with the SPF community.
> They are really a comprehensive set of tests much like
> your existing parser, macro, mechanism, modifier & adoption
> examples. We've written tests to push the boundaries of our
> implementation and also exercise all of our code paths. I'm really
> grateful for your tests as they highlighted several problems in

-- snip

Let me apologize for the tone of my previous message. I don't mean to
come across as rude as I did. Its exceptionally hard to continue to
read posts such as yours. Its just going to happen over and over and
over, so instead of freaking out at people in here, I'm going to go work
on a "Why XML is WRONG" document, and I'm going to refer everyone to
that instead. So please accept my apology and understand that XML has
no place in SPF or DNS and thats all that really needs to be said. I
hope I haven't put you off further contributions to this project.

Until said document is complete I strongly urge that you put any bias
aside and go give: http://c2.com/cgi/wiki?XmlSucks a good read, or
perhaps: http://www.crockford.com/JSON/index.html and specifically on
that site: http://www.crockford.com/JSON/xml.html

Sincerely,

James

--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Wed, 9 Jun 2004, Gary Levell wrote:

> I've converted most of your tests to this XML document. As you probably
> know, a simple XSL file could be written to transform the XML back to
> your .pl files, or to anyone elses' favourite scripting language ready
> for their tests to run.
> The advantage of using XML for the tests is that it is platform
> neutral, language agnostic, human readable and machine parseable (not
> that this is a plug for storing SPFv2 in XML you understand :-> ). There
> are also many parsers, editors and transformers for it available on all
> platforms, which to my mind makes huge sense when dealing with a spec
> that now spans the entire internet community and all it's platforms.

Of course you have the advantage that the semantics of these tests are
well understood. XML as a syntax has all the advantages you list, but
without semantics, it's useless. This throws SPFv2 into quite a bad light.

This is shamelessly off topic for the thread but it amused me.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com