wayne wrote:
There is no "MAY" in section 4.6.
| Implementations MAY choose to parse the entire record first
| and return "PermError" if the record is not syntactically
| well formed.
"k$" is not well formed, but "foo" is.
There is no reason that there shouldn't be a "MUST" saying,
requiring all syntax errors to be detected.
There's also no reason why an implementation shouldn't parse
the sender policy left to right, and evaluate the tokens in
this order. It's really a minor problem, and it's consistent
with draft-mengwong-spf-01.txt
It is not at all theoretical because of all the typos and
bogus stuff in SPF records. Yes, in theory, this is a
theoretical problem, in practice, it is a practical problem.
LOL, okay. Let's say that this problem cannot be solved in
draft-lentczner-spf-00, but maybe in draft-01, or in his 48
hours. If I understand you correctly you want to reverse the
MUST 7.1 and MAY 4.6 somehow: An implemetation MAY accept
stuff until it finds clear nonsense which isn't a modifier,
but SHOULD reject all bogus mechanisms even if they're never
evaluated.
The practical result of allowing unknown modifiers is a less
reliable SPF system.
I read s/modifiers/mechanisms/ here, correct me if I'm wrong.
And yes, that's true, as we see for numerous "common mistakes".
Getting rid of this problem in the spec is (among others) an
editorial problem. And if Mark changes 4.6 and 7.1 somehow,
then this won't automagically fix all "common mistakes". It's
also a problem for the FAQ(s), wizard(s), validator(s), and
test suite(s).
The most pressing problem - now after a new draft exists - is
to get an RfC for existing implementations. Do you really want
to delay this process now ? That's a political question.
Your idea of "validating" implementations is nice, but it's
not absolutely necessary for all existing SPF1 implementations.
Have you read what Meng and Mark have written about unknown
mechanism on this list?
Probably, if it was in May or later. Meng has numerous ideas,
and he's less concerned with syntactical details. One of his
ideas was to allow a:1.2.3.4, and if you'd ask him about your
"prt" and "ipv4" problems I could guess his answer. It would
be different from my or your answer... ;-)
Have you read section 7.1?
Sure. Adding unrecognized mechanisms is impossible without a
new SPF tag. That's what I meant with the joke in my comment:
| Lines 1480-1482: <joke>
| implementation that did not recognize the "foo" mechanism would
| return "PermError". An implementation that did recognize the
| "foo" mechanism would be able to perform an extended evaluation.
|
| In other words the sender shouldn't send mail to receivers which
| have not yet implemented the "foo" mechanism. </joke>
It is a bad idea.
It's not only a bad idea, It's obviously impossible. Unless
you don't care if the same MAIL FROM is rejected by an old
implementation (PermError) but evaluated by new implementations.
I recommend /dev/random coupled with /dev/null for an offline
solution instead of publishing mechanism "foo". Forget it ;-)
There is only one "MUST" in section 7.1, and that deals with
modifiers, not mechanisms and I think it should stay asis.
| Mechanisms listed before the unknown mechanism MUST, however,
| be evaluated.
Are you sure that we're dicussing the same document ?
all of these were posted before you became involved with
MARID, let alone SPF,
It was the other way around, I only asked for write access on
mxcomp when MARID drifted away from XML-over-DNS to lala-land.
I've certainly no problem with limiting the DNS queries instead
of limiting the recursive evaluations or an overall timeout of
20 seconds. It is a good idea.
But before you dig deeper into this issue, there are many other
ideas which never made it into one of the drafts for various
reasons. E.g. the abbreviated CIDR notation proposed here by
somebody from Russia. Scott's HARDPASS idea. My proposal to
delete SOFTFAIL and explanations. Meng's a:1.2.3.4 proposal.
More elaborated HELO ideas (Meng and Hector, but on different
tracks). And so on, including highly controversional stuff.
I do not see any reason to keep reposting stuff like this
every time someone new comes along.
As far as I'm concerned the 20 seconds limit and the limit of
recursions addresses the underlying problem. If you want a
global "DNS query counter" in check_host(), then just say so
resp. make it so.
look through their code and see if a cracker can use the SPF
checks to amplify a DoS attack.
| While these distributed denial of service attacks are
| possible, they seem more convoluted to mount, and have less
| of an impact, than other simpler attacks.
IMHO you don't need SPF to DDoS name servers. But you can try
to use it for this purpose. BTW, add to the list of "ignored"
issues mentioned here: SPF "exists" as a new kind of web bug
in conjunction with logging. How real is this ? Do we need
to discuss this now ?
Been there, done that, was ignored.
Yes, but that's a problem "we" (tinw) all have. And "our" new
shepherd isn't clairvoyant or psychic. It's really difficult
to grab the consensus from a list like this. Just look at the
desastrous MARID outcome. The complete time spent for SPF as
we know it was less than one week, and the complete time spent
for CSV was zero (official time, minus off topic discussions).
The rest of the time was useless XML / IPR / PRA gibberish :-(
But maybe Meng now got the idea that "we" want MAIL FROM. Or
that's what I hope.
Read spf-draft-200406.txt
The d****d wildcard issue was one of my first questions here on
this list, because I was stunned that the sender policy for
claranet.de didn't cover my xyzzy.claranet.de vanity host.
There was never anything near a rough consensus how this could
be solved for subdomains. Some vague ideas like the modifier
"match_subdomains" never made it. You can't expect me to fix
this, because I don't know the necessary DNS details. I don't
know how "point of delegation" or "zone cut" exactly work.
My impression was that it really must be this clumsy: If you
want a sender policy for a domain x.y.z.example then the only
solution is to define a TXT record for x.y.z.example. In some
cases *.y.z.example might do the trick. It would be nice if
that's not the case.
There are people out there with %{h} macros. It was
primarily MS that wanted it removed.
M$ has nothing to do with check_host(), that's an abstraction
invented by Mark, it allows different scopes. We discussed 2
versions of check_host(), the almost "classic" approach with
3 arguments - that necessarily kills %{h}. And a version with
a 4th argument "scope" together with %{e}. Meng's %{e} idea
didn't make it, because it wasn't necessary for your proposal
with a "scope" as part of the tag like say spf2.0/helo.
Now we're essentially returning to spf2.0/mfrom, and <oops>,
the %{h} is lost in space. Mark asked at least three times
what "we" want with HELO, and the outcome was inconclusive.
That's no M$ conspiracy, that's a consequence of the agreed
upon editorial strategy to retrofit the last MARID policy-03
document with spf2.0/mfrom into an updated v=spf1 document.
You are confusing the removal of the %{h} macro with the
removal of the HELO checking.
No, that's just the other side of the same coin. You can't
expand %{h} in a check_host() recursion, if it was never before
initialized.
several of us strong disagree that HELO checking that was
allowed in previous drafts was not useful.
Nobody said that it wasn't useful. "We" only agreed that it
wasn't essential (= it was optional), and IMHO (not "we") it
didn't cover the different ideas proposed by Meng resp. Hector.
Your idea of "SPF1" seems to be based off of much more recent
stuff.
Actually it's based on an early (01) RMX draft. 6 months later
I heard about the AOL experiment, and thought that somebody had
finally implemented and tested RMX. And in March 2004 (IIRC) I
started to lurk in this list. Because nothing happened in the
ASRG lists at this time.
it was removed when Mark became involved again with the
editing the MARID drafts.
Yes, I thought that MARID is about SPF. And the new syntax is
really _much_ better and clearer than in draft-mengwong-spf-01.
+ A limit of 5 MX names MUST be enforced.
More than 5 MX are not unusual, this MUST doesn't fly for me.
+ A limit to checking 5 PTR records MUST be enforced.
Why don't you just count DNS queries instead of these arbitrary
magic numbers ? Unnecessary magic numbers are evil. BTW, many
of your quoted (+) proposals are reflected in the actual draft.
+ the total DNS lookups must be limited.
Yes, that's much better than the utter dubious "5 MX" limit.
+ SPF implementations MUST limit the number of mechanisms
+ that do DNS lookups to at most 10.
Why not 16 or 32 or a similar magic number ? What can be done
in 20 seconds under normal conditions (no DDoS) ?
+ The limit SHOULD be allow the SPF evaluation to last at
+ least 30 seconds.
The actual draft says 20 seconds as smallest upper limit, and
you have 30 seconds as lower limit.
Bye, Frank