Unknown mechanisms

[Murray S. Kucherawy]

After a brief re-read, I see that RFC4408 explains that unknown modifiers are to be ignored, but doesn't say what to do if there's an unknown mechanism encountered. Since such a mechanism fails the ABNF grammar, I presume that means a receiver should just ignore the entire record because it's invalid.

Should the updated one say that explicitly, or say "ignore unknown mechanisms", or just leave it the way it is?

-MSK



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20110902134404:23D8B61E-D58B-11E0-A940-DBA58BC2B55F
Powered by Listbox: http://www.listbox.com

[Scott Kitterman]

Post by Murray S. Kucherawy
After a brief re-read, I see that RFC4408 explains that unknown modifiers
are to be ignored, but doesn't say what to do if there's an unknown
mechanism encountered. Since such a mechanism fails the ABNF grammar, I
presume that means a receiver should just ignore the entire record because
it's invalid.
Should the updated one say that explicitly, or say "ignore unknown
mechanisms", or just leave it the way it is?

New mechanisms (unlike new modifiers) can change the SPF result. If we were to
add a new mechanism, then we'd have to bump the version. If an unknown
mechanism is encountered, the correct result is permerror.

Scott K

[Murray S. Kucherawy]

-----Original Message-----
Sent: Friday, September 02, 2011 11:06 AM
Subject: Re: [spf-discuss] Unknown mechanisms
New mechanisms (unlike new modifiers) can change the SPF result. If we were to
add a new mechanism, then we'd have to bump the version. If an unknown
mechanism is encountered, the correct result is permerror.

Fair enough.

I'd like that to be explicit. As it is now an implementer could decide that ignoring unknown mechanisms is simplest (and a common practice, such as in DKIM and its friends), leaving the remaining record parsable and usable. Something like "An SPF-aware receiver encountering an unknown mechanism MUST return a 'permerror' result" would be good to add in the right place.

-MSK

[Dotzero]

Post by Murray S. Kucherawy

-----Original Message-----
Sent: Friday, September 02, 2011 11:06 AM
Subject: Re: [spf-discuss] Unknown mechanisms
New mechanisms (unlike new modifiers) can change the SPF result.  If we were to
add a new mechanism, then we'd have to bump the version.  If an unknown
mechanism is encountered, the correct result is permerror.

Fair enough.
I'd like that to be explicit.  As it is now an implementer could decide that ignoring unknown mechanisms is simplest (and a common practice, such as in DKIM and its friends), leaving the remaining record parsable and usable.  Something like "An SPF-aware receiver encountering an unknown mechanism MUST return a 'permerror' result" would be good to add in the right place.
-MSK

Being explicit makes sense to me.

[Scott Kitterman]

Post by Murray S. Kucherawy

-----Original Message-----
Sent: Friday, September 02, 2011 11:06 AM
Subject: Re: [spf-discuss] Unknown mechanisms
New mechanisms (unlike new modifiers) can change the SPF result. If we
were to add a new mechanism, then we'd have to bump the version. If an
unknown mechanism is encountered, the correct result is permerror.

Fair enough.
I'd like that to be explicit. As it is now an implementer could decide
that ignoring unknown mechanisms is simplest (and a common practice, such
as in DKIM and its friends), leaving the remaining record parsable and
usable. Something like "An SPF-aware receiver encountering an unknown
mechanism MUST return a 'permerror' result" would be good to add in the
right place.

I've looked over the relevant bits of RFC 4408 and I agree it could be more
explicit. Thanks,

Scott K

[Stuart D. Gathman]

Post by Murray S. Kucherawy

Post by Scott Kitterman
New mechanisms (unlike new modifiers) can change the SPF result. If we were to
add a new mechanism, then we'd have to bump the version. If an unknown
mechanism is encountered, the correct result is permerror.

Fair enough.
I'd like that to be explicit. As it is now an implementer could decide that
ignoring unknown mechanisms is simplest (and a common practice, such as in
DKIM and its friends), leaving the remaining record parsable and usable.
Something like "An SPF-aware receiver encountering an unknown mechanism MUST
return a 'permerror' result" would be good to add in the right place.

FWIW, the test suite will flunk an implementation that fails to give
permerror for the "moo" mechanism.

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

[Frank Ellermann]

Post by Murray S. Kucherawy

 If an unknown mechanism is encountered, the correct result is
permerror.

Fair enough.

There is no such thing as an "unknown mechanism". The <mechanism>
syntax is a finite enumeration of known mechanisms. Anything else
could be anything, a broken modifier, a funny TXT record unrelated
to v=spf1, or nobody knows what, except that it's no valid v=spf1.

Post by Murray S. Kucherawy
I'd like that to be explicit.  As it is now an implementer could
decide that ignoring unknown mechanisms is simplest (and a common
practice, such as in DKIM and its friends), leaving the remaining
record parsable and usable.

I don't recall any DKIM syntax details, but I'd bet that it also
does not explicitly say that syntactical garbage cannot be parsed.

It would be odd to discuss IPv4 octets 256 or greater in prose, so
why would you wish to discuss non-existing mechanisms in prose?

I've never heard of any difficulties with this aspect of RFC 4408,
after all it was published when the proposals for other mechanisms
were long dead (for the reason stated by Scott). IIRC you would
find some erroneous "unknown mechanism" syntax in old SPF drafts.

-Frank

[Murray S. Kucherawy]

-----Original Message-----
Sent: Friday, September 02, 2011 4:05 PM
Subject: Re: [spf-discuss] Unknown mechanisms

Post by Murray S. Kucherawy
Fair enough.

