Re: So here it is one year later...

On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote:
> Please Doug.
> 
> You can't guarantee that an immediate router will be CSV compliant.  So you
> have the same heterogeneous/mixed policy issues as SPF and all the rest of
> the proposals.

If the sending SMTP client publishes a CSV-CSA record, then this client
is both authenticated and authorized by the HELO domain.  This permits
assessment of reputation which may supersede evaluation of the IP
address.  It also permits direct and meaningful feedback to the
accountable administrator, as a means to rapidly respond to abuse.

Authorizations offered by SPF path registration is insufficient for
reputation assessments, as there is no assurance which administrator is
directly accountable for abusive messages.  SPF does not authenticate
the sending domain, it only confirms authorization.  Where many domains
have authorized an MTA with SPF, resolving abuse may become an expensive
process.

CSV allows such assessments to be made safely on an opportunistic basis
while not requiring heterogeneous adoption.  CSV is also incorporating a
means to assert domain wide use of CSV as a means to discourage HELO
spoofing.  Unlike SPF, CSV does not disrupt the normal use of mail nor
depend upon any tests or changes in MTA behavior.

> In addition,  you have a MUCH higher overhead than most as you based on
> state point #1 - HELO/EHLO.

Authenticating the HELO is done within a single lookup with CSV.  How
can this be a higher overhead?

SPF provides authorization for the MTA referenced by a sending mailbox
domain (without consensus as to which mailbox domain).  While SPF could
also be extended to examine the HELO domain, those that have previously
published SPF records may not have ensured HELO domains resolve to an
SPF record.  SPF evaluation of HELO was previously applied during the
sending of bounce messages, where the outcome would have been "unknown"
rather than "fail" without specific records in place.  It is also likely
that SPF HELO records may require resolving the same large address space
as that needed for mailbox domains and is a DoS concern. : (

Changing SPF to apply a record at the zone cut against the HELO, in
addition to further increasing overhead, may now put some domains in
jeopardy due to a lack of proper record revisioning.  Using the same
check_host routine and records, as used to examine mailbox domains, may
also permit unexpected exploits.  Although the number of SPF records
could be few on average, the need to register potentially complex paths
always requires an excessive limit for the number of lookups.    

> Now why would I want to do a HELO CSV check without determining:
> 
>     - Check to see if the sender is valid,
>     - Final vs Route

MASS is addressing the need to safely authenticate the administrator of
originating sender domain.  CSV addresses the need to protect the
network from abuse, and therefore only considers authenticating the
administrator of the immediate sending domain.  CSV does not require
customers of various mail providers to have their various provider's
domains entered into their DNS records.

CSV will not inappropriately assess the customers of various providers
for a lapse in access control of some provider's server.  The
administrators of the servers are accountable for security, not
customers.    

> You will say;
> 
>     "Our new MAPS CSV/DNA service will take of this.  We will vouch
>      for the transaction."

Accurately authenticating the accountable domain's administrator (who is
permitting mail access), allows assessing reputation.  There is value
from this information alone, as it also means the sending MTA has been
specifically authorized to send mail.  This helps with detection of
zombies without the use of a vouching service.  Securing the networks
will always require a reputation service, whether IP address based or
extended to using names.  There are advantages using names with respect
to ensuring legitimate domains eliminate abusive accounts with the least
expenditure.

> But what if the SMTP operator does not want to use your new MAPS CSV/DNA
> service?  What if you go out of business?   What if you get enough support
> headaches from thousands of smaller systems that you decide to raise the
> price to filter out these bothersome clientele?

This seems to be putting the cart before the horse.

> Please, again.
> 
> Give me something technically SOUND before even have to bother with the
> baloney that will come about with DNA like concepts.

The CLEAR design team is working diligently at ensuring CSV is sound.
There are models where reputation is provided as a service to the SMTP
servers.  While CSV has made accommodations for a vouching model, it is
unknown which model will prevail.  While bulk mail providers may favor
the vouching approach, a more significant number may rely upon a direct
reputation service model.

I should also note that BATV does not require any outside service to
address abusive bounce messages.  Although SES is similar, it introduces
some security concerns by way of its syntax.

-Doug