Mailing List Archive

> Test 75 doesn't match because recursion being too deep should be an
> error, not an unknown.
>
>
My take on this is that recursion depth > 20 should result in an
UNKNOWN. The spec says so, and it makes sense that mail shouldn't be
rejected because of an incorrect mechanism.

If you do a 'include:somewhere.com' means that the SPF processing is
out of your control... if 'somewhere.com' messes up, then ALL your mail
will be rejected, and that doesn't sound right.

So, the Perl and Python implementations are WRONG, the tests in M:S:Q
are WRONG.

Cheers!

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> My take on this is that recursion depth > 20 should result in an
> UNKNOWN. The spec says so, and it makes sense that mail shouldn't be
> rejected because of an incorrect mechanism.
>
> If you do a 'include:somewhere.com' means that the SPF processing is
> out of your control... if 'somewhere.com' messes up, then ALL your mail
> will be rejected, and that doesn't sound right.

Uhmm.... I beg to differ. If you choose to "include" somewhere else,
its upon your head that you do so. One should not include records that
are not in their control. And if one were to include records from
another domain, one would hope that it would be reputable enough to know
what it is doing. That being said, the current implementation is
perfectly sound. I would treat "including" offsite records as, "Do so
at your own risk".

The underlying goal behind include is to help shorten rules, yes you
could include anyones record, but again, at your own risk IMO.

> So, the Perl and Python implementations are WRONG, the tests in M:S:Q
> are WRONG.

Whatever you say boss.

Cheers,

James
--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

James Couzens wrote:

>>My take on this is that recursion depth > 20 should result in an
>>UNKNOWN. The spec says so, and it makes sense that mail shouldn't be
>>rejected because of an incorrect mechanism.
>>
>>If you do a 'include:somewhere.com' means that the SPF processing is
>>out of your control... if 'somewhere.com' messes up, then ALL your mail
>>will be rejected, and that doesn't sound right.
>
>
> Uhmm.... I beg to differ. If you choose to "include" somewhere else,
> its upon your head that you do so. One should not include records that
> are not in their control. And if one were to include records from
> another domain, one would hope that it would be reputable enough to know
> what it is doing. That being said, the current implementation is
> perfectly sound. I would treat "including" offsite records as, "Do so
> at your own risk".

Well I'm going to back... erm, Terence Way apparently (please don't
remove attributions when quoting!)

If your own record becomes unavailable, your mail all gets "unknown".
There is no reason that the unavailability of a third party's record
should have any worse consequences than that.

"include" is designed to allow safe inclusion of "my ISP". It must
therefore be explicitly fail-safe for third-party usage. I do not expect
a DDOS on some third- or fourth- party DNS server to affect my email.


AS it happens, the test in question fails not because of genuine
recursion error, but because it has the string "include" with no
parameters, which as far as I'm concerned is an undefined behaviour.

The fact that my parser tries to include the parent record and Meng's
just skips it is just a difference of approach.

Wechsler

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Wed, Jan 28, 2004 at 10:05:05AM -0500, Terence Way wrote:
| My take on this is that recursion depth > 20 should result in an
| UNKNOWN. The spec says so, and it makes sense that mail shouldn't be
| rejected because of an incorrect mechanism.

I think this confusion will be resolved once we add Philip Gladstone's
new error states.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

> AS it happens, the test in question fails not because of genuine
> recursion error, but because it has the string "include" with no
> parameters, which as far as I'm concerned is an undefined behaviour.
>

This reminds me of my favorite quote:
"Let's not cloud the issue with facts"

Okay, good point: 'include' as a mechanism by itself is a good test of how
an implementation parses mechanisms: most mechanisms have *optional*
arguments, like 'a' vs 'a:dingus.com'

But surely this isn't 'undefined' behaviour: unknown or unparsable
mechanisms should result in an UNKNOWN.

Cheers!

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGHÝÜîU;±¤Þ¬bÆß®2x.com