Subject: RE: On Extensibility in MARID Records

From: "Jim Lyon" <[email-masked]>
Date: Wed, 16 Jun 2004 23:19:58 -0700

Wayne,

I had somehow missed the message you reference. It actually makes a
different point: SPF syntax like
  +a:foo.com/24 is already broken because it's not (syntactically)
obvious whether the domain is foo.com or foo.com/24.

I was making yet another point: The slash char has already been usurped
by SPF syntax for something other than extensions.

I also had not been aware of the details of the SPF report extension.
Now that I'm aware, I agree that it's useless.  The concept isn't
useless, but that particular expression of it is.  It's also hard to
implement -- asking MTAs to keep running counters for each triple
(domain,senderIP,receiverIP).

People who want the feedback actually need to see a sampling of the
actual messages.

-- jimbo

---

From: wayne <[email-masked]>
Date: Thu, 17 Jun 2004 08:07:24 -0500

> obvious whether the domain is foo.com or foo.com/24.

Well, "broken" is probably an overstatement.  The BNF in the SPF spec
makes it unambigious, CIDR notation must be the *final part* of the
token.  There will only be a conflict if there comes a day when there
are top level domains such as "com/24".  If such TLDs are created, you
will need to use "a:foo.com/24." instead.  While things like
"adsl/18.foo.com" are valid domain names, they aren't valid host
names, and thus I think it is pretty unlikely that such TLDs will be
created.

> by SPF syntax for something other than extensions.

I guess it is all how you look at it.  My point was that slash is
reserved for use in host names, with a special case for CIDR
notation. 

It doesn't make much difference.  All the creative talk about how to
tag mechanism is irrelevant for SPFv1.  You simply can not do it.  You
must think in terms of modifiers instead, but it is important to
remember that modifiers are position independant and the spec
recommends that you place them at the end.

> People who want the feedback actually need to see a sampling of the

I think it is extremely unlikely that mail admins will send samples of
actual messages to anyone, unless it is in a *very* controlled
manner.  The privicy and mailbombing implications rule it out.

SPF already has a logging technique that is in use:
  "v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all"

As you pointed out during the interim meeting, this can give
inaccurate results because legitimate SPF implementations may not do
the DNS lookups when you expect them, but also because others can do
DNS lookups any time they want to skew the results.

These same problems occur with all the reporting techniques mentioned
so far.  Not only is it foolish to send reports to random email
address specified by third parties, but it is foolish to trust the
reports you get.

-wayne