Mailing List Archive

In <Pine.LNX.4.44.0609181053380.12582-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> On Mon, 18 Sep 2006, Scott Kitterman wrote:
>
>> that..." isn't justification. The RFC explicitly calls out the cases that
>> get a permerror and this isn't one of them. I wish the RFC were different,
>> but it's not.

I agree with this interpretation of the MX limit. As the RFC is
written, a PERMERROR should not be given.


>> We can't use the test suite to back-door in requirements that aren't in the
>> RFC. I think it undermines the credibility of the test suite.

Agreed. Sadly, that mean that everything in the spec is perfectly
clear though. :-<

> In defense of the majority, let me point out that a permerror result
> is explicitly required for the other limits, the MX limit immediately follows
> the others, and an English speaking reader can reasonably assume the
> permerror result applies to the MX limit as well.

I disagree, paragraphs are generally used to group points or ideas of
discussion. A different paragraph generally means a new point.


When developing these limits for libspf2, I was primarily thinking of
the ptr: mechanism. My understanding is that both djbdns and
Microsoft's DNS system automatically add PTR records when you add an A
record. So, if you have a webserver that supports 1000 virtual
websites, you could easily have 1000 PTR records, and check all of
them for a match would cause problems. In almost all cases, any of
the PTR records will do because they will all point back to same A
record.

The mx: limit was somewhat of a second-thought. I went back and
checked the code for other loops that could cause DoS potential.

Checking the libspf2 code, I see that exceeding the MX limit does not
trigger an error. Like test suites, implementations can not be
considered authoritative. This does, however, confirm my mind set
when I was writing this part of the spec. And, this part of the spec
was written soon after I wrote the libspf2 code in early 2004, but the
patch to the I-D was rejected by Meng. Meng said that he thought that
DoS stuff is something that MARID/IETF should sort out. When I took
over being the SPF I-D editor, I just resurrected that patch and I
didn't put that much more thought into it.


I agree with the sentiment that you should be able to get consistent
results from an SPF check and that ignoring too many MX records runs
counter to this. Had this point been brought to my attention, I would
certainly have seriously considered changing the I-D. (As with the
rest of the I-D, I would certainly have changed it to however the
consensus went.) To the best of my knowledge, no one raised this
point though.

Exceeding the MX limit is not the only way an SPF result can be
inconsistent. If you publish only a TYPE99 SPF-RR, implementations
are free to ignore it and return "NONE". If a ptr: or %{p} fails the
DNS lookup, you can get different results. If you publish an SPF
record that has too many bytes, you may be ignored. I'm sure there
are more.


Can anyone find anywhere that this point was discussed? You may have
to go back to early 2004 when processing limits were first argued
over.

Can anyone point to an SPF implementation that existed in 2004/2005
where too many MX records gave an error?

If we can find references that show that we considered this point,
thought that SPF implementations should give an error and that the
current language in the SPF was clear enough on that point that it
didn't need to be changed, then we can certainly claim that too many
MX records should cause a PERMERROR. I doubt we will find anything
that clear-cut though. :-<



-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

> When developing these limits for libspf2, I was primarily thinking of
> the ptr: mechanism. My understanding is that both djbdns and
> Microsoft's DNS system automatically add PTR records when you add an A
> record. So, if you have a webserver that supports 1000 virtual
> websites, you could easily have 1000 PTR records, and check all of
> them for a match would cause problems. In almost all cases, any of
> the PTR records will do because they will all point back to same A
> record.
>
> The mx: limit was somewhat of a second-thought. I went back and
> checked the code for other loops that could cause DoS potential.

At least with mx-limit, the result of stopping after 10 is (usually)
well-defined thanks to the priority. Although not mentioned in the RFC,
and not strictly necessary for SPF purposes, I am assuming that MX records
should be examined in priority order. With ptr-limit, it is essentially
random whether a ptr mechanism matches when there are more than 10 records
for an IP.

Before someone suggests that I simply leave this test out, I refuse to
leave out a test for a MUST that affects the SPF result. If the RFC
is not clear enough, then let's drag out those mailing list archives
and decide what it really means.

