Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SPF: Discuss

Unknown mechanisms

 

 

SPF discuss RSS feed   Index | Next | Previous | View Threaded


msk at cloudmark

Sep 2, 2011, 10:43 AM

Post #1 of 13 (4157 views)
Permalink
Unknown mechanisms

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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902134404:23D8B61E-D58B-11E0-A940-DBA58BC2B55F
Powered by Listbox: http://www.listbox.com


scott at kitterman

Sep 2, 2011, 11:05 AM

Post #2 of 13 (4053 views)
Permalink
Re: Unknown mechanisms [In reply to]

On Friday, September 02, 2011 01:43:55 PM Murray S. Kucherawy wrote:
> 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


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902140600:35401B60-D58E-11E0-AFCB-94E1E7C56D0D
Powered by Listbox: http://www.listbox.com


msk at cloudmark

Sep 2, 2011, 11:12 AM

Post #3 of 13 (4060 views)
Permalink
RE: Unknown mechanisms [In reply to]

> -----Original Message-----
> From: Scott Kitterman [mailto:scott [at] kitterman]
> Sent: Friday, September 02, 2011 11:06 AM
> To: spf-discuss [at] listbox
> 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


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902141217:16B6A3E8-D58F-11E0-96BF-80799ADB7D81
Powered by Listbox: http://www.listbox.com


dotzero at gmail

Sep 2, 2011, 11:32 AM

Post #4 of 13 (4064 views)
Permalink
Re: Unknown mechanisms [In reply to]

On Fri, Sep 2, 2011 at 2:12 PM, Murray S. Kucherawy <msk [at] cloudmark> wrote:
>> -----Original Message-----
>> From: Scott Kitterman [mailto:scott [at] kitterman]
>> Sent: Friday, September 02, 2011 11:06 AM
>> To: spf-discuss [at] listbox
>> 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.


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902143216:E14D2882-D591-11E0-87A5-A8CD9FB15F5E
Powered by Listbox: http://www.listbox.com


scott at kitterman

Sep 2, 2011, 12:28 PM

Post #5 of 13 (4065 views)
Permalink
Re: Unknown mechanisms [In reply to]

On Friday, September 02, 2011 02:12:10 PM Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: Scott Kitterman [mailto:scott [at] kitterman]
> > Sent: Friday, September 02, 2011 11:06 AM
> > To: spf-discuss [at] listbox
> > 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


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902152849:C779C0E8-D599-11E0-9D6B-82553486EFB5
Powered by Listbox: http://www.listbox.com


stuart at bmsi

Sep 2, 2011, 1:50 PM

Post #6 of 13 (4063 views)
Permalink
RE: Unknown mechanisms [In reply to]

On Fri, 2 Sep 2011, Murray S. Kucherawy wrote:

>> 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 <stuart [at] bmsi>
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.


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902165029:2FD4BE4E-D5A5-11E0-9645-BC20FFB6DC3F
Powered by Listbox: http://www.listbox.com


hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail

Sep 2, 2011, 4:05 PM

Post #7 of 13 (4048 views)
Permalink
Re: Unknown mechanisms [In reply to]

On 2 September 2011 20:12, Murray S. Kucherawy wrote:

>> 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.

> 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


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902190545:15961FA6-D5B8-11E0-90E6-C67781BDB327
Powered by Listbox: http://www.listbox.com


msk at cloudmark

Sep 2, 2011, 5:40 PM

Post #8 of 13 (4051 views)
Permalink
RE: Unknown mechanisms [In reply to]

> -----Original Message-----
> From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz [at] gmail]
> Sent: Friday, September 02, 2011 4:05 PM
> To: spf-discuss [at] listbox
> Subject: Re: [spf-discuss] Unknown mechanisms
>
> > 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?



-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902204049:5D2C914E-D5C5-11E0-A3D6-83D4E2147AF3
Powered by Listbox: http://www.listbox.com


alex at vandenbogaerdt

Sep 2, 2011, 8:14 PM

Post #9 of 13 (4054 views)
Permalink
RE: Unknown mechanisms [In reply to]

> 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 ?




-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902231508:E874AC54-D5DA-11E0-AB60-D3742726069F
Powered by Listbox: http://www.listbox.com


alex at vandenbogaerdt

Sep 2, 2011, 8:14 PM

Post #10 of 13 (4047 views)
Permalink
RE: Unknown mechanisms [In reply to]

> 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 ?




-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110902231511:EB8A9E1C-D5DA-11E0-8778-EE9D915C2FF1
Powered by Listbox: http://www.listbox.com


hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail

Sep 3, 2011, 4:51 AM

Post #11 of 13 (4037 views)
Permalink
Re: Unknown mechanisms [In reply to]

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

Hi,

> 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


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110903075148:17E86690-D623-11E0-83CA-F3FF5D7FF0A8
Powered by Listbox: http://www.listbox.com


msk at cloudmark

Sep 3, 2011, 6:46 PM

Post #12 of 13 (4047 views)
Permalink
RE: Unknown mechanisms [In reply to]

> -----Original Message-----
> From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz [at] gmail]
> Sent: Saturday, September 03, 2011 4:51 AM
> To: spf-discuss [at] listbox
> Subject: Re: [spf-discuss] Unknown mechanisms
>
> > 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".

> 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.

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.


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110903214633:B69F0306-D697-11E0-8D03-AD13ACA3C98B
Powered by Listbox: http://www.listbox.com


hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail

Sep 15, 2011, 2:33 AM

Post #13 of 13 (4016 views)
Permalink
Re: Unknown mechanisms [In reply to]

On 4 September 2011 03:46, Murray S. Kucherawy wrote:

>> 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)


-------------------------------------------
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/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110915053352:D185422C-DF7D-11E0-90D6-FD86BA670D70
Powered by Listbox: http://www.listbox.com

SPF discuss RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.