From: John Levine [mailto:johnl(_at_)iecc(_dot_)com]
If on the other hand a VeriSign mailer is saying HELO
mail.cybercash.com or whatever it is unlikely to cause problems.
Unless the mailer's name is really mail17.cybercash.com.
In which case the sender gets no benefit from the verisign.com record and no
Tony collected some stats and a remarkably large number of
legitimate mail clients HELO as a name that is in an
appropriate domain but the A record for that name doesn't
point back to the mail host. We designed CSV so it's easiest
to set up if the A records are right, but it's only slightly
harder if they're not, and it can still tell the difference
betwenn a Hotmail host HELO'ing as hotmail.com and some
random zombie doing so.
If you really think this is necessary then the reasonable way to go
about deployment is to propose an approriate SPF context flag.
The semantics of CSV are unrelated to those of SPF. There's
no advantage to combining them in one bloated record.
There is if you want to see the scheme deployed and used. Attempting to
fragment mindshare at this point is not something that you will find people
well disposed to, particularly given the behavior of some of the CSV
advocates in MARID.
The semantics of the policy records have always been that the sender is
identifying the outgoing email edge servers. The receiver will interpret
that information any way they choose.
SPF has generated a very significant degree of open source and industry
support. If after rejecting that proposal the IETF endorses a rival proposal
that has no support from any quarter the reaction would be savage.
The feedback I got from the FTC workshop was that a lot of people were very
annoyed that the technical side had not got its act together behind one
proposal. The lack of apparent concern about email security has a lot of
people very disappointed.