Here are the relevant two paragraphs from rfc4408:

SPF implementations MUST limit the number of mechanisms and modifiers that do
DNS lookups to at most 10 per SPF check, including any lookups caused by the
use of the "include" mechanism or the "redirect" modifier. If this number is
exceeded during a check, a PermError MUST be returned. The "include", "a",
"mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do
count against this limit. The "all", "ip4", and "ip6" mechanisms do not
require DNS lookups and therefore do not count against this limit. The "exp"
modifier does not count against this limit because the DNS lookup to fetch
the explanation string occurs after the SPF record has been evaluated.

When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST
be a limit of no more than 10 MX or PTR RRs looked up and checked.

So, the question is, does "a PermError MUST be returned" apply to the 2nd
paragraph as well as the 1st sentence. And if not, how *should* the SPF
result be computed when there are more than 10 RRs?

The two principal interpretations are:

1) Return permerror when more than 10 MX or PTR RRs are referenced for
a single mechanism.

2) a) Evaluate up to 10 MX RRs in priority order. For duplicate
priorities, select randomly.
b) Randomly select and evaluate up to 10 PTR RRs

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
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 Mon, 18 Sep 2006 11:11:01 -0400 (EDT) "Stuart D. Gathman"
<stuart@bmsi.com> wrote:
>On Mon, 18 Sep 2006, Scott Kitterman wrote:
>
>> that..." isn't justification. The RFC explicitly calls out the cases
that
>> get a permerror and this isn't one of them. I wish the RFC were
different,
>> but it's not.
>>
>> We can't use the test suite to back-door in requirements that aren't in
the
>> RFC. I think it undermines the credibility of the test suite.
>>
>> Feel free to forward this to Julian or the appropriate lists.
>>
>
>Did that. Your opinion is in the minority. (Doesn't mean its wrong.)
>The "some people feel that..." refers to the minority opinion. I didn't
>take a formal poll, however.
>
>In defense of the majority, let me point out that a permerror result
>is explicitly required for the other limits, the MX limit immediately
follows
>the others, and an English speaking reader can reasonably assume the
>permerror result applies to the MX limit as well.
>
>Furthermore, returning a pass, neutral, or softfail, or fail in this case
>goes completely against the spirit of those results.
>
>In defense of the minority opinion, at least the order the MX records are
>checked in is well defined - provided there aren't any leftover cache
records
>(which can cause unstable results for other mechanisms as well) AND that
the
>priorities are unique.
>
>Perhaps a compromise is to have permerror as the preferred result, and
>neutral as an acceptable result. I mean, if the RFC doesn't explicitly
>designate the required result, you can pick anything you want, right?
>
>tests:
> mx-limit:
> description: >-
> there MUST be a limit of no more than 10 MX looked up and checked.
> comment: >-
> While the MX and PTR limits immediately follow a paragraph mandating
> a permerror for exeeding limits, some of the SPF community feel that
> more than 10 MX records should simply be ignored. However, ignoring
> the excess MX records can cause SPF results that are different for
> each query. A permerror is the right response.
> spec: 10.1/7
> helo: mail.example.com
> host: 1.2.3.5
> mailfrom: foo@e4.example.com
> result: permerror
>zonedata:
> mail.example.com:
> - A: 1.2.3.4
> e4.example.com:
> - SPF: v=spf1 mx
> - MX: [0, mail.example.com]
> - MX: [1, mail.example.com]
> - MX: [2, mail.example.com]
> - MX: [3, mail.example.com]
> - MX: [4, mail.example.com]
> - MX: [5, mail.example.com]
> - MX: [6, mail.example.com]
> - MX: [7, mail.example.com]
> - MX: [8, mail.example.com]
> - MX: [9, mail.example.com]
> - MX: [10, e4.example.com]
> - A: 1.2.3.5

IIRC, this same issue applies to the PTR limit.

I guess I would ask if there are other places where we are generating a permerror the that RFC
doesn't explcitly call for it?

As I remember this discussion on these two points (MX and PTR lookup limit) when we were
developing the RFC, this point was specifically addressed and the RFC, by design, does not call
for permerror.

Right or wrong, the test suite needs to support that.

Scott K

-------
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 Mon, 18 Sep 2006, wayne wrote:

> Exceeding the MX limit is not the only way an SPF result can be
> inconsistent. If you publish only a TYPE99 SPF-RR, implementations
> are free to ignore it and return "NONE". If a ptr: or %{p} fails the
> DNS lookup, you can get different results. If you publish an SPF
> record that has too many bytes, you may be ignored. I'm sure there
> are more.

While these results may be surprising, they are well defined, and not random.

But trying to see it your way, I guess your point is that if an implementation
can decide which of SPF, TXT RRs to evaluate, then it can decide which 10 of
1000 PTR or MX RRs to evaluate.

What about requiring implementations to select the 10 lowest priority MX RRs?
Not in the RFC, but it seems obvious.

Otherwise, there is simply no test that can be constructed for MX-limit.
There is already no way to test whether an implementation stopped after
10 PTR RRs, because there is no defined order.

In the SPF/TXT case, I can construct tests. Without a permerror - or at least
an imposed ordering - for mx-limit, there is no test. And this is a big
problem since mx-limit is a MUST that affects the result.

Look at it this way: if someone publishes an SPF record with ptr, and
the IP has 1000 RRs, that record is going to randomly fail. They
need to know that their record, if not technically illegal, is definitely
wrong. They need a permerror. (Though I suppose Wayne's desired behaviour
lets me use SPF to probe how DNS servers order PTR RRs in their responses.)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
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 <Pine.LNX.4.44.0609181246450.13308-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> At least with mx-limit, the result of stopping after 10 is (usually)
> well-defined thanks to the priority. Although not mentioned in the RFC,
> and not strictly necessary for SPF purposes, I am assuming that MX records
> should be examined in priority order.

I don't see any particular reason why SPF implementations should pay
attention to the MX priority. The priority is for receiving email, it
seems quite likely to me that priorities for outbound email are quite
different.


> Before someone suggests that I simply leave this test out, I refuse to
> leave out a test for a MUST that affects the SPF result. If the RFC
> is not clear enough, then let's drag out those mailing list archives
> and decide what it really means.

I've been pondering how you can check the mx: and ptr: limits, and I'm
not sure if you can, just by checking the SPF result.


There are other "MUST"s in the RFC that will be hard to check too,
such as stuff relating to the exp= text and the Received-SPF header.

An example that is closer to the processing limits is the requirement
from section 4.5 that says:

If no matching records are returned, an SPF client MUST assume that
the domain makes no SPF declarations. SPF processing MUST stop and
return "None".

How can you prove, via the SPF result, that an implementation didn't
actually continue processing stuff and then throw out the results and
return "None"?




> Here are the relevant two paragraphs from rfc4408:
>
> [stuff from section 10.1 snipped]

There is also section 5.4 that says, in part:

To prevent Denial of Service
(DoS) attacks, more than 10 MX names MUST NOT be looked up during the
evaluation of an "mx" mechanism (see Section 10).

Again, no mention of PermError


> So, the question is, does "a PermError MUST be returned" apply to the 2nd
> paragraph as well as the 1st sentence.

I don't think so.

> And if not, how *should* the SPF
> result be computed when there are more than 10 RRs?

Only 10 MX records should be checked. Which ten is undefined.


-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 <Pine.LNX.4.44.0609181551390.15693-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> Otherwise, there is simply no test that can be constructed for MX-limit.
> There is already no way to test whether an implementation stopped after
> 10 PTR RRs, because there is no defined order.

I've continued to ponder how we can test that an SPF implementation
doesn't check more than 10 MX records. I still can't think of a
perfect test, but here is an idea about how we might get a crude
approximation. It won't check to make sure that no more than 10 MX
records are checked, and it won't always work, but I'm guessing it
will give pretty good results.


Say we have a domain with more than 10 MX records. Say it has 13,
which is about the max I remember being able to fit in a single UDP
DNS packet. If we evaluate an mx: mechanism and the IP address of the
SMTP client is within the 10 that we choose to check, then the
evaluation stops with a match. If the 10 MX record limit is enforced,
then maybe 3 out of 13 times, this check should not match.

We want to increase the probability to something much higher than 3
out of 13, if we can. Three out of 13 is 23% which isn't too bad, in
and of it self.

OK, so, some DNS resolvers will always return a RRset in the same
order, but most will return them in round robin order. A few
(djbdns?) may randomize the set. In order to make things a little
more deterministic, we can set the TTLs down to zero seconds so that
things are a little more consistent.


OK, so we want to create a single SPF check that checks many such
domains with 13 MX records and make sure that at least one of the mx:
checks does *not* match.

Try 1:

mxlimit TXT "v=spf1 include:_m1.%{d} -all"
hit.mxlimit A 192.0.2.1
miss.mxlimit A 192.0.2.2

_m1.mxlimit TXT "v=spf1 -mx:_m1.%{d} +all"
_m1.mxlimit 0 MX 10 hit.mxlimit
_m1.mxlimit 0 MX 10 miss.mxlimit
_m1.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 10 times ...

Ok, with this SPF setup and the connecting STMP client IP address of
192.0.2.1, we will get a PASS if hit.mxlimit is *not* one of the ten
MX records that is checked. Inside the included record, _m1.mxlimit,
if the IP address does *not* match, then it will continue to the +all
and the include:_m1.%{d} will succeed, but if the IP address *does*
match, then the included SPF record will return FAIL, which will cause
the include: to not match.

Note that the 0 in front of the MX is the TTL, so these MX records
should not be cached.

Messy, but let's try with a bunch more include statements:

Try 2:

mxlimit TXT "v=spf1 include:_m1.%{d} include:_m2.%{d} include:_m3.%{d} include:_m4.%{d} include:_m5.%{d} -all"
hit.mxlimit A 192.0.2.1
miss.mxlimit A 192.0.2.2

_m1.mxlimit TXT "v=spf1 -mx:_m1.%{d} +all"
_m1.mxlimit 0 MX 10 hit.mxlimit
_m1.mxlimit 0 MX 10 miss.mxlimit
_m1.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 10 times ...


_m2.mxlimit TXT "v=spf1 -mx:_m2.%{d} +all"
_m2.mxlimit 0 MX 10 miss.mxlimit
_m2.mxlimit 0 MX 10 hit.mxlimit
_m2.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 10 times ...


_m3.mxlimit TXT "v=spf1 -mx:_m3.%{d} +all"
_m3.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 10 times ...
_m3.mxlimit 0 MX 10 hit.mxlimit
_m3.mxlimit 0 MX 10 miss.mxlimit


_m4.mxlimit TXT "v=spf1 -mx:_m4.%{d} +all"
_m4.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 10 times ...
_m4.mxlimit 0 MX 10 miss.mxlimit
_m4.mxlimit 0 MX 10 hit.mxlimit


_m5.mxlimit TXT "v=spf1 -mx:_m5.%{d} +all"
_m5.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 6 times ...
_m5.mxlimit 0 MX 10 hit.mxlimit
_m5.mxlimit 0 MX 10 miss.mxlimit
... the miss.mxlimit MX record repeated another 6 times ...


Ok, if I've done this right, there will be 10 SPF mechanisms, which is
the max we can do. We check to see if SPF implementation ignores the
either of the first 2 entries, either of the last 2 entries, or the
middle entry. Even if the DNS resolver ignores the 0 TTL and the
RRset goes through a few round-robin rotations, the hit.mxlimit can't
be in all of the RRsets. The only way this check can fail is if the
DNS resolver randomizes the RRsets and you just happen to get
unlucky. The chances of getting unlucky is (1 - 3/13)^5 = 27%, that
is, we should still get the right answer 73% of the time.


Yeah, this is *ugly* and not perfect, but it might work reasonably
well.


-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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne Schlitt wrote:
> Stuart D. Gathman writes:
> > At least with mx-limit, the result of stopping after 10 is (usually)
> > well-defined thanks to the priority. Although not mentioned in the
> > RFC, and not strictly necessary for SPF purposes, I am assuming that
> > MX records should be examined in priority order.
>
> I don't see any particular reason why SPF implementations should pay
> attention to the MX priority.

Agreed. The spec says nothing about MX priorities, not even between the
lines.

> [...] There are other "MUST"s in the RFC that will be hard to check too,
> [...]
>
> An example that is closer to the processing limits is the requirement
> from section 4.5 that says:
>
> If no matching records are returned, an SPF client MUST assume that
> the domain makes no SPF declarations. SPF processing MUST stop and
> return "None".
>
> How can you prove, via the SPF result, that an implementation didn't
> actually continue processing stuff and then throw out the results and
> return "None"?

This is a Schrödinger's cat in a box. From the outside, it really doesn't
matter.

As long as the effect is equivalent to what's described in the spec, an
implementation can do whatever it wants. It can even implement the game
of Tetris (e.g. using a new "tetris=" modifier) and still be SPF
compliant.

About whether exceeding the processing limits should always cause a
PermError, or only in exactly those cases where the spec literally demands
it... Wayne, you're having way too much fun picking the flaws in your own
spec. ;-) To make a long story short, I'm firmly in the "always
PermError" camp. I'd even be willing to rewrite history if that's what's
required to make it happen. Or, use my brain when interpreting the spec.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFDydNwL7PKlBZWjsRAovnAJ4t602VVXTDJ8siKRu1sBIexzwxNQCfSkM7
Laorz75i2noxXtXZ0mOeKH0=
=Mruf
-----END PGP SIGNATURE-----

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne Schlitt wrote:
> I've continued to ponder how we can test that an SPF implementation
> doesn't check more than 10 MX records. I still can't think of a
> perfect test, but here is an idea about how we might get a crude
> approximation. It won't check to make sure that no more than 10 MX
> records are checked, and it won't always work, but I'm guessing it
> will give pretty good results.
>
> [...]
>
> Yeah, this is *ugly* and not perfect, but it might work reasonably
> well.

