In <E1BNWzR-0005ry-35(_at_)argon(_dot_)connect(_dot_)org(_dot_)uk> "Jon Kyme"
<jrk(_at_)merseymail(_dot_)com> writes:
The SPF community has prepared a strategy for getting adoption by the
masses, but is holding off on executing that strategy in deference to
the IETF.
On the face of it, this appears to be the most egregious megalomania. If
not a threat.
Various IETF people (ADs, co-chairs, etc.) have several times said
that they think people should continue to work on their systems while
discussions here go on.
Delaying is not a threat, it is a courtesy.
It seems that some SPF proponents believe that the primary use for this
group is to get endorsement for SPF. This may be a consequence of poor
perceived prospects for substantive levels of deployment otherwise.
With many major ISPs publishing records and very rapid increase in the
amount of email being check with SPF, I think the prospects for
substantive levels of deployment of SPF is very good. I think the
prospects are good, with our without an standard-track RFC, although
obviously, a standard-track RFC would certainly help a great deal.
If this working group only publishes RFCs along the lines of CSV or
MTAmark, then there is no real conflict between what we accomplish
here and what SPF is doing. Both can coexist very nicely.
If this working group publishes something similar to SPF, but
incompatible with the install base, then I think there will be a
problem. There are a limited number of people out there that are
willing to be early adopters, and the number that are willing to try
several similar, but incompatible systems is even more limited. SPF
has been using up those early-adopters since last fall. SPF has
several orders of magnitude more adopters than all other designated
sender systems combined.
As a result, I think it would be better for us to either not touch the
problem domain addressed by SPF, or to create a standard that is
(largely) compatible with the SPF install base.
Identifying, and getting support from, the key players seems to me to be a
good plan.
Agreed, and work has been going on in this area for many months.
Prospects look good for SPF.
Can IETF help you do this?
Yes, certainly.
Does the rich feature set of SPF
help? (Or would they be happier with something more "lightweight"?)
Yes, I think the rich feature set of SPF helps a great deal.
Almost all SPF implementations support almost all of the SPF
functionality and almost all of the functionality is used in the real
world. The "complexity" with SPF does not seem to be an objection for
key players.
The complaints against SPF appear to be mostly the forwarding problem
and the lack of support in MTAs. Actually problems with greeting-card
type systems that "forge" almost everything in the email have
generated as more complaints than email forwarders, but the latter is
more often expressed as a concern.
-wayne