You are here: Home > Participate > Join a Discussion > Mailman Archives

Re: [anti-spam-wg] Client SMTP Validation

  • To: "pna.lists" <
  • From: Dave Crocker <
  • Date: Mon, 31 Oct 2005 07:21:51 -0800
  • Cc: RIPE anti-spam WG <
  • Organization: Brandenburg InternetWorking
  • Reply-to:

pna.lists wrote:
It is just another SPF epigon, isn't it?

SPF uses the RFC2821.mailfrom domain name, CSV uses RFC2821.helo. The first is tied to the author. The second is tied to the operator of the client's net. These often are completely different identities and, therefore, entail completely different attempts at accountability.

(SPF has a variety of extensions that attempt to incorporate other pieces of work that have been done, but these extensions are not SPF's core and, as nearly as I can tell, do not have much meaningful traction.)

SPF requires application of the origin identity at every hop along the path. This requires pre-registration of every path for every recipient. Minor effects from this include breaking all forms of re-posting. CSV is a single-hop mechanism, only between the current client and the current server. It has no impact on re-posting.

SPF has an impressively powerful (and therefore complication) configuration language that it codes into a DNS record. It is very difficult to configure correctly. CSV has a simple DNS record.

SPF seems to lead to 50-100 DNS queries. CSV requires 1-2.

So, SPF and CSV differ in philosphy, structure, administration, operation and performance.

But whether you use CLEAR/CSV, SPF or Sender ID, you need another component of
I'm guessing at the rest of the sentence as referring to the need for an assessment component -- white- or black-list of some sort -- and yes they do.

All of the current work is on authentication. Different identities are authenticated and they are applied differently, but when you are done with any of these mechanisms, you have an identity that you believe.

Whether you "trust" that identity does require more mechanism.