So there's finally a situation where simulated offline testing is clearly
superior to online testing. The order of MX RRs in a simulated offline
DNS packet should be always consistent with their order in the test suite
data. (I can hardly see an implementor deliberatly randomizing their
order.)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFDyipwL7PKlBZWjsRAnBLAKCPHiT9Bnmy40cKIvfZxcsTSbE3hQCdGqFK
q0gbFgtC/nQ/til/tbVjmDE=
=g9di
-----END PGP SIGNATURE-----

-------
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 Mon, 18 Sep 2006 23:10:05 +0000 Julian Mehnle <julian@mehnle.net> wrote:
>About whether exceeding the processing limits should always cause a
>PermError, or only in exactly those cases where the spec literally demands
>it... Wayne, you're having way too much fun picking the flaws in your own
>spec. ;-) To make a long story short, I'm firmly in the "always
>PermError" camp. I'd even be willing to rewrite history if that's what's
>required to make it happen. Or, use my brain when interpreting the spec.

For your implementation I think you are perfectly free and even encouraged
to do that. For a reference test suite, I think you need to be more
restrained.

As written now if someone doesn't Permerror and we say an implementation
fails the compliance test, what is our answer when the author complains and
asks us "Where in RFC 4408 does it say I have to do that?"

Finally, there is no RFC limit on the number of MX servers a domain can
have. let's not invent another way that people can complain SPF 'breaks'
SMTP.

