Hi Wayne,
I have now finally managed to read through the whole spec. Here are my
suggestions, with "#" style comments embedded (below the
changes they belong to).
You can also find the complete patch attached as a file. It includes the
comments, too, but current versions of `patch` should
properly ignore them.
--- draft-schlitt-spf-classic-00.xml Fri Dec 31 17:41:35 2004
+++ draft-schlitt-spf-classic-00-mehnle.xml Tue Jan 04 00:33:31 2005
@@ -2,3 +2,3 @@
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!DOCTYPE rfc SYSTEM "http://xml.resource.org/public/rfc/bibxml/rfc2629.dtd" [
<!ENTITY rfc1035 PUBLIC ''
@@ -36,3 +36,3 @@
]>
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+<?xml-stylesheet type='text/xsl'
href='http://greenbytes.de/tech/webdav/rfc2629.xslt' ?>
@@ -170,3 +170,4 @@
casually, this document defines the "MAIL FROM" identity in
- <xref target="mfrom-ident"/>. Note that other terms, that
+ <xref target="mfrom-ident"/>, and the "HELO" identity in
+ <xref target="helo-ident"/>. Note that other terms, that
may superficially look like the common terms, such as
#
# The HELO identity should be mentioned.
#
@@ -189,7 +190,7 @@
<t>
- SPF clients MAY check the "HELO" identity by calling the
- check_host() function (<xref target="function"/>) with the
+ SPF clients MAY check the "HELO" identity by applying the
+ check_host() function (<xref target="function"/>) to the
"HELO" identity as the <sender>. If the HELO test
- returns a "fail", the overall result for the SMTP session is
- "fail", and there is no need to test the "MAIL FROM" identity.
+ results in a "Fail", the overall result for the SMTP session is
+ "Fail", and there is no need to test the "MAIL FROM" identity.
</t>
#
# "Applying the function" and "the function results in" sound less code-ish and
# more algorithmic.
#
@@ -202,3 +203,3 @@
the sender mailbox, and is the mailbox to which notification
- messages are sent if there are problems delivering the
+ messages are to be sent if there are problems delivering the
message.
@@ -207,3 +208,3 @@
<xref target="RFC2821" /> allows the reverse-path to be null
- (see Section 4.5.5.) In this case, there is no explicit
+ (see Section 4.5.5). In this case, there is no explicit
sender mailbox, and such a message can be assumed to be a
#
# Fix grammar.
#
@@ -212,3 +213,3 @@
identity to be the mailbox composed of the localpart
- "postmaster" and the "HELO" identity
+ "postmaster" and the "HELO" identity.
</t>
#
# Fix grammar.
#
@@ -216,4 +217,4 @@
SPF clients MUST check the "MAIL FROM" identity unless HELO
- testing produced a "fail". SPF clients check the "MAIL
- FROM" identity by calling the check_host() function with the
+ testing produced a "Fail". SPF clients check the "MAIL
+ FROM" identity by applying the check_host() function to the
"MAIL FROM" identity as the <sender>.
#
# Use upper case in result codes everywhere for consistency.
# "Applying the function": see above.
#
@@ -244,3 +245,3 @@
mail message it receives. This check tests the
- authorization of a client host to inject mail with a given
+ authorization of a client host to emit mail with a given
"MAIL FROM" identity. This check MAY also be applied to the
@@ -249,3 +250,3 @@
processing chain so long as the required information is
- available. Checking other identities against SPF records is
+ available and reliable. Checking other identities against SPF
records is
NOT RECOMMENDED because there are cases that are known to
#
# Requiring the information to be reliable should be explicit.
#
@@ -257,3 +258,3 @@
of other tests may influence whether or not a particular SPF
- check is performed. For example, finding the sending host
+ check is performed. For example, finding the sending host's IP
address
on a local white list may cause all other tests to be
@@ -271,3 +272,3 @@
To make the test, the mail receiver MUST evaluate the
- check_host() with the arguments set as follows:
+ check_host() function with the arguments set as follows:
</t>
@@ -276,3 +277,3 @@
<t hangText="<ip>">- the IP address of the SMTP client
- that is injecting the mail, either IPv4 or IPv6.
+ that is emitting the mail, either IPv4 or IPv6.
</t>
@@ -289,8 +290,6 @@
formed domain name. For example, if the reverse-path was
- null, then the EHLO or HELO domain is used. In a valid SMTP
- session, this can be an address literal or entirely
+ null, then the EHLO/HELO domain is used. In a valid SMTP
+ session, this could be an IP address literal or entirely
#
# "EHLO or HELO domain" implies that these are distinct concepts,
# "EHLO/HELO domain" doesn't.
# "can be" somewhat implies that IP address literals and entirely null
# identities are the usual case, the subjunctive is less strong in this
# regard.
# Make it clear that "address literal" refers to an IP address literal.
#
malformed. In these cases, check_host() is defined in <xref
target="initial" /> to return a "None" result.
- <!-- FIXME: should this be "None"? lots of conflict between -->
- <!-- PermError in the various specs and implementations -->
</t>
#
# I think "None" is a good choice. The only real alternative would be
# "PermError", but that one shouldn't be used to indicate problems with
# messages, but only problems with SPF records.
#
@@ -306,5 +305,5 @@
<t>
- Software SHOULD perform this authorization check during the
- processing of the SMTP transaction that injects the mail.
- This allows errors to be returned directly to the injecting
+ This authorization check SHOULD be performed during the
+ processing of the SMTP transaction that sends the mail.
+ This allows errors to be returned directly to the sending
server by way of SMTP replies. Software can perform the
#
# Avoid mentioning the "software" in the first sentence because not every
# software that might be acting as an SPF client handles SMTP transactions
# (MUAs for example). Instead, give emphasis to the main point of the
# sentence.
#
@@ -314,4 +313,4 @@
<t>
- Software can perform the authorization after the
- corresponding SMTP transaction has completed. There are two
+ Software can also perform the authorization after the
+ corresponding SMTP transaction has completed. However there are two
problems with this approach: 1) It may be difficult to
#
# Improve wording to make clear that "offline" SPF checking is just a
# suboptimal alternative to "on-the-fly" checking.
#
@@ -321,3 +320,3 @@
notification to the alleged sender is problematic due to the
- large number of forged emails on the Internet today. Such
+ large number of forged e-mails on the Internet today. Such
an action would go against the explicit wishes of the
#
# Fix spelling of the word "e-mail". Also, be consistent with other
# occurrances of the word.
#
@@ -328,3 +327,3 @@
<t>
- The check_host() function returns one of seven results.
+ The check_host() function returns one of several result codes.
This section describes how software that performs the
#
# Do not "hard-code" the number of distinct result codes.
#
@@ -336,4 +335,5 @@
<t>
- A result of None means that no records were published by
- the domain. The checking software cannot ascertain if the
+ A result of "None" means that no records were published by
+ the domain, or that no checkable sender domain could be
+ determined from the given identity. The checking software cannot
ascertain if the
client host is authorized or not.
#
# For consistency, always quote result codes. Also, note the other valid
# reason why a "None" result could occur.
#
@@ -343,5 +343,6 @@
<t>
- The domain owner has explicitly stated that doesn't know
- whether the IP is authorized or not. A Neutral result
- MUST be treated exactly like the None result.
+ The domain owner has explicitly stated that he doesn't know
+ whether the IP is authorized or not. A "Neutral" result
+ SHOULD be treated exactly like the "None" result; the
+ distinction exists only for informational purposes.
</t>
#
# Fix grammar: insert missing "he". Quote result code.
# There is no point in trying to enforce local policy decisions. We can
# make it clear that the meaning of "Neutral" is supposed to match that of
# "None", but we cannot force receivers to treat them identically.
#
@@ -350,3 +351,3 @@
<t>
- A Pass result means that the client is authorized to
+ A "Pass" result means that the client is authorized to
inject mail with the given identity. Further
@@ -358,3 +359,3 @@
<t>
- A Fail result is an explicit statement that the client is
+ A "Fail" result is an explicit statement that the client is
not authorized to use the domain in the given
@@ -369,3 +370,3 @@
target="RFC2034"/>), in addition to an appropriate
- message. The check_host() function may return either a
+ reply text. The check_host() function may return either a
default explanation string, or one from the domain that
#
# Clarify: "reply text" is the wording used by RFC 2821.
#
@@ -386,4 +387,4 @@
<t>
- A SoftFail result should be treated as somewhere between a
- Fail and a Neutral. The domain believes the host isn't
+ A "SoftFail" result should be treated as somewhere between a
+ "Fail" and a "Neutral". The domain believes the host isn't
authorized but isn't willing to make that strong of a
@@ -396,8 +397,4 @@
receivers MAY try to inform either the sender or the
- recipient of the e-mail. As examples, the recipient's MUA
- could highlight the SoftFail status. Or the MTA could
- give the sender a message using a technique called
- "greylisting" where by the MTA can issue an SMTP reply
- code of 451 (4.3.0 DSN code) with a note the first time
- the message was received, but accept it the second time.
+ recipient of the e-mail. For example, the recipient's MUA
+ could highlight the "SoftFail" status.
</t>
#
# Drop the "greylisting" example. The point of greylisting "SoftFail"
# messages is not evident, especially since some spammers already know how
# to circumvent greylisting.
#
@@ -406,3 +403,3 @@
<t>
- A TempError result means that the SPF client encountered a
+ A "TempError" result means that the SPF client encountered a
transient error when performing the check. Checking
@@ -417,3 +414,3 @@
<t>
- A PermError result means that the domain's published
+ A "PermError" result means that the domain's published
records couldn't be correctly interpreted. Checking
@@ -428,3 +425,3 @@
<t>
- An SPF record declares which hosts are, and are not,
+ An SPF record is a DNS Resource Record (RR) that declares which hosts
are, and are not,
authorized to use a domain name for the "HELO" or "MAIL FROM"
#
# This first paragraph about SPF records should explain right away that
# they are DNS RRs.
#
@@ -443,3 +440,3 @@
<t>
- This record has a version of "v=spf1" and three directives:
+ This record has a version of "spf1" and three directives:
"+mx", "a:colo.example.com/28" (the + is implied), and "-all".
#
# The version string is not "v=spf1", but "spf1".
#
@@ -453,3 +450,3 @@
it, such as is done with SRV records. This is the same
- whether TXT RRs or SPF RRs are used.
+ whether the TXT or SPF RR type is used.
</t>
#
# Fix semantics of sentence.
#
@@ -468,12 +465,12 @@
published there for other purposes. They may cause problems
- with size limits (see <xref target="rsize"/>.)
+ with size limits (see <xref target="rsize"/>).
</t>
#
# Fix grammar.
#
<t>
- An SPF record published at the zone cut for the domain will
- be used as a default for all subdomains within the zone (See
- <xref target="version"/>.) Domain owners SHOULD publish SPF
+ An SPF record published at the zone cut for the domain is
+ considered a default for all subdomains within the zone (see
+ <xref target="version"/>). Domain owners SHOULD publish SPF
#
# The described assumption applies to publishers and publishing software
# as well, not just to SPF checking software. Fix grammar.
#
records for hosts used for the HELO and MAIL FROM identities
- instead of using the zone cut default because the fallback
+ instead of relying on the zone cut default because the fallback
#
# Domain owners AKA publishers don't "use" the zone cut default, only
# receivers do.
#
requires additional DNS lookups. The zone cut default does
- reduce the need to publish SPF records for non-email related
+ reduce the need to publish SPF records for non-e-mail related
hosts, such as www.example.com.
#
# Fix spelling of the word "e-mail".
#
@@ -482,3 +479,3 @@
<t>
- This document defines a new DNS Resource Record (RR) of
+ This document defines a new DNS RR of
type SPF, type code to be determined. The format of this
#
# "DNS RR" has been explained above already (see suggested change), so use
# the abbreviation.
#
@@ -512,6 +509,8 @@
<t>
- An SPF compliant check SHOULD lookup both types. Lookups
- can be performed serially or in parallel. If both types of
- records are obtained for a domain, the SPF type MUST be
- used.
+ An SPF compliant check SHOULD try to look up and use
+ a record of the SPF type first, before falling back to the
+ TXT type. However, the client MAY also perform lookup
+ of both types in parallel. If for a domain both types
+ are obtained but their contents do not match, the SPF
+ client SHOULD return a "PermError" result.
</t>
#
# Make it clear that the SPF record type is preferred. But if both TXT
# and SPF type records are actually obtained, make sure they are
# congruent.
#
@@ -519,3 +518,3 @@
Example RRs in this document are shown with the TXT record
- type, however they could also be published with both RR types.
+ type, however they could be published with the SPF type or with
both types.
</t>
#
# Avoid the misconception that only publishing the SPF type were
# unacceptable.
#
@@ -571,3 +570,3 @@
are too long to fit in a single UDP packet MAY be
- silently ignored.
+ silently ignored by SPF clients.
</t>
#
# Clarify.
#
@@ -618,3 +617,3 @@
The check_host() function fetches SPF records, parses them,
- and interprets them to evaluate if a particular host is or is
+ and interprets them to determine if a particular host is or is
not permitted to send mail with a given
@@ -625,3 +624,3 @@
Implementations MAY use a different algorithm than the canonical
- algorithm defined here, so long as the results are the same.
+ algorithm defined here, so long as the results are the same in all
cases.
</t>
@@ -632,6 +631,7 @@
<t hangText="<ip>">- the IP address of the SMTP client
- that is injecting the mail, either IPv4 or IPv6.
+ that is emitting the mail, either IPv4 or IPv6.
</t>
- <t hangText="<domain>">- the domain portion of the
- "MAIL FROM" or "HELO" identity.
+ <t hangText="<domain>">- the domain that provides the
+ sought-after authorization information; initially the
+ domain portion of the "MAIL FROM" or "HELO" identity.
</t>
#
# Mention the point that <domain> is not constant, and more accurately
# explain its meaning.
#
@@ -645,3 +645,3 @@
same as the <domain> argument when check_host() is
- initially evaluated. However, it will generally not be true for
+ initially evaluated. However, this will generally not be true for
recursive evaluations (see <xref target="mech-include"/>
@@ -650,5 +650,5 @@
<t>
- Actual implementations of the check_host() function will
- likely need additional arguments.
- </t>
+ Actual implementations of the check_host() function may
+ need additional arguments.
+ </t>
</section>
#
# It is not clear why implementations of check_host() would "likely" need
# additional arguments.
#
@@ -656,3 +656,3 @@
<t>
- The function check_host() can result in one of seven results
+ The function check_host() can return one of several results
described in <xref target="op-result"/>. Based on the
#
# "To result in a result" is poor wording. Also, do not "hard-code" the
# number of distinct result codes.
#
@@ -678,3 +678,3 @@
for the <domain> name, querying for either RR type
- TXT, SPF or both.
+ TXT, SPF, or both.
</t>
#
# Fix grammar.
#
@@ -721,3 +721,3 @@
<t>
- If no matching records are returned for the <domain;>,
+ If no matching records are returned for the <domain>,
the SPF client MUST find the Zone Cut as defined in <xref
@@ -758,4 +758,4 @@
-directive = [ prefix ] mechanism
-prefix = "+" / "-" / "?" / "~"
+directive = [ sign ] mechanism
+sign = "+" / "-" / "?" / "~"
mechanism = ( all / include
#
# The term "prefix" is too generic.
#
@@ -794,3 +794,3 @@
<t>
- If it matches, processing ends and the prefix value is
+ If it matches, processing ends and the sign value is
returned as the result of that record. If it does not
@@ -801,3 +801,3 @@
<t>
- The possible prefixes, and the results they return are:
+ The possible signs, and the results they return are:
<list style="hanging">
@@ -809,5 +809,5 @@
</t>
- <t> The prefix is optional and defaults to "+". </t>
+ <t> The sign is optional and defaults to "+". </t>
<t>
- When a mechanism matches, and the prefix is "-" so that a
+ When a mechanism matches and the sign is "-", then a
"Fail" result is returned and the explanation string is
#
# Fix grammar/semantics.
#
@@ -815,3 +815,3 @@
</t>
- <t> Specific mechanisms are described in <xref
target="mechanisms"/>. </t>
+ <t> The specific mechanisms are described in <xref
target="mechanisms"/>. </t>
</section>
#
# Fix semantics.
#
@@ -821,3 +821,3 @@
not-match. Instead they provide additional information.
- While modifiers do not directly effect the evaluation of
+ While modifiers do not directly affect the evaluation of
the record, the "redirect" modifier has an effect after
@@ -831,3 +831,3 @@
modifier, then the check_host() returns a result of
- "Neutral". If there is a "redirect" modifier, check_host()
+ "Neutral", just as if "?all" were specified as the last directive.
If there is a "redirect" modifier, check_host()
proceeds as defined in <xref target="mod-redirect"/>.
#
# Clarify.
#
@@ -964,7 +964,9 @@
In hind sight, the name "include" was poorly chosen. Only
- the evaluated results of the referenced SPF record is used,
+ the evaluated result of the referenced SPF record is used,
#
# Fix grammar.
#
rather than acting as if the referenced SPF record was
- literally included in the first. Better names for this
- mechanism would have been something like "on-pass" or
- "if-pass".
+ literally included in the first. For example, evaluating a
+ "-all" directive in the referenced record does not terminate
+ the overall processing and does not necessarily result in a
+ overall "Fail". Better names for this mechanism would have
+ been "call", "eval, "on-pass", or "if-pass".
</t>
#
# Clarify. Also, suggest better names for the "include" mechanism.
#
@@ -985,3 +987,3 @@
That would direct check_host() to, in effect, check the
- records of example.com and example.org for a "pass"
+ records of example.com and example.org for a "Pass"
result. Only if the host were not permitted for either of
@@ -1056,4 +1058,5 @@
each MX name returned. The <ip> is compared to each
- returned IP address. To prevent DoS attacks, a limit of 10
- MX names MUST be enforced (see <xref target="security" />).
+ returned IP address. To prevent DoS attacks, more than 10
+ MX names MUST NOT be looked up during the evaluation of a
+ "mx" mechanism (see <xref target="security" />).
If any address matches, the mechanism matches.
#
# Clarify.
#
@@ -1088,4 +1091,5 @@
name by looking up its IP address. To prevent DoS attacks,
- a limit of 10 PTR names MUST be enforced (see <xref
- target="security" />). If <ip> is among the returned
+ more than 10 PTR names MUST NOT be looked up during the
+ evaluation of a "ptr" mechanism (see <xref target="security" />).
+ If <ip> is among the returned
IP addresses, then that domain name is validated. In
#
# Clarify.
#
@@ -1153,3 +1157,2 @@
ip6-cidr-length = "/" 1*DIGIT
-dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
#
# Drop irrelevant ABNF rule. (It's still in the collected ABNF, though.)
#
@@ -1227,5 +1230,5 @@
<t>
- Unrecognized modifiers SHOULD be ignored no matter where in
+ Unrecognized modifiers MUST be ignored no matter where in
a record, nor how often. This allows implementations of
- this document to handle records with modifiers that are
+ this document to gracefully handle records with modifiers that are
defined in other specifications.
#
# There is no point in not strictly requiring unrecognized modifiers to be
# ignored. What should implementations do if they choose not to ignore
# them?
#
@@ -1278,3 +1281,3 @@
same, there is no guarantee that the record at domain "B"
- will correctly work for addresses in domain "A", especially
+ will correctly work for mailboxes in domain "A", especially
if domain "B" uses mechanisms involving localparts. An
#
# Use the term "mailbox" instead of "address" or "e-mail address" for
# consistency, just like Mark Lentczner did everywhere.
#
@@ -1386,6 +1389,6 @@
<t>
- Note: During recursion into an "include" mechanism, exp=
- modifiers do not propagate out. In contrast, during
- execution of a "redirect" modifier, the explanation string
- from the target of the redirect is used.
+ Note: During recursion into an "include" mechanism, an exp=
+ modifier from the target domain MUST NOT be used. In
+ contrast, when executing a "redirect" modifier, an exp=
+ modifier from the original domain MUST NOT be used.
</t>
#
# "Do not propagate out"? Huh? Clarify. Also, make behavior a strict
# requirement.
#
@@ -1426,11 +1429,10 @@
<t>
- SPF implementations MUST limit the number of mechanism that
- do DNS lookups to at most 10, if this number is exceeded, a
- PermError MUST be returned. The mechanisms that count
- against this limit are "include", "a", "mx", "ptr", "exists"
- and the "redirect" modifier. The "all", "ip4" and "ip6"
+ SPF client implementations MUST limit the number of mechanisms
+ and modifiers that do DNS lookups to at most 10 per SPF check.
+ 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" and "exp" modifiers 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 requires a DNS
- lookup, but it is not counted as it is used only in the case
- of errors.
+ count against this limit.
</t>
#
# Only _client_ implementations should be concerned by this. Explicitly
# mention modifiers in this requirement.
# Also, there is no point in excluding the "exp" modifier just because "it
# is used only in the case of errors". Attackers will not care about it
# only being used in the case of errors, and thus might exploit such an
# exemption.
#
@@ -1498,3 +1500,3 @@
defined here. This information is intended for the
- recipient. (Information intended for the sender described
+ recipient. (Information intended for the sender is described
in <xref target="mod-exp"/>, Explanation.)
@@ -1502,3 +1504,3 @@
<t>
- The Received-SPF header is a trace field (See <xref
+ The Received-SPF header is a trace field (see <xref
target="RFC2822"/> section 3.6.7) and SHOULD be
@@ -1512,7 +1514,7 @@
<artwork type="abnf">
-header = "Received-SPF:" [CFWS] result [CFWS]
+header = "Received-SPF:" [CFWS] result [FWS [comment]]
[ key-value-list ]
#
# Although the semantics were already correct, the <comment> string should
# be explicitly mentioned so that the below text can refer to it.
#
-result = "Pass" / "Fail" / "TempError" / "SoftFail" /
- "Neutral" / "None" / "PermError"
+result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+ "None" / "TempError" / "PermError"
#
# Re-order the result codes intelligently.
#
@@ -1524,6 +1526,6 @@
dot-atom = ; unquoted word as per [RFC2822]
-
quoted-string = ; quoted string as per [RFC2822]
-
+comment = ; comment string as per [RFC2822]
CFWS = ; comment or folding white space as per [RFC2822]
+FWS = ; folding white space as per [RFC2822]
</artwork>
#
# Define <comment> and <FWS>. Drop unnecessary blank lines.
#
@@ -1532,3 +1534,4 @@
<t>
- The <comment-string> should convey supporting
+ The header SHOULD include a "(...)" style <comment> after the
+ result, conveying supporting
information for the result, such as <ip>,
#
# Clarify.
#
@@ -1544,3 +1547,3 @@
<t hangText="client-ip"> the IP address of the SMTP client</t>
- <t hangText="envelope-from"> the envelope sender address</t>
+ <t hangText="envelope-from"> the envelope sender mailbox</t>
<t hangText="helo"> the host name given in the HELO
@@ -1626,3 +1629,3 @@
<t>
- Many mechanisms and modifiers perform macro interpolation on
+ Many mechanisms and modifiers perform macro expansion on
part of the term.
@@ -1633,2 +1636,3 @@
domain-end = ( "." toplabel ) / macro-expand
+
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
#
# Insert a blank line to make the ABNF more readable.
#
@@ -1636,5 +1640,7 @@
alphanum = ALPHA / DIGIT
-macro-string = *( macro-expand / macro-literal )
+
explain-string = *( macro-string / SP )
-macro-expand = ( "%{" macro-letter transformer *delimiter "}" )
+
+macro-string = *( macro-expand / macro-literal )
+macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
#
# Insert blank lines to make the ABNF more readable. Also, swap around
# the definitions of "macro-string" and "explain-string" for the same
# reason.
# Rename the "transformer" item into "transformers", as it stands for
# multiple transformers, not just for a single one.
#
@@ -1644,3 +1650,3 @@
"c" / "r" / "t"
-transformer = *DIGIT [ "r" ]
+transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
#
# Rename the "transformer" item into "transformers". See above.
#
@@ -1742,3 +1748,3 @@
The "s" macro expands to the <sender> argument. It is
- an e-mail address with a localpart, an "@" character, and a
+ a mailbox address with a localpart, an "@" character, and a
domain. The "l" macro expands to just the localpart. The "o"
@@ -1770,3 +1776,3 @@
any name from the list may be used. If there are no
- validated domain name or if a DNS error occurs, the string
+ validated domain names or if a DNS error occurs, the string
"unknown" is used.
#
# Fix grammar.
#
@@ -1776,5 +1782,5 @@
SHOULD be a fully qualified domain name, but if one does not
- exist (as when the checking is done by a script) or if
+ exist (as when the checking is done by a MUA) or if
#
# "A script"? Huh?
#
policy restrictions dictate otherwise, the word "unknown"
- should be substituted. The domain name may be different than
+ SHOULD be substituted. The domain name may be different than
the name found in the MX record that the client MTA used to
#
# Make the statement a formal recommendation.
#
@@ -1793,3 +1799,3 @@
(the maximum length of a domain name), the left side is
- truncated to fit, by removing successive subdomains until
+ truncated to fit, by removing successive domain labels until
the total length does not exceed 253 characters.
@@ -1799,6 +1805,6 @@
equivalents, and are then URL escaped. URL escaping for the
- non-uric characters is described in <xref target="RFC2396"/>.
+ non-URIish characters is described in <xref target="RFC2396"/>.
</t>
#
# Is "uric" supposed to be a pun on the word "urine"? No, thanks.
#
<t>
- Note: Domains should avoid using the "s", "l", "o" or "h"
+ Note: Domains SHOULD NOT use the "s", "l", "o", or "h"
macros in conjunction with any mechanism directive. While
#
# Make statement a formal recommendation.
#
@@ -1855,13 +1861,13 @@
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
-bad.strong.lp.3.2.0.192.in-addr._spf.example.com
+ bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
-3.2.0.192.in-addr.strong.lp._spf.example.com
+ 3.2.0.192.in-addr.strong.lp._spf.example.com
%{d2}.trusted-domains.example.net
-example.com.trusted-domains.example.net
+ example.com.trusted-domains.example.net
IPv6:
-%{ir}.%{v}._spf.%{d2} 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.
-5.d.a.0.8.0.0.0.2.5.0.f.5.ip6._spf.example.com
+%{ir}.%{v}._spf.%{d2} 1.0.0.0.0.0.0.0.
+0.0.0.0.0.0.0.0.0.0.8.5.d.a.0.8.0.0.0.2.5.0.f.5.ip6._spf.example.com
</artwork>
#
# Align the expanded strings to the right to make the examples more
# readable.
#
@@ -1896,3 +1902,3 @@
"tracking exists:" mechanism. By looking at the name server
- logs, an incompletely list may be generated. For example:
+ logs, an rough list may then be generated. For example:
<list>
#
# Fix grammar/semantics.
#
@@ -1906,3 +1912,3 @@
<t>
- Mailing lists must be aware of how they re-inject mail that
+ Mailing lists must be aware of how they re-send mail that
is sent to the list. Mailing lists MUST comply with the
@@ -1910,3 +1916,3 @@
<xref target="RFC1123"/> Section 5.3.6 that say that the
- reverse-path MUST be changed to be the address of a person
+ reverse-path MUST be changed to be the mailbox of a person
or other entity who administers the list. While the reasons
@@ -1918,3 +1924,3 @@
complies with this requirement. Mailing lists that do not
- comply, may or may not encounter problems depending on how
+ comply may or may not encounter problems depending on how
access to the list is restricted. Such lists that are
#
# Fix grammar.
#
@@ -1929,3 +1935,3 @@
writing, the near-universal practice of such services is to
- use the original MAIL FROM of a message when re-injecting
+ use the original MAIL FROM of a message when re-sending
it for delivery to the external mailbox. <xref
@@ -1941,3 +1947,3 @@
mailbox wishes to trust the forwarding service, they can
- direct the external mailbox's MTA to skip such tests when
+ direct the external mailbox's MTA to skip SPF tests when
the client host belongs to the forwarding service. Tests
#
# Clarify.
#
@@ -1954,4 +1960,4 @@
<t>
- Forwarding services can also solve the problem by using
- MAIL FROM that contain their own domain. This means
+ Forwarding services can also solve the problem by rewriting the
+ MAIL FROM to be in their own domain. This means
that mail bounced from the external mailbox will have to be
#
# Clarify.
#
@@ -1960,8 +1966,8 @@
resource requirements on the part of the forwarding service.
- Several popular MTAs can change "alias" semantics to
- "mailing list" semantics by including an adding another
- alias with "owner-" added to the beginning of the alias
- name. (e.g. an alias of "friends: george(_at_)example(_dot_)com,
+ Also, several popular MTAs can be forced from "alias" semantics to
+ "mailing list" semantics by configuring an additional
+ alias with "owner-" prepended to the original alias
+ name (e.g. an alias of "friends: george(_at_)example(_dot_)com,
#
# Improve wording.
#
fred(_at_)example(_dot_)org" would need another alias of the form
- "owner-friends: localowner")
+ "owner-friends: localowner").
</t>
#
# Fix grammar.
#
@@ -1970,7 +1976,7 @@
<t>
- Entities that offer mail services to other domains such as
- sending of bulk mail will may have to alter their mail in
- light of the authorization check in this document. If the
+ Service providers that offer mail services to third party domains,
such as
+ sending of bulk mail, may have to adjust their setup in
+ light of the authorization check described in this document. If the
MAIL FROM used for such e-mail uses the domain of the
- mail service provider, then the provider needs only to
+ service provider, then the provider needs only to
ensure that their sending host is authorized by their own
#
# Improve wording.
#
@@ -1981,4 +1987,4 @@
domain, then extra care must be taken. The SPF record
- format has several options for authorizing the sending MTAs
- of another domain (the service provider's)
+ format has several options for the third party domain to authorize
+ the service provider's MTAs to send mail on its behalf.
</t>
#
# Improve wording.
#
@@ -1993,4 +1999,4 @@
However, for purposes of this document, such relays are effectively
- invisible. The "MAIL FROM" identity authorization check is a check
- between border MTAs.
+ transparent. The "MAIL FROM" identity authorization check is a check
+ between border MTAs of different domains.
</t>
#
# Improve wording. Clarify.
#
@@ -2004,3 +2010,4 @@
Mail receivers will generally want to perform the authorization check
- at the border MTAs. This allows mail that fails to be rejected
+ at the border MTAs, specifically including all secondary MXes.
+ This allows mail that fails to be rejected
during the SMTP session rather than bounced. Internal MTAs then do
#
# Clarify.
#
@@ -2018,3 +2025,3 @@
construed to provide more assurance than it does. It is
- entirely possible for a malicious sender to inject a message
+ entirely possible for a malicious sender to send a message
using their own domain in the identities used by SPF, to have
@@ -2068,3 +2075,3 @@
<t>
- While implementations of check_host() need to limit the
+ While implementations of check_host() are supposed to limit the
number of DNS lookups, malicious domains could publish
#
# Fix semantics.
#
@@ -2132,3 +2139,3 @@
<t>
- Philip Gladstone contributed macros to the specification,
+ Philip Gladstone contributed the concept of macros to the
specification,
multiplying the expressiveness of the language and making
#
# Fix semantics.
#
@@ -2139,3 +2146,3 @@
individuals who have participated in the development of this
- design. There are far too numerous to name, but they include:
+ design. They are far too numerous to name, but they include:
</t>
#
# Fix grammar.
#
@@ -2269,5 +2276,7 @@
alphanum = ALPHA / DIGIT
-macro-string = *( macro-expand / macro-literal )
+
explain-string = *( macro-string / SP )
-macro-expand = ( "%{" macro-letter transformer *delimiter "}" )
+
+macro-string = *( macro-expand / macro-literal )
+macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
#
# Replicate inline ABNF grammar changes from above.
#
@@ -2277,3 +2286,3 @@
"c" / "r" / "t"
-transformer = *DIGIT [ "r" ]
+transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
#
# Replicate...
#
@@ -2282,7 +2291,7 @@
-header = "Received-SPF:" [CFWS] result [CFWS]
+header = "Received-SPF:" [CFWS] result [FWS [comment]]
[ key-value-list ]
-result = "Pass" / "Fail" / "TempError" / "SoftFail" /
- "Neutral" / "None" / "PermError"
+result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+ "None" / "TempError" / "PermError"
#
# Replicate...
#
@@ -2294,6 +2303,6 @@
dot-atom = ; unquoted word as per [RFC2822]
-
quoted-string = ; quoted string as per [RFC2822]
-
+comment = ; comment string as per [RFC2822]
CFWS = ; comment or folding white space as per [RFC2822]
+FWS = ; folding white space as per [RFC2822]
</artwork>
#
# Replicate...
#
@@ -2307,8 +2316,7 @@
; and two servers at the domain name
-
$ORIGIN example.com.
@ MX 10 mail-a
-MX 20 mail-b
-A 192.0.2.10
-A 192.0.2.11
+ MX 20 mail-b
+ A 192.0.2.10
+ A 192.0.2.11
amy A 192.0.2.65
#
# Fix formatting.
#
@@ -2320,4 +2328,3 @@
; A related domain
-
-$ORIGIN example.org
+$ORIGIN example.org.
@ MX 10 mail-c
@@ -2326,3 +2333,2 @@
; The reverse IP for those addresses
-
$ORIGIN 2.0.192.in-addr.arpa.
@@ -2338,3 +2344,2 @@
; something it's not
-
$ORIGIN 0.0.10.in-addr.arpa.
@@ -2411,4 +2416,4 @@
This record would be used if mail from example.org actually came
- through servers at example.com and example.net. Example.org's
- designated servers are the union of example.com and example.net's
+ through servers at example.com and example.net. example.org's
+ designated servers are the union of example.com's and example.net's
designated servers.
#
# Fix syntax and grammar.
#
@@ -2425,3 +2430,3 @@
system to make use of that mail system's record. In this way, only
the
- mail system's record needs to updated when the mail setup changes.
+ mail system's record needs to be updated when the mail setup changes.
These domains' records never have to change.
#
# Fix grammar.
#
@@ -2436,3 +2441,3 @@
<artwork>
-$Origin _spf.example.com.
+$ORIGIN _spf.example.com.
mary.mobile-users A 127.0.0.2
#
# Improve formatting.
#
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
draft-schlitt-spf-classic-00-mehnle.xml.diff
Description: Binary data