Re: draft-schlitt-spf-classic-01.txt

On Wed, 2005-06-01 at 00:36 -0400, Hector Santos wrote:

> > While possible, with add restrictions imposed by the email provider,
> > the domain owner remains completely at the mercy of an email
> > provider's diligence at _every_ MTA involved in the transport of the
> > message, and not just those MTAs that have been directly authorized
> > by the SPF record.  A mistake on the part of an email provider, such
> > as misconfiguration of a firewall, and the domain owner's reputation
> > suffers.
> 
> And how is CSV immune from these same set of possible routing scenarios?

The HELO name would be indicative of the domain administrator running
the MTA, irrespective of the mailbox-domains contained in messages sent
by the MTA.  If the MTA is not properly administered, it would be this
MTA and the administrator of this MTA identified by a reputation scheme
that rates HELO names.

Those that would normally send messages over a HELO blocked MTA would be
free to look elsewhere to obtain email services.  If the mailbox-domains
were rated and blocked instead, as with SPF, a poorly maintained MTA
could continue to send abusive and even forged emails, but then the
domain owners would find use of their domains blocked, no matter which
other provider they tried.  Not fair for the domain owner, nor effective
at preventing abuse. : (


> Are you saying that once CSV authorizes a submission at the MSA, then there
> is no need to further perform CSV during the route and only at the MDA?

CSV would be checked once for every HELO presented.  The basis of any
reputation should be with respect to the administrator.  Only the
administrator is in a position to take immediate and knowledgeable
corrective action.  Normally an administrator's reputation evaluation
would only need to be done once for any number of messages.  Unlike SPF,
which may entail many many lookups, CSV requires just one for its basic
use, and done just once per MTA for a substantial reduction in overhead.
This low overhead makes CSV suitable for protecting network resources.


> What if you have this topology?
> 
>         MUA ---> MSA1/MTA1 -----> MTA2 ---->  MDA3
>
> MSA1 and MDA3 is CVS ready.  MTA2 is not.
> 
> How does MDA3 handle this using CSV?  What is the policy here?

CSV offers a means to protect network resources on a name basis.  CSV
would permit name reputation accrual for the MTA, rather than just for
its address as done today.  Thus updating addresses would not impact the
MTA administrator to the same extent as it does today.  As CSV uses the
SRV record, there would be no address maintenance involved in an address
change either.  (Beyond the normal A record reassignment of the
interface of course.)  

By elevating the network reputation protection service to the name
space, rather than just address space, CSV offers a means to extend DoS
protections for other uses, such as email signatures as described in:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt

CSV also provides a means to establish domain-wide assertions without
the use of wildcards as well.  Of course this would be greatly
facilitated by a convention that expects the HELO to resolve to a CSV
record.

If MDA2 claimed to be from a domain that had a domain-wide policy that
required a CSV record (per the SRV Port assertions), then a lack of such
a record would become a basis for MTA3 to refuse messages from MTA2.

There could also be a simple fallback that depends upon an address space
reputation service, instead of name space.  Regardless of the use of
addresses or HELOs, there is no expectations that new conventions are
adhered to by each MTA.  The HELO name would be authenticated directly,
and would be acting under the auspices of the MTA administrator.

On top of this network HELO name reputation protection scheme, a
signature domain name reputation protection scheme could be constructed.
In either case, HELO or signature domain, the name reputation would
reflect the diligence of the administrator guarding access at each MTA.
Of course, in the case of the signature, this provides valuable end-user
protections, and not network resource protections.

Signature schemes would also assist MTA administrators identify
problematic accounts without unfair assumptions.  CSV and Signatures are
fair and safe alternative to path registration.

-Doug