Scott K

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

> I agree with this interpretation of the MX limit.
> As the RFC is written, a PERMERROR should not be given.

+1

> When developing these limits for libspf2, I was primarily
> thinking of the ptr: mechanism.

Yes, you've explained that back in late 2004...

> I didn't put that much more thought into it.

...we've discussed it. The consideration was that more
MXs are "insane", worst known case 8 for T-Online.

With "insane" meaning "the addresses won't fit into the
additional section of a DNS reply for q=mx over UDP."

> Had this point been brought to my attention, I would
> certainly have seriously considered changing the I-D.

It was, and ruled as practically irrelevant.

> To the best of my knowledge, no one raised this point
> though.

It was, in various constellations, you might have missed
this thread (started by Stuart, degenerating into a kind
of flame war between me and Radu), but IIRC you read it:

http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=14467/force_load=t/focus=14921

> Can anyone find anywhere that this point was discussed?

See above. Our 10+10+10 discussion was late 2004, that's
where you explained how you arrived at 10 for PTR, and why
that's handled as specified in the later RFC.

> I doubt we will find anything that clear-cut though. :-<

Finding the opposite (= NO Permerror) isn't impossible. ;-)

Frank


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

Stuart D. Gathman wrote:

> Otherwise, there is simply no test that can be constructed
> for MX-limit.

