In <42684379.45AE@xyzzy.claranet.de> Frank Ellermann <email@example.com> writes: > Fresh from the FUD factory:
> Sigh... It's really not Andy's fault if he's forced to explain
> the "zone cut" as a major difference between "classic SPF" and
> "original SPF". It's the same problem on the ASRG list or on
> WTH is going on with the SPF Council and Wayne's draft -01 ?
Frank: I've been a bum.
That being said, here are my comments on Andy's I-D: : 2.1.1 Original SPF
: The specification in  (and its immediate predessor) was the first
: specification considered to contain the basis of SPF.
I disagree that draft-mengwong-spf-00.txt was the first specification
considered to contain the basis of SPF. It is actually one of the
last. Developement of SPF had been going on for about 9 months with
over a dozen different drafts before that particular one.
The first SPF draft to be considered useful for deployment was
draft-mengwong-spf.02.9.3.txt, released Dec 9, 2003. Several
revisions, mostly editorial improvements were made between then and
Feb 11, 2004 when draft-mengwong-spf-00.txt was released.
It may be that the draft-mengwong-spf-00.txt version was the first to
be submitted to the IETF, but it was hardly the first to be the basis
On May 16, 2004 the draft-mengwong-spf-01.txt draft was release, which
I'm pretty sure was also submitted to the IETF. : 2.1.2 SPF Classic
: There exists some ambiguity regarding the term "Classic SPF" or "SPF
: Classic" as it was originally used to distinquish original SPF
: (Section 2.1.1) from a variant of SPF known as Sender ID (Section
: 2.1.3). However, the more recent use of the term "SPF Classic"
: refers to . This specification differs from original SPF (Section
: 2.1.1) in the following ways:
: o DNS lookups that fail to find TXT records will use an algorithm to
: find DNS zone cuts and requery the DNS further up the tree.
As Meng indicated, this has been eliminated from the working documents
for the spf-classic-01 draft. : o Checking of the fully qualified domain name given in an SMTP HELO
: or EHLO command is optional even if an address is given in the
: SMTP MAIL FROM command.
HELO checking was optional in the draft-mengwong-spf-01.txt draft. At
the time of the writting of that draft, there was only "SPF", and this
draft is generally considered to be the target of what is considered
to be "SPF classic".
The current draft-schlitt-spf-classic-* drafts are aimed at
reconciling the differences between the most common SPF implmentations
and the various SPF drafts. The intent is to be as close to
draft-mengwong-spf-01 as possible, while using the wordsmithng done
during the MARID work group.
So, really, I think you should eliminate the "original SPF" section
since all SPF drafts have been evolving. The hope is that the
draft-schlitt-spf-classic-* versions will be the final product of SPF
version 1. : 2.1.3 Sender ID
: This variant of SPF is defined by  ,  and . It differs from
: It should be noted that some proponents of SPF Classic (Section
: 2.1.2) do not consider Sender ID (Section 2.1.3) to be a legitimate
: variant of SPF. This may cause confusion when determining the
: compliance of software.
If, by "some proponents", you mean "all but a few", then yeah.
To reduce the confusion caused by this, you should not call Sender ID
a variant of SPF. You could say that Sender ID has origins in both
SPF and Microsoft's CallerID. : o The email identity used is determined by the publisher of the SPF
: o It defines a new email identity that is selected from the headers
: of the email message using an algorithm called the Purported
: Responsible Address (PRA).
Please make sure you mention that there are many known cases where the
use of existing SPF records for Sender ID will cause email to be
incorrectly rejected. Most of these cases aren't common at this time,
but they are likely to grow. : o The syntax of the record can either be the SPF syntax specified by
: original SPF (Section 2.1.1) (identified by the "v=spf1" version
: identifier) or a slightly different SPF syntax (identified by the
: "spf2.0" identifier).
As you well know, the MARID working group determined that it was not
appropriate for Sender ID to use SPF v1 records and it was decided
that they *MUST* use "spf2.0" records. As you well know, the IETF
requested that the *MARID* documents be submitted as experimental RFCs
and that the current SenderID documents fail on both of these points. : The domain name given on line 2 (felix.example.net) of the SMTP
: transaction is the HELO identity, and it is suppose to be the fully
: qualified domain name of the mail server sending the email. Original
: SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) specify that an
: SPF DNS TXT resource record by that name is to be consulted to
: determine if the source IP address of the SMTP connection is
: authorized to act on behalf of the HELO identity.
Please change "original SPF and SPF Classic" to "SPF", or "all
versions of SPF". : The domain name of the email address in Line 4 (example.com) is the
: MAIL FROM identity used by original SPF (Section 2.1.1) and SPF
: Classic (Section 2.1.2)
Same here. : Lines 10 through 12 are the headers of the email message. The PRA
: algorithm selects an identity from these headers. In this example,
: the PRA specifies the email address in Line 11 and the use of the
: domain name in that email address (example.net) as the Purported
: Responsible Domain (PRD). An SPF DNS TXT resource record by that
: name is to be consulted to determine if the source IP address of the
: SMTP connection is authorized to act on behalf of the PRA identity.
: See .
Please change this to "SPF2.0 DNS TXT rouce records" so as to confirm
to what you told the SenderID folks to do. : Since the PRA is the only identity verified that is part of the email
: message, verification of the PRA is the only part of SPF that
: attempts to insure that end-users see authorized email addresses.
: However, the PRA algorithm does not always select an identity that is
: shown to end users by mail clients. Therefore, SPF is not guaranteed
: to prevent end users from seeing forged identities.
Please change "SPF" to "SenderID".
Also please note that PRA checks both the Sender: header and the
Resent-* headers. In different situations, both of these headers may
be added and they may be added in different orders. As a result, the
PRA can not possibly be correct in all known cases, there will always
be times where it will give incorrect results. : 3.3 Publisher's Intent
: For the purposes of backwards compatibility, Sender ID (Section
: 2.1.3) interprets the first record to be equivalent to "spf2.0/
: mfrom,pra", which is to say that both MAIL FROM and PRA checks are to
: occur. To avoid confusion, senders should explicitly publish spf2.0/
: mfrom records. If a sender has not taken prepatory steps to
: accomodate PRA checking, a non-committal SPF record of "spf2.0/mfrom
: ?all" will signal that all PRA checking against this domain will have
: unknown results.
Opt-out is evil and generally used by spammers. : 5. Usage of Headers for Check Status
: Original SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) defines
Again, get rid of the distinction between "original SPF" and "SPF classic". : 6. DNS Usage
: 6.1 Mechansim Lookups
: Network administrators need to be conscious of the fact that SPF
: records can create more load on their DNS servers than just that of
: querying the SPF records.
: SPF Classic (Section 2.1.2), which has the most strict upper bounds
: on DNS lookups, allows for 10 SPF mechanisms that may trigger
: subsequent DNS lookups. In turn each mechanism may require more than
: one DNS lookup to fulfill the requirements of the mechanism. The
: theoretical maximum to conduct an SPF check is 111 DNS lookups. For
: instance, the appearance of one "mx" mechanism in an SPF record could
: result in 10 DNS lookups in the process of following the targets of
: the queried DNS MX records.
This is actually one of the real changes between draft-mengwong-spf-01
and draft-schlitt-spf-classic-00. Some implementations of SPF (such
as mine, released in Feb 2003) have always implemented these
restrictions. If it wasn't for the DoS potential, I would have kept
the "ten include/redirect" limit of draft-mengwong-spf-01. : 6.2 Zone Cut Issues
This has been removed, even though it is in draft-mengwong-spf-01. It
just wasn't implemented often enough. : As stated in Section 2.1, many implementations of SPF adhere to
: original SPF (Section 2.1.1) even though that current branch of SPF
: is described by SPF Classic (Section 2.1.2). Unfortunately, both use
: the same "v=spf1" record identifier, so there exists no easy method
: to differentiante the two programmatically.
: Both versions differ substantially in their error case for the
: "include" mechanism. Under original SPF (Section 2.1.1), if an
: "include" mechanism references a non-existent SPF record, SPF
: processing against all email for the domain making the reference
: would cease (essentially resulting in a state equivalent to having no
: SPF record for the domain making the reference).
In draft-mengwong-spf-00, it was allowed for either a "none" result or
a "error" result in the case of an NXDOMAIN. In draft-mengwong-spf-01,
this was changed to only allow the "error" result. Actual
implementations vary quite a bit. : Under SPF Classic (Section 2.1.2), if an "include" mechansim
: references a non-existent SPF record, SPF processing against all
: email for the domain making the reference would result in a PermError
: state and consequent permanent SMTP rejection of the email.
Ah, this is actually something that I could see changing in the
Unfortunately, draft-schlitt-spf-classic-* can not be consistent with
all well known implementations of SPF and all drafts of the SPF spec.
I think that this is a reasonable choice to make, but could be
convinced to change it. In particular, I could be convinced to change
it to TempError.
Overall, there is a lot of good advice in this document, but I can't
help noticing that much of it is a duplication of what is already in
the spf-classic I-D. I guess it makes a summary of various SPF
specifications, but not all of them and not most of the actual
implementations. It also compares SPF with SenderID, which I guess is
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://firstname.lastname@example.org