There has been a lot of good discussions on extending SPF recently.
Many of the points raised and much of this discussion has been
repeats of earlier discussions. While this might be getting old for
some people who have been involved with SPF, I think this most recent
discussion has been quite good.
First, for those people who have only recently started following SPF,
we can't expect them to wade through the last year's worth of
archives.
Second, every this subject has come up, the general conclusions have
remained the same. This is important. Even when lots of new, fresh
eyes have looked over the situation, and older minds have had a chance
to reconsider, we are finding that the current SPF spec is quite
reasonable. This gives me confidence that we aren't overlooking
anything critical.
Mark Shewmaker gave what I think is an excellent summary in:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200406/0105.html
In particular, he made the following points:
* SPF is extensible syntactically, but not semantically.
* SPF's not-so-extensible semantics is a necessary *feature*, as
you don't want two SPFv1-compliant receivers to come up
with different results for the same record and emails.
* You can use modifiers to extend things if you need to.
I will add:
* If you want Java in a sandbox, you know where to find it.
* K.I.S.S.: SPF must be "obvious" to casual mail admins, as the vast
majority of them will not want to spend much time learning the small
details.
I've thought about this who subject a lot over the last 9 months or
so. I don't know if anyone else views things the same way, but this
is how I view the subject.
The SPFv1 mechanisms define the "SPFv1 result". It is extremely
important that different receivers don't give conflicting "SPFv1
results", or domain owners will be afraid to publish SPF records. I
think it was Stuart Gathman who first pointed out that "There is
actually no need for any mechanism other than exists. The other
mechanisms exist only as an optimization for common checks which can
be safely performed on the receiving MTA without consulting the sender
domain."
However, SPF is a policy framework. SPF is not a FUSSP. We want to
be able to extend things.
How do we resolve this conflicting goal? Well, by accepting that the
"SPFv1 result" is not the only policy that can be created and it does
not override all other policies.
So, we can use the SPF record to also create, for example, an "S/MIME
policy" using a modifier such as "smime=required". This would mean
that even if the "SPFv1 result" is "pass", the email should be
rejected if the email doesn't use S/MIME because of the "S/MIME
policy".
Or, we could have another "S/MIME policy" that says "smime=accept",
which would mean that even if the "SPFv1 result" failed, that you
should accept the email. In order to completely implement this new
"S/MIME policy", domain owners might be wise to not publish an "SPFv1
policy" that results in a fail so that MTAs that check before the DATA
command won't reject the email. If this policy sounds reasonable to
many people, SPF implementations might want to check for this S/MIME
policy and not reject the email during the SMTP session. The SPF
implementation should just generate a Received-SPF: header that shows
that the "SPFv1 result" was "fail".
Thus, we can use modifiers to create extensions and test them out.
After a while, we can look to see which extensions are most useful and
create a new "SPFv2 policy" that creates new SPF mechanisms to support
these extensions.
SPF mechanisms define the SPF result. SPF modifiers do not change the
SPF result although they can add useful information, such as the exp=
and accred= modifiers. Modifiers can be used to create new,
different, policies and the SPF record is a really good place to add
those policy hooks.
-wayne