Why not contruct in the same way as for the PTR limit ?

> There is already no way to test whether an implementation
> stopped after 10 PTR RRs, because there is no defined order.

The test suite can define the order. If the IUT gets a match
for the 11th MX (with say result PASS), and the result for
10 MXs is say FAIL, then that's a FAIL for that test case.

> Without a permerror - or at least an imposed ordering - for
> mx-limit, there is no test.

Sure, you've to impose the order. Where that's impossible
(test with a real DNS server) you can only test for FAIL or
INCONCLUSIVE. You'll also get some INCONCLUSIVE for IPv6,
UDP-lengths, etc., the MX-limit can't be the only grey area.

Frank


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

Scott Kitterman wrote:

> For your implementation I think you are perfectly free and
> even encouraged to do that.

Bogus PermErrors are generally net abuse. And arguably more
than 10 MXs are also abusive.

> For a reference test suite, I think you need to be more
> restrained.

+1

> "Where in RFC 4408 does it say I have to do that?"

It doesn't, for reasons discussed and decided in 2004 and 2005.

> let's not invent another way that people can complain SPF
> 'breaks' SMTP.

Discussions with people who refuse to acknowledge that SMTP was
broken by 1123 5.3.6(a) are hopeless, let them implement a pure
DKIM solution, and check out what it does for them (probably
nothing)

