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

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