----- Original Message -----
From: "Julian Mehnle" <julian(_at_)mehnle(_dot_)net>
Not wanting to fuel the eternal "SPF vs. foo" debates, but...
Who is using CSV?
Does it represent atleast 1% of the transactions for any one system? If
not 1%, maybe 0.01%?
Everyone has to start somewhere, even SPF had to.
Right, and early on most people didn't support SPF until there sufficient
growth in this direction, especially with the announced support of industry
leaders, like AOL and MICROSOFT. We didn't bother with SPF until AOL added
CSV has not experienced such industry wide interest whatsoever.. So all
this talk as it is has any insignificant in the market. It doesn't . It
doesn't even compare to SPF as far as adoption.
1) Information week has a article on Email Authentication Methods - SPF,
SENDERID and DKIM. No need to talk about CSV. SPF was described as the
clear top dog and according to Forrester Research, it has grabbed 30% of
2) BankofAmerica.com is investing big-time in finalizing SPF operations with
augmented technology. See their PDF presented at last months DKIM Marketing
Summit at Cisco.
In short, the only people talking about CSV is the authors themselves. Dave
or Doug isn't promoting SPF, so the SPF people shouldn't promote CSV. No
one else is.
What reputations services are available for it? Are this paid services?
Reputation isn't conceptually attached to the _method_ of authentication,
but to the _identity_ that is being authenticated. If both SPF and CSV
authenticate the HELO identity, then in both cases the same reputation
database can be used.
That is true, and I remain to this day as I told Dave/Doug/John that
attaching Reputation, and in their case, it was Accredidation (Are you good
actor? as oppose are you a Bad Actor?) that it will have a dearth of
adoption problems on a wide scale. It is a "Batteries Required" concept
and I have too many nightmares with the early Merchant Account business when
there were only a few around. Pushing our customers to these "Battery
Required" vendors caused major PR support problems for us. Keep in mind
these three guys (especially Doug and John) have a strategic interest in
promoting a new A/R business models using a fee based Centralized Repository
concept. This is one major reason why it hasn't caught on and suffice it
to say, DKIM risk the same adoption problem because of the same impetus
A/R ideas is a "Service" concept. It is not a transparent infrastructure
Even if it was to became a standard, why should I believe who YOU tell me if
your Voucher? And how do I guarantee that a CLIENT is a member of my
Chosen Voucher. If this was a complete 100% single entity same shop
across the board service for everyone, then it has a better change of
succeeding. But as you know, no one whats that to happen.
Did CSV fix its "chicken and egg" problem on how it will used within
the double entry EHLO TLS operations?
BTW, how did SPF solve that problem with regard to EHLO checking?
As with all protocols, my recommendation is to use a State Delayed
EHLO ---> Validate at MAIL FROM: (or RCPT TO:) if you reach it.
MAIL FROM ---> Validate at RCPT TO: if you reach it.
On an consistent and average basis, the client domain is syntactically
invalid between 20% to 40% of the time. So the payoff is to wait until
atleast the MAIL FROM state is reached. If the session is TLS or ESMTP
AUTH authenticated, then this can offer one less need to do any client
Similarly, the RCPT TO: is on average 50% invalid (user doesn't exist), so
this reduced the need to do any verification on the client domain or the
return path since the client is not going to get past RCPT TO:
Hector Santos, Santronics Software, Inc.
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
please go to