There is no such thing as an "unknown mechanism". The <mechanism>
syntax is a finite enumeration of known mechanisms. Anything else
could be anything, a broken modifier, a funny TXT record unrelated
to v=spf1, or nobody knows what, except that it's no valid v=spf1.

RFC4408 is fine as it is in a pure sense, but nowhere does it explicitly answer the question "What do I do if there's a bogus mechanism in here but the record otherwise looks correct?" It's vaguely in there. I think it should be explicitly in there.

Yes, it's in the ABNF, and the definition of "permerror" basically covers it.

Is there harm in explicitly connecting the two?

[Alex van den Bogaerdt]

Post by Murray S. Kucherawy
RFC4408 is fine as it is in a pure sense, but nowhere does it explicitly
answer the question "What do I do if there's a bogus mechanism in here but
the record otherwise looks correct?" It's vaguely in there. I think it
should be explicitly in there.
Yes, it's in the ABNF, and the definition of "permerror" basically covers it.
Is there harm in explicitly connecting the two?

Is "xyzzy" an unknown mechanism, a bogus mechanism, or just a syntax error?

To answer this question myself: "Terms that do not contain any of "=",
":", or "/" are mechanisms, as defined in Section 5."

Nowhere in section 5 it says that character strings without "=", ":", or
"/" are mechanisms per se, so this sentence should be read similar to:
"when you encounter a string without "=", ":", or "/", it should be a
mechanism which is defined in section 5."

Chances are that it should have been a mechanism, or a modifier, and it
just contains a typo. Is "xyzzy = blah" intended as mechanism or as
modifier? In any case it is a syntax error, and syntax errors are covered
in the spec, in more than one place, at least in 2.5.7 and 4.6, possibly
more.

Why specifically mention
syntax-errors-which-look-like-mechanisms-but-are-not ?

[Alex van den Bogaerdt]

Post by Murray S. Kucherawy
RFC4408 is fine as it is in a pure sense, but nowhere does it explicitly
answer the question "What do I do if there's a bogus mechanism in here but
the record otherwise looks correct?" It's vaguely in there. I think it
should be explicitly in there.
Yes, it's in the ABNF, and the definition of "permerror" basically covers it.
Is there harm in explicitly connecting the two?

Is "xyzzy" an unknown mechanism, a bogus mechanism, or just a syntax error?

To answer this question myself: "Terms that do not contain any of "=",
":", or "/" are mechanisms, as defined in Section 5."

Nowhere in section 5 it says that character strings without "=", ":", or
"/" are mechanisms per se, so this sentence should be read similar to:
"when you encounter a string without "=", ":", or "/", it should be a
mechanism which is defined in section 5."

Chances are that it should have been a mechanism, or a modifier, and it
just contains a typo. Is "xyzzy = blah" intended as mechanism or as
modifier? In any case it is a syntax error, and syntax errors are covered
in the spec, in more than one place, at least in 2.5.7 and 4.6, possibly
more.

Why specifically mention
syntax-errors-which-look-like-mechanisms-but-are-not ?

[Frank Ellermann]

On 3 September 2011 02:40, Murray S. Kucherawy wrote:

Hi,

Post by Murray S. Kucherawy
Yes, it's in the ABNF, and the definition of "permerror"
basically covers it. Is there harm in explicitly
connecting the two?

Not directly, but I recall that we had *big* difficulties
to limit the size (in pages) of this beast.

Your proposal could result in new text like this:

| Note that there are no "unknown mechanisms", because this
| would | result in a syntax error while parsing a policy,
| or, if it were explicitly allowed, in PERMERROR results
| with older implementations, and in different results with
| newer implementations either supporting or ignoring such
| mechanisms. Therefore a new version different from v=spf1
| is REQUIRED for the introduction of new mechanisms.

That would cover the issue completely, hopefully, but it is
also one of those cases where not talking about it might be
clearer for readers.

[There is a complete draft explaining the similar issue of
unknown modifiers with incompatible results depending on
the implementation (support as new vs. ignore as unknown),
originally intended as RFC 4408 section. And there were
good reasons to never add it to RFC 4408: It is just not
interesting as long as nobody invents new modifiers with
this property -- Scott's MARF modifiers are not affected.]

If you have a shorter/clearer idea to explain the issue of
unknown mechanisms in prose, shoot.

-Frank

[Murray S. Kucherawy]

-----Original Message-----
Sent: Saturday, September 03, 2011 4:51 AM
Subject: Re: [spf-discuss] Unknown mechanisms

Post by Murray S. Kucherawy
Yes, it's in the ABNF, and the definition of "permerror"
basically covers it. Is there harm in explicitly
connecting the two?

Not directly, but I recall that we had *big* difficulties
to limit the size (in pages) of this beast.

I'm not advocating adding "pages".

| Note that there are no "unknown mechanisms", because this
| would | result in a syntax error while parsing a policy,
| or, if it were explicitly allowed, in PERMERROR results
| with older implementations, and in different results with
| newer implementations either supporting or ignoring such
| mechanisms. Therefore a new version different from v=spf1
| is REQUIRED for the introduction of new mechanisms.

Or, the one sentence I already proposed:

"An SPF-aware receiver encountering an unknown mechanism MUST return a 'permerror' result."

If you have a shorter/clearer idea to explain the issue of
unknown mechanisms in prose, shoot.

Shot taken.

[Frank Ellermann]

Post by Murray S. Kucherawy

Post by Frank Ellermann
If you have a shorter/clearer idea to explain the issue of
unknown mechanisms in prose, shoot.

Shot taken.

I'll let Scott or the mysterious "4408bis WG" decide if it
was a hit... ;-)

-Frank (cleaning up my "starred" messages)