Frank


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> Julian Mehnle wrote:
> > About whether exceeding the processing limits should always cause a
> > PermError, or only in exactly those cases where the spec literally
> > demands it... Wayne, you're having way too much fun picking the flaws
> > in your own spec. ;-) To make a long story short, I'm firmly in the
> > "always PermError" camp. I'd even be willing to rewrite history if
> > that's what's required to make it happen. Or, use my brain when
> > interpreting the spec.
>
> For your implementation I think you are perfectly free and even
> encouraged to do that. For a reference test suite, I think you need to
> be more restrained.

Agreed. I therefore agree with the approach of permitting both PermError
and another possible result in the relevant test case.

> As written now if someone doesn't Permerror and we say an implementation
> fails the compliance test, what is our answer when the author complains
> and asks us "Where in RFC 4408 does it say I have to do that?"

_I_ would say, "read between the lines". However, I'm fully aware that the
spec doesn't spell it out and that there's no protocol police.

> Finally, there is no RFC limit on the number of MX servers a domain can
> have. let's not invent another way that people can complain SPF
> 'breaks' SMTP.

This (legitimate) question is irrelevant to the "PermError or not" issue.
You can always say "ip4:... ip4:... ..." or "exists:..." if you have more
than 10 outgoing MXes.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFD9REwL7PKlBZWjsRAuAgAKD+nhR9OQZ2gIV0mp4CGqocBvVkWACffbSQ
XjO1fkbSFs559FY7MooZ0m0=
=Lz08
-----END PGP SIGNATURE-----

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Scott Kitterman wrote:
> > For your implementation I think you are perfectly free and even
> > encouraged to do that.
>
> Bogus PermErrors are generally net abuse. And arguably more than 10 MXs
> are also abusive.

