"Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
Reputations Tied to Individual Mechanisms
----------- ---- -- ---------- ----------
Suppose I have a small domain with no reputation. [snip]
Using invented syntax, I could say something like:
v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep
which gets the point across nicely.
v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com
In this case, the indirections are a mere implementation detail, [snip]
I like this concept of using the mechanism that caused the IP address
to be validated as a way of determining the reputation. This is not
unlike the checking of URLs within email to determine of they point to
However, I see this as a case of being "not useful because no one will
believe unverifiable claims."
If you are going to do this kind of reputation checking, you should do
it whether there is a "/targetrep" flag or not. A spammer who
publishes "v=spf1 include:optinrealbig.com -all" will almost certainly
not say to check the target's reputation, but a receiver may find that
very useful to check. If the various hotmail include: mechanisms
aren't good indicators of reputation, the checking will make no
difference. However, there is a chance that, due to the CIDR blocks
dedicated to dialups or different countries, the various hotmail
include:'s will make a difference.
The anti-spam systems that judge the urls within an email don't look
for some special tag and for good reason. The same goes for SPF
Message Types Tied to Individual Mechanisms
------- ----- ---- -- ---------- ----------
Many domains send both non-bulk and bulk mail, generally through very
different parts of their organization. It may be useful to have
annotations on an SPF mechanism that describe the kinds of mail they
send. For example:
v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all
Again, I see this as a case of being "not useful because no one will
believe unverifiable claims."
The common theme among these hard-to-represent-in-SPF extensions is that
the extension says something about an individual mechanism, instead of
saying something about the domain as a whole
This is true. The current SPF spec says that modifiers are position
independent and therefore you can't use them to mark up individual
I think we could change the SPF spec to allow modifiers to be
(optionally) position dependant and not cause problems for the
installed base of SPF records. That is, we could say that things like
"redirect=" and "exp=" are position independent, but allow for new
modifiers, such as "targetrep=" and "mailvolume=" to be position
dependant. So, it would be possible to say "v=spf1 mx mailvolume=bulk..."
and have the mx: mechanism marked up.
I have checked the SPF records that are listed in the Adoption Roll
and my survey of the 1.3 million email domain names. I could find
none that wouldn't work just fine with this change in the SPF spec.
I'm not sure I really think it is a good idea to make this change, but
I think it is a valid option.