ietf-mxcomp
[Top] [All Lists]

Re: [spf-help] Re: SPF and SenderID

2005-07-22 10:01:43


On Jul 22, 2005, at 6:18 AM, Kjetil Torgrim Homme wrote:

  CSV does not address the TARGET problem of malicious transactions.
  It has no practical value other than ENFORCE a new level of
  secured transactions and this is only DOABLE within compliant
  systems.


I don't think anyone believes that CSV will be much help in the
struggle against spam, but it will help establish clearer
responsibilities and accountability.  we already reject half a million
delivery attempts daily based on bogus HELO values.  CSV will increase
that hit rate (probably not by much, though), and remove some of the
ad hoc rules in our system.

Reputation systems will move away from reliance upon using the IP address in favor of the domain name when made possible by DKIM, for example. DKIM clearly provides authentication without requiring many infrastructure alterations. One thing not protected is the network resources. A reputation service can and often does offer a significant level of resource protection however. With either DKIM or Sender-ID there can be no resource protect that results from the application of reputation following the acceptance of the message.

One key, fair, and safe requirement for any reputation system would be the accrual of behavior be based upon authenticated identities. Here is where CSV becomes vital. CSV allows the extension of name based reputation into also protecting the network resources. I know that SPF claims to be able to "authenticate" the HELO, but with SPF Classic, it is all (which includes a list of problems) or nothing. The high required minimum number of lookups for the SPF records absolutely prevents this record from playing a resource protective role. CSV not only does NOT need wildcards to express a domain-wide policy, but expects this function can be done using a single lookup prior to any further exchanges, including the message.

When there is a failure to find the CSV based off the HELO, then, as an option, there is a means to quickly discover whether the domain offers a CSV policy. A domain name provides a fair amount of information. Reputation can assessed based upon this ancillary information to hold the appropriate level accountable. There could be methods that propagate accountability up the name tree, and I would say that bad reputation always would move down the tree.

A school on a single T1 may tax the budget $450/month. Without resource protection, the school may find that that this resource is being consumed by a flood of spam in effect wasting this investment. Here resource protection becomes vital. When perhaps 80% of domain owners share servers, the use of IP addresses tends to paint with too broad of a brush. To move into the use of name reputation to be more selective about who the bad actors are, then CSV offers that possibility. A CSV lookup failure will force the fail-over to the use of IP address to assess reputation. It could be to your customers advantage to not be tied to the IP address reputation. CSV becomes a way to offer an alternative reputation specific for the client. Even when the HELO is held static, this still permits an authenticated name as a basis for reputation accrual.

CSV will hold the domain granted access or the administrator granting access accountable. SPF however holds whoever authorized the server accountable. Those that authorize the server are likely not responsible for who has access or who uses their domain. Yes, it is possible the server may force this restriction. There are also domain owners that will not trust such restrictions, and will want their own IP address that is never shared with other domains. I want to see what email service provider will indemnify there customers from others using their domain on the server.

-Doug


<Prev in Thread] Current Thread [Next in Thread>