Sorry, I pushed the "submit" button before filling in the references.
This is a resend, with that fixed.
-- jimbo
As requested by the cochairs, here are two more examples of scenarios
for which the SPF syntax is insufficient.
My initial scenario (feedback tied to individual mechanisms,
http://www.imc.org/ietf-mxcomp/mail-archive/msg02021.html) kicked off
the thread.
The second scenario deals with reputation tied to individual mechanisms.
The third scenario deals with message types tied to individual
mechanisms.
Reputations Tied to Individual Mechanisms
----------- ---- -- ---------- ----------
(This is mostly a repeat of
http://www.imc.org/ietf-mxcomp/mail-archive/msg02090.html)
Suppose I have a small domain with no reputation. Suppose I'm a
customer of both MSN and Comcast, and I send some of my outbound mail
through MSN's mail servers, and some through Comcast's mail servers. As
things currently stand, I'd publish a MARID record like:
v=spf1 +indirect:msn.com +indirect:comcast.com -all
This authenticates me very well (assuming that MSN and Comcast each do a
sufficient job of policing their internal networks to keep other
customers from masquerading as me).
When we get into the question of reputation, the argument goes something
like: If you get mail from me through MSN's mail servers, you should
believe it's not spam because MSN does a good job of keeping its
customers from sending spam. Similarly, if you get mail from me through
Comcasts's mail servers. The degree to which you as a receiver believe
my mail is not spam is exactly a function of one of my ISP's
reputations.
Using invented syntax, I could say something like:
v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep
-all
which gets the point across nicely.
Contrast this with the case of hotmail's record. Hotmail has more
address ranges for outgoing servers than fits into a single DNS record,
even using SPF syntax. So they publish something like:
v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com
+indirect:c.hotmail.com -all
In this case, the indirections are a mere implementation detail, and
receivers shouldn't attempt to read anything into the fact that they
received a message from the "b" list of servers instead of the "a" list.
As a separate example, consider a domain that sends a lot of spam,
through its own servers. It also sends non-spam, indirected through
Comcast. It may well publish a MARID record like:
v=spf1 +mx +indirect:comcast.com/targetrep -all
So, if you get mail directly from this domain's servers, the domain's
lousy reputation applies. If you get mail from Comcast's servers,
Comcast's reputation applies. (This example sidesteps the question of
whether some vigilantes might want to reject a domain's identifiably
legitimate mail because it also sends spam -- a question I don't want to
go into right now).
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
Summary
-------
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 -- other proposed
extensions that say something about the domain as a whole are much
easier to represent using SPF modifiers (unless the somethings have
internal structure, in which case it gets hard again).
When you put it all together, we need a way to say something new about
an individual mechanism. Furthermore, we need the ability to say more
than one something new about the same mechanism
(+indirect:comcast.com/targetrep,nonbulk). Furthermore, some of the
somethings have some internal structure (?all/feedback=xxx,hdrs,p=.001).
[Note that I'm not proposing syntax here -- the commas in this last
example mean something different than the commas in the previous
example.]
XML gives you all of the above. We don't have any other proposals on
the table that give you any of the above.
-- jimbo