Look, I think you're missing the point here. The goal of PermError'ing on
excess MXes (and PTRs) is to eliminate one more source of randomness in
how SPF results are computed. We need to be as predictable as possible.
Yes, there are other sources that are outside of our reach, but that
doesn't mean we shouldn't try to minimize those that are _within_ reach.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFD9YEwL7PKlBZWjsRAr6xAKDrkjH7pHHinWcv++Z/ktR4P/E6LgCgvaka
6KDCkdmDPWJ6Hv4mliTYT9Q=
=zIMl
-----END PGP SIGNATURE-----

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

Julian Mehnle wrote:

> I therefore agree with the approach of permitting both
> PermError and another possible result in the relevant test
> case.

A bogus PermError spells "non-conforming" so clearly, that it
would be a complete waste of time to check any other test case.


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > I therefore agree with the approach of permitting both PermError and
> > another possible result in the relevant test case.
>
> A bogus PermError spells "non-conforming" so clearly, that it would be a
> complete waste of time to check any other test case.

Maybe. A "processing limit exceeded" PermError isn't bogus, though.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFD+ZLwL7PKlBZWjsRAiskAKCPN3Inh973bsp1fiNHJn+XqMtHiQCdGJEs
LAuU71dF7YLrF4FnsxXowSE=
=H35E
-----END PGP SIGNATURE-----

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

Julian Mehnle wrote:

> The goal of PermError'ing on excess MXes (and PTRs) is to
> eliminate one more source of randomness in how SPF results
> are computed.

That's a fine goal for a 4408bis, and I support it. But for
4408 it's "obviously" not the idea. Where "obvious" means
that Wayne needed some days to convince me back in late 2004.

We were all there, and nobody insisted on PermError for that
case (maybe Radu did). We can't reinterpret and reinvent the
spec. whenever we feel like it. And that's the reason why I
always pushed for an RFC, published RFCs are no moving target.

You can of course always abort the evaluation of a policy if
you don't like it. E.g. abort the interpretation of 'exists'
mentioning SORBS with a "5xx go away". But don't throw an
SPF PermError for a valid policy. Who knows what they're
trying to do with their weird more than 10 MXs ? Maybe it
doesn't matter from their POV, because all have the same IP.

SPF implementations hallucinating PermErrors are as bad as
implementations accepting broken policies without PermError:

Non-conforming because such random results are confusing for
senders (and receivers = users of such implementations, when
it hits their abuse desk).

Frank


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> The fundamental difference, IMO, is that all the explicit PermError
> cases are about errors/limits within the SPF record. MX and PTR limits
> are related to DNS configuration outside of SPF and so treating them
> differently in order to avoid imposing requirements on other protocols
> is appropriate.
>
> I suppose if we still called PermError Unknown, I might be more likely
> to agree with you, but I lost that point and have moved on.
>
> The more I think about this, the more I think the RFC is correct and
> silently not matching is the best out of a selection of poor choices.

Ever since we renamed "unknown" to "PermError", I have been thinking of it
as _any_ error that needs manual intervention to be resolved. I doubt
this will ever change unless we rename it to, e.g., "SyntaxError".

Thus I may see myself forced to submit to a (pardon me) pedantically
literal interpretation of the spec, but I'm certainly not able to defend
that interpretation.

So, I think we should set up an issue tracker for the specification ASAP so
we don't make the same problems in 4408bis or SPFv3. Comments?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFD/kvwL7PKlBZWjsRAt+pAJwNl4urWM6PEfD6pJhatG1ZpmPuIACgqqRO
D33UmrPQ0usdDY6cgrJFLiI=
=aYL2
-----END PGP SIGNATURE-----

-------
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 <450FC69F.5ED1@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes:

> wayne wrote:
>
>> I didn't put that much more thought into it.
>
> ...we've discussed it. The consideration was that more
> MXs are "insane", worst known case 8 for T-Online.

By "it", I meant "whether there should be a PermError for too many
MX/PTR records". Yes, there were lots of discussions about whether we
should have process limits on DNS lookups, and if so, how to count
them, but not what the result should be.

