I collected a number of quotes from the MARID list, which temporarily
are here:
http://wiki.fastmail.fm/wiki/index.php/MrElveyScratchSpace#CSV (feel
free to edit)
It shows a helluva lot of support.
Advocacy of CSV on the MARID mailing list:
"We ... see a lot of benefit to the "newer" CSV idea." "This is a VERY
interesting approach." "This sounds really cool." - Carl Hutzler (in
charge of _AntiSpam_?
<http://wiki.fastmail.fm/wiki/index.php/AntiSpam?action=create>
Operations at AOL)
http://www.imc.org/ietf-mxcomp/mail-archive/msg02057.html : CSV is
based on broadly deployed working code. - Doug Otis (who made many
other supporting arguments)
Who also said: The great thing about rehabilitating the EHLO name, is
that this name is provided early in every SMTP session. The EHLO name is
captured within the message headers to allow tracing. There is no need
for submitter or to invent new mail headers to discern where the message
is originating with the use of CSV applying the post-mark so to speak.
http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html : "CSV is
orders of magnitude easier to deploy than SPF." - Matthew Elvey
http://article.gmane.org/gmane.ietf.mxcomp/5180 : Why everyone sending
legit mail will publish CSV records.
"... I support something simple and lightweight, that protects HELO
or MAIL FROM instead of body headers. If the recipient has a domain
that will put its reputation on the line to vouch for a message, it
doesn't need to be the one that appears in the body. We need to
create the smallest possible system that can authenticate one
protocol field in an SMTP transaction. From that, this or another
group can develop stronger mechanisms for combating forgery and
spam, but not until after basic authentication has been deployed." -
Philip Miller
"The original intent ... was to verify the parameters of the SMTP
transaction. _W_e can still do that with ability to check ... EHLO if
CSV is integrated into the main record format. " - Yakov Shafranovich
<Let's abandon MAIL FROM/PRA.> "I also think that in this scenario the
mechanism should be CSV rather than SPF, because CSV is vastly more
efficient and less abusive of the DNS." - Tony Finch (dot @ dot at . at)
"And less abusive of the forwarders." - Rand Wacker (of sendmail),
concurring
With CSV, "the number of domain names to support is some orders of
magnitude smaller than for SPF or Sender-ID." and other *important*
arguments here
<http://www.imc.org/ietf-mxcomp/mail-archive/msg05012.html> - Dave
Crocker, author of the seminal RFC 822, which in large part defined SMTP.
"_Let's_ reexamine previous decisions (such as the one against CSV,
which could be reintegrated with a HELO scope)." - Stephane Bortzmeyer
CSV is a "promising proposal" - William Leibzon
"Lets proceed with SPF Classic and/or Unified SPF." - Terry Fielder
"Sender ID and CSV ... may in fact turn out to be complementary." - Roy
Badami
<SPF isn't more useful.> "When you add SRS in to the equation, SPF
Classic essentially "degrades" in to CSV-like functionality. - Rand
Wacker (Sendmail.com)
http://www.google.com/search?q=gmane+%22do+CSV+and+BATV%22 - John Levine
(agree: David Woodhouse)
"I fully expect ESPs and ISPs to do CSV on their MTAs." "I am
implementing ... CSV" " "I now agree that checking HELO can be very
useful, as it satisfies the ESP->ISP whitelisting requirement nicely,
and also has the benefit of making life easier for forwarders who would
then be able to skip SRS." - Meng Weng Wong (!)
Let's "move forwards now with a unified syntax and storage" supporting
HELO - Matt Sergeant (who writes spam filters for a living) here
<http://www.imc.org/ietf-mxcomp/mail-archive/msg04512.html>
Oh, yes.... First Post! :)