In
<81AC085044D04B429F5FB883D94FA1AF42A3D2(_at_)df-fido-msg(_dot_)exchange(_dot_)corp(_dot_)microsoft(_dot_)com>
"Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
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.
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.
I was making yet another point: The slash char has already been usurped
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.
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.
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