In the case of PTR records, more than 10 of them will show up in
legitimate cases and generally not cause any problems. Ignoring more
than 10 is fine.

In the case of MX records, more than 10 was thought to be "uncommon",
but ignoring more of them causes problems.


-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 <200609191244.59675.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> Frank Ellermann wrote:
>> Julian Mehnle wrote:
>> > I therefore agree with the approach of permitting both PermError and
>> > another possible result in the relevant test case.
>>
>> A bogus PermError spells "non-conforming" so clearly, that it would be a
>> complete waste of time to check any other test case.
>
> Maybe. A "processing limit exceeded" PermError isn't bogus, though.

Creating PermErrors where none are specified by the specification is
bogus.

And, as I mention else where, creating PermErrors in the case of ptr:
is a really bad idea since the domain owner has no control over where
spam forging their domain name is sent from. Even in legitimate cases
where the domain owner's PTR records exceed 10, ignoring the others is
the right thing to do.

This is a case where treating mx: and ptr: the same is wrong, but it
is in the spec. As Frank said, this would be a good thing for
4408bis.


-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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne Schlitt wrote:
> And, as I mention else where, creating PermErrors in the case of ptr:
> is a really bad idea since the domain owner has no control over where
> spam forging their domain name is sent from.

So what could happen? Spam gets rejected due to PermError instead of due
to Fail? So what?

> Even in legitimate cases where the domain owner's PTR records exceed 10,
> ignoring the others is the right thing to do.

It makes things unpredictable, given the undefined order of the RRs in DNS
packets. So I disagree. Giving a PermError would immediately advise the
SPF publisher not to rely on the "ptr:" mechanism for his setup.

> This is a case where treating mx: and ptr: the same is wrong, but it
> is in the spec. As Frank said, this would be a good thing for
> 4408bis.

The "ptr:" mechanism should rather be removed in SPFv3.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFEAI7wL7PKlBZWjsRAoboAKC/C+d2c4bjyA1OVaHgQ3Co6RBVvACeML86
RfWb9z+z76moZ7yXj0ECa/c=
=1YWC
-----END PGP SIGNATURE-----

-------
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 <200609191444.11586.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> Wayne Schlitt wrote:
>> And, as I mention else where, creating PermErrors in the case of ptr:
>> is a really bad idea since the domain owner has no control over where
>> spam forging their domain name is sent from.
>
> So what could happen? Spam gets rejected due to PermError instead of due
> to Fail? So what?

Lots of people treat these two SPF results differently. So, I guess
with your implementation you can do whatever you want, but I would
think for the test suite, it should follow the SPF spec.

>> This is a case where treating mx: and ptr: the same is wrong, but it
>> is in the spec. As Frank said, this would be a good thing for
>> 4408bis.
>
> The "ptr:" mechanism should rather be removed in SPFv3.

I could see that, although it is rather effective and I bet you will
get a lot of people objecting to its removal.


-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

On Tue, 19 Sep 2006 14:05:35 +0000 Julian Mehnle <julian@mehnle.net> wrote:

>So, I think we should set up an issue tracker for the specification ASAP
so
>we don't make the same problems in 4408bis or SPFv3. Comments?

Sounds like a great idea to me. Do we really need a full blown issue
tracker or is a page in the wiki sufficient?

Scott K

-------
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 Mon, 18 Sep 2006, wayne wrote:

> There are other "MUST"s in the RFC that will be hard to check too,
> such as stuff relating to the exp= text and the Received-SPF header.

Already did the exp= stuff.

> An example that is closer to the processing limits is the requirement
> from section 4.5 that says:
>
> If no matching records are returned, an SPF client MUST assume that
> the domain makes no SPF declarations. SPF processing MUST stop and
> return "None".
>
> How can you prove, via the SPF result, that an implementation didn't
> actually continue processing stuff and then throw out the results and
> return "None"?

I simply check that the result is none. We don't really care what additional
processing they do as long as the result is none. It's their CPU.

> Only 10 MX records should be checked. Which ten is undefined.
>
>
> -wayne

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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