SPF/term - Revision history

Woozle at 14:48, 19 August 2022

2022-08-19T14:48:55Z

← Older revision		Revision as of 14:48, 19 August 2022
Line 10:		Line 10:
	* {{fmt/arg\|*-cidr-length}}: see {{l/sub\|cidr-length}}		* {{fmt/arg\|*-cidr-length}}: see {{l/sub\|cidr-length}}
	* {{fmt/arg\|domain-spec}} defaults to {{arg\|host domain}}.		* {{fmt/arg\|domain-spec}} defaults to {{arg\|host domain}}.
			** In some cases, this is parsed using the SPF macro language; it's not clear whether this applies to all cases, however.
			** Either way, a domain name without any SPF markup will be interpreted literally (i.e. as you'd expect).
	* {{fmt/arg\|host domain}} is the domain whose DNS record we're constructing/examining		* {{fmt/arg\|host domain}} is the domain whose DNS record we're constructing/examining
	** The RFC calls this the {{fmt/xml/tag\|target-name}}).		** The RFC calls this the {{fmt/xml/tag\|target-name}}).
	* {{fmt/arg\|~~{{l/sub\|~~ip}}~~}}, aka "~~the IP~~": I thought this meant one thing, but now I'm not sure.~~
			Terms used in explanations:
			* {{fmt/arg\|sender-ip}}: the IP address from which the message is being received
	{\| class="wikitable"		{\| class="wikitable"
	! code !! format \|\| meaning		! code !! format \|\| meaning
Line 29:		Line 33:
	\|-		\|-
	\| <code>a</code>		\| <code>a</code>
	\| a{{fmt/opt\|:{{fmt/arg\|domain-spec}}}} {{fmt/arg~~/opt~~\|dual-{{l/sub\|cidr-length}}}}		\| style="white-space: nowrap;" \| a{{fmt/opt\|:{{fmt/arg\|domain-spec}}}}{{fmt/opt\|/{{fmt/arg\|dual-{{l/sub\|cidr-length}}}}}}</span>
	\| ~~match if~~ {{arg\|domain-spec}} ~~points to one of the~~ {{arg\|~~host domain~~}}~~'s IP addresses~~		\| All the A or AAAA records for {{fmt/arg\|domain-spec}} are tested. If {{fmt/arg\|sender-ip}} is found among them, this mechanism matches.
			* Use of A or AAAA depends on whether the connection is made over IPv4 or IPv6 respectively.
	\|-		\|-
	\| <code>mx</code>		\| <code>mx</code>
	\|		\| style="white-space: nowrap;" \| mx{{fmt/opt\|:{{fmt/arg\|domain-spec}}}}{{fmt/opt\|/{{fmt/arg\|dual-{{l/sub\|cidr-length}}}}}}
	~~<poem>mx~~		\| All the A or AAAA records for all the MX records for {{fmt/arg\|domain-spec}} are tested in order of MX priority. If {{fmt/arg\|sender-ip}} is found among them, this mechanism matches.
	mx/{{~~arg\|dual-{{l~~/~~sub~~\|~~cidr-length}}}}~~		* Use of A or AAAA depends on whether the connection is made over IPv4 or IPv6 respectively.
	mx:{{arg\|domain-spec}}
	~~mx:~~{{~~arg~~\|~~domain-spec}}~~/{{arg\|dual-{{l/sub\|cidr-length}}}}
	~~</poem>~~
	\| All the A records for all the MX records for {{fmt/arg\|domain-spec}} are tested in order of MX priority. If ~~the client IP~~ is found among them, this mechanism matches.
	\|-		\|-
	\| <code><s>ptr</s></code>		\| <code><s>ptr</s></code>
Line 48:		Line 49:
	<code>ip4</code><br>		<code>ip4</code><br>
	<code>ip6</code>		<code>ip6</code>
	\| ip''N''{{fmt/opt\|:{{fmt/arg\|ip''N''-network}}}} {{fmt/arg~~/opt~~\|ip''N''-{{l/sub\|cidr-length}}}}		\| ip''N''{{fmt/opt\|:{{fmt/arg\|ip''N''-network}}}}{{fmt/opt\|/{{fmt/arg\|ip''N''-{{l/sub\|cidr-length}}}}}}
	\| test whether sender is contained within a given IP network		\| test whether sender is contained within a given IP network (address range)
	* can also match a specific IP address, apparently		* can also match a specific IP address, apparently
	\|-		\|-
Line 69:		Line 70:
	* The macro-expanded domain is also substituted for the current domain in those lookups.		* The macro-expanded domain is also substituted for the current domain in those lookups.
	\|}		\|}
			==Clarification==
			Where the syntax looks like this --
			{{fmt/arg\|term}}{{fmt/opt\|:{{fmt/arg\|spec}}}}{{fmt/opt\|/{{fmt/arg\|dual-{{l/sub\|cidr-length}}}}}}
			-- valid combinations are:
			{{fmt/arg\|term}}
			{{fmt/arg\|term}}/{{arg\|dual-{{l/sub\|cidr-length}}}}
			{{fmt/arg\|term}}:{{arg\|spec}}
			{{fmt/arg\|term}}:{{arg\|spec}}/{{arg\|dual-{{l/sub\|cidr-length}}}}
	==Links==		==Links==
	* {{wikipedia\|Sender_Policy_Framework#Implementation}}		* {{wikipedia\|Sender_Policy_Framework#Implementation}}

Woozle at 14:16, 19 August 2022

2022-08-19T14:16:56Z

← Older revision		Revision as of 14:16, 19 August 2022
Line 60:		Line 60:
	\| colspan=3 \| '''Modifiers''':		\| colspan=3 \| '''Modifiers''':
	\|-		\|-
			\| exp
			\| exp={{fmt/arg\|domain}}
			\| The given {{fmt/arg\|domain}} should have a DNS TXT record (interpreted using SPF's macro language) to get an explanation for FAIL results – typically a URL which is added to the SMTP error code. This feature is rarely used.
			\|-
			\| redirect
			\| redirect={{fmt/arg\|domain-spec}}
			\| Replace this SPF record with the SPF record from {{fmt/arg\|domain-spec}}.
			* The macro-expanded domain is also substituted for the current domain in those lookups.
	\|}		\|}
	==Links==		==Links==
			* {{wikipedia\|Sender_Policy_Framework#Implementation}}
	* [https://dmarcadvisor.com/spf-syntax-table/ SPF Record Syntax]		* [https://dmarcadvisor.com/spf-syntax-table/ SPF Record Syntax]
	==Footnote==		==Footnote==

Woozle at 14:10, 19 August 2022

2022-08-19T14:10:47Z

← Older revision		Revision as of 14:10, 19 August 2022
Line 61:		Line 61:
	\|-		\|-
	\|}		\|}
			==Links==
			* [https://dmarcadvisor.com/spf-syntax-table/ SPF Record Syntax]
	==Footnote==		==Footnote==
	<references>		<references>
	<ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote\|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp\|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref>		<ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote\|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp\|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref>
	</references>		</references>

Woozle: /* About */

2022-08-19T14:09:45Z

About

← Older revision		Revision as of 14:09, 19 August 2022
Line 33:		Line 33:
	\|-		\|-
	\| <code>mx</code>		\| <code>mx</code>
	\| mx{{~~fmt~~/~~opt~~\|:{{~~fmt/~~arg\|domain-spec}}}} {{~~fmt/~~arg~~/opt~~\|dual-{{l/sub\|cidr-length}}}}		\|
	\| ~~do an~~ MX ~~lookup on the~~ {{arg\|~~host~~ domain}}~~, then look up address for each~~ MX ~~name returned.~~..		<poem>mx
	* It's not yet clear what the ~~pass/fail criteria are.~~		mx/{{arg\|dual-{{l/sub\|cidr-length}}}}
	* Multiple MX mechanisms may be listed.		mx:{{arg\|domain-spec}}
			mx:{{arg\|domain-spec}}/{{arg\|dual-{{l/sub\|cidr-length}}}}
			</poem>
			\| All the A records for all the MX records for {{fmt/arg\|domain-spec}} are tested in order of MX priority. If the client IP is found among them, this mechanism matches.
	\|-		\|-
	\| <code><s>ptr</s></code>		\| <code><s>ptr</s></code>
Line 58:		Line 61:
	\|-		\|-
	\|}		\|}

	==Footnote==		==Footnote==
	<references>		<references>
	<ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote\|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp\|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref>		<ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote\|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp\|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref>
	</references>		</references>

Woozle: modifiers need to be added

2022-08-18T17:08:15Z

modifiers need to be added

← Older revision		Revision as of 17:08, 18 August 2022
Line 1:		Line 1:
	{{fmt/title\|SPF ~~mechanisms~~}}		{{fmt/title\|SPF terms}}
	==About==		==About==
	~~Mechanisms used by [[../]]~~ are ~~defined in [https:~~/~~/www.rfc-editor.org/rfc/rfc7208.html#section-5 RFC 7208 Section 5]. We~~'~~ll refer to {the domain to~~ which ~~a DNS record refers} as the {{arg\|host domain}} (although the RFC refers to it as {{fmt/xml/tag\|target-name}}~~).		SPF terms are either ''mechanisms'' (which are ways of evaluating and return pass/fail) or ''modifiers'' (which return additional information but do not evaluate). All terms are separated by spaces.

	Mechanisms are ~~separated by spaces~~.		'''Mechanisms''' used by [[../]] are defined in [https://www.rfc-editor.org/rfc/rfc7208.html#section-5 RFC 7208 Section 5].

	Commonly-used ~~terms~~:		'''Modifiers''' used by SPF are defined in [https://www.rfc-editor.org/rfc/rfc7208.html#section-6 RFC 7208 Section 6].
	* {{fmt/arg\|{{l/sub\|ip}}}}, aka "the IP"
			Commonly-used argument names:
	* {{fmt/arg\|*-cidr-length}}: see {{l/sub\|cidr-length}}		* {{fmt/arg\|*-cidr-length}}: see {{l/sub\|cidr-length}}
	* {{arg\|domain-spec}} defaults to {{arg\|host domain}}.		* {{fmt/arg\|domain-spec}} defaults to {{arg\|host domain}}.
			* {{fmt/arg\|host domain}} is the domain whose DNS record we're constructing/examining
			** The RFC calls this the {{fmt/xml/tag\|target-name}}).
			* {{fmt/arg\|{{l/sub\|ip}}}}, aka "the IP": I thought this meant one thing, but now I'm not sure.
	{\| class="wikitable"		{\| class="wikitable"
	! code !! format \|\| meaning		! code !! format \|\| meaning
	\|-		\|-
	\| colspan=3 \| '''Basic''':		\| colspan=3 \| '''Basic''' mechanisms:
	\|-		\|-
	\| <code>all</code>		\| <code>all</code>
Line 22:		Line 26:
	\| utility is unclear; includes SPF evaluation of the given domain, but not in a systematic way		\| utility is unclear; includes SPF evaluation of the given domain, but not in a systematic way
	\|-		\|-
	\| colspan=3 \| '''Designated sender''':		\| colspan=3 \| '''Designated sender''' mechanisms:
	\|-		\|-
	\| <code>a</code>		\| <code>a</code>
Line 50:		Line 54:
	* This allows for complex/fine-grained examination of the mail envelope to determine what is permitted		* This allows for complex/fine-grained examination of the mail envelope to determine what is permitted
	* {{fmt/arg\|domain-spec}} is defined in [https://www.rfc-editor.org/rfc/rfc7208.html#section-7 Section 7].		* {{fmt/arg\|domain-spec}} is defined in [https://www.rfc-editor.org/rfc/rfc7208.html#section-7 Section 7].
			\|-
			\| colspan=3 \| '''Modifiers''':
			\|-
	\|}		\|}
	==Footnote==		==Footnote==

Woozle: Woozle moved page SPF/mechanism to SPF/term

2022-08-18T16:51:31Z

Woozle moved page SPF/mechanism to SPF/term

← Older revision	Revision as of 16:51, 18 August 2022
(No difference)

Woozle at 16:36, 18 August 2022

2022-08-18T16:36:17Z

← Older revision		Revision as of 16:36, 18 August 2022
Line 5:		Line 5:
	Mechanisms are separated by spaces.		Mechanisms are separated by spaces.

	Commonly-used terms ~~(are these defined in~~ {{l/~~same~~\|~~modifiers~~}}~~?):~~		Commonly-used terms:
	* {{fmt/arg\|~~dual~~-cidr-length}}: ~~I don't yet know what this means.~~		* {{fmt/arg\|{{l/sub\|ip}}}}, aka "the IP"
			* {{fmt/arg\|*-cidr-length}}: see {{l/sub\|cidr-length}}
	* {{arg\|domain-spec}} defaults to {{arg\|host domain}}.		* {{arg\|domain-spec}} defaults to {{arg\|host domain}}.
	{\| class="wikitable"		{\| class="wikitable"
Line 19:		Line 20:
	\| <code>include</code>		\| <code>include</code>
	\| <code>include:{{arg\|domain-spec}}</code>		\| <code>include:{{arg\|domain-spec}}</code>
	\| utility is unclear; includes evaluation of the given domain, but not in a ~~clean~~ way		\| utility is unclear; includes SPF evaluation of the given domain, but not in a systematic way
	\|-		\|-
	\| colspan=3 \| '''Designated sender''':		\| colspan=3 \| '''Designated sender''':
	\|-		\|-
	\| <code>a</code>		\| <code>a</code>
	\| a{{fmt/opt\|:{{fmt/arg\|domain-spec}}}} {{fmt/arg/opt\|dual-cidr-length}}		\| a{{fmt/opt\|:{{fmt/arg\|domain-spec}}}} {{fmt/arg/opt\|dual-{{l/sub\|cidr-length}}}}
	\| ~~matches~~ if {{arg\|domain-spec}} points to one of the {{arg\|host domain}}'s IP addresses		\| match if {{arg\|domain-spec}} points to one of the {{arg\|host domain}}'s IP addresses
	\|-		\|-
	\| <code>mx</code>		\| <code>mx</code>
	\| mx{{fmt/opt\|:{{fmt/arg\|domain-spec}}}} {{fmt/arg/opt\|dual-cidr-length}}		\| mx{{fmt/opt\|:{{fmt/arg\|domain-spec}}}} {{fmt/arg/opt\|dual-{{l/sub\|cidr-length}}}}
	\| ~~does~~ an MX lookup on the {{arg\|host domain}}, then ~~does an~~ address ~~lookup on~~ each MX name returned...		\| do an MX lookup on the {{arg\|host domain}}, then look up address for each MX name returned...
	* It's not yet clear what the pass/fail criteria are.		* It's not yet clear what the pass/fail criteria are.
	* Multiple MX mechanisms may be listed.		* Multiple MX mechanisms may be listed.
Line 40:		Line 41:
	<code>ip4</code><br>		<code>ip4</code><br>
	<code>ip6</code>		<code>ip6</code>
	\| ip''N''{{fmt/opt\|:{{fmt/arg\|ip''N''-network}}}} {{fmt/arg/opt\|ip''N''-cidr-length}}		\| ip''N''{{fmt/opt\|:{{fmt/arg\|ip''N''-network}}}} {{fmt/arg/opt\|ip''N''-{{l/sub\|cidr-length}}}}
			\| test whether sender is contained within a given IP network
			* can also match a specific IP address, apparently
	\|-		\|-
	\| <code>exists</code>		\| <code>exists</code>
			\| exists:{{fmt/arg\|domain-spec}}
			\| construct a domain name in various ways, and use that for a DNS A record query.
			* This allows for complex/fine-grained examination of the mail envelope to determine what is permitted
			* {{fmt/arg\|domain-spec}} is defined in [https://www.rfc-editor.org/rfc/rfc7208.html#section-7 Section 7].
	\|}		\|}
	==Footnote==		==Footnote==

Woozle: Woozle moved page SPF/mechanisms to SPF/mechanism without leaving a redirect

2022-08-18T15:36:56Z

Woozle moved page SPF/mechanisms to SPF/mechanism without leaving a redirect

← Older revision	Revision as of 15:36, 18 August 2022
(No difference)

Woozle: saving work and renaming page to depluralize

2022-08-18T15:36:42Z

saving work and renaming page to depluralize

New page

{{fmt/title|SPF mechanisms}}
==About==
Mechanisms used by [[../]] are defined in [https://www.rfc-editor.org/rfc/rfc7208.html#section-5 RFC 7208 Section 5]. We'll refer to {the domain to which a DNS record refers} as the {{arg|host domain}} (although the RFC refers to it as {{fmt/xml/tag|target-name}}).

Mechanisms are separated by spaces.

Commonly-used terms (are these defined in {{l/same|modifiers}}?):
* {{fmt/arg|dual-cidr-length}}: I don't yet know what this means.
* {{arg|domain-spec}} defaults to {{arg|host domain}}.
{| class="wikitable"
! code !! format || meaning
|-
| colspan=3 | '''Basic''':
|-
| <code>all</code>
| <code>all</code>
| a test that always matches; place as last mechanism in a record to provide an explicit default
|-
| <code>include</code>
| <code>include:{{arg|domain-spec}}</code>
| utility is unclear; includes evaluation of the given domain, but not in a clean way
|-
| colspan=3 | '''Designated sender''':
|-
| <code>a</code>
| a{{fmt/opt|:{{fmt/arg|domain-spec}}}} {{fmt/arg/opt|dual-cidr-length}}
| matches if {{arg|domain-spec}} points to one of the {{arg|host domain}}'s IP addresses
|-
| <code>mx</code>
| mx{{fmt/opt|:{{fmt/arg|domain-spec}}}} {{fmt/arg/opt|dual-cidr-length}}
| does an MX lookup on the {{arg|host domain}}, then does an address lookup on each MX name returned...
* It's not yet clear what the pass/fail criteria are.
* Multiple MX mechanisms may be listed.
|-
| <code><s>ptr</s></code>
|
| (do not use<ref name=ptr-note />)
|-
|
<code>ip4</code><br>
<code>ip6</code>
| ip''N''{{fmt/opt|:{{fmt/arg|ip''N''-network}}}} {{fmt/arg/opt|ip''N''-cidr-length}}
|-
| <code>exists</code>
|}
==Footnote==
<references>
<ref name=ptr-note>From the RFC (formatting added for clarity): {{fmt/quote|'''This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the {{l/wp|.arpa}} name servers.''' If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, '''it has been concluded that it is unnecessary and more reliable alternatives should be used instead.''' It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.}}</ref>
</references>