ietf-clear
[Top] [All Lists]

[ietf-clear] Re: Make CSV backwards compatible with legacy SPF records?

2004-11-18 10:00:03
On Thu, 2004-11-18 at 08:27, Carl Hutzler wrote:
On 11/18/04 10:44 AM, "wayne" <wayne(_at_)midwestcs(_dot_)com> wrote:

Now, the folks involved with CSV (Dave C, John L, Doug O, etc.) claim
that checking the HELO domain against SPF records isn't as good as
doing CSV checks.  Despite having listened to them explain this, and
read their specs several times, for the life of me, I can't see why
SPF checks against the HELO domain isn't just as good.

Can you explain the difference to me?

Is this difference significant enough to justify having all your
whitelisted domains implement two very similar systems?

I believe they are thinking that an email address domain (right side of the
@ sign) is a different animal than a HELO domain. I tend to agree but also
am hoping that in some cases it may be the same thing for most MTAs.

Providing an identifier for a machine is a different function than an
identifier for a mailbox-domain.  Even mapping these identifiers from
the machine to the mailbox-domain is a challenge.  AOL adds two
sub-domains to the root domain, as example.  Finding the zone-cut
becomes a factor when even attempting to trace accountable entities. 
One can not rely upon a wild-card SPF record, as these are intended to
provide a denial that the label is valid for a mailbox-domain. : (

As a method to authenticate a name, SPF offers macros where a lack of IP
address authentication may still provide a positive response.  This
weakens desired protections from zombie systems, as example.  The number
of DNS queries needed to do this real-time is also a serious concern. 
If SPF is to provide for white-listing, the exists macro must be removed
from the script.  : (

The use of the HELO-domain in classic SPF was a 'Hail Mary' attempt to
find a record.  These identifiers (HELO-domain / mailbox-domain) 
_require_ different records with different labels.  As the goals are
much narrower in scope for CSV, the appropriate record should also
enforce this narrower scope, as is the case with the CSA record.  The
potential within SPF for claiming a large address space greatly reduces
a utility in locating problems.

Although SIDF ignores the intent of the record, what is implied is
important.  Publishing a Client SMTP Authorization record indicates
acceptance for accountability of the operation of the SMTP client.  This
affirmation is important.  A SPF record however indicates that the owner
authorizes some undefined entity, but as the reference identifier has
not been authenticated, it should not be used to establish a
reputation.  The mapping of these identifiers then falls into question,
should the mailbox-domain act to locate the record.  The opposite is
true for CSV, as there is never a question who is accountable.  In order
to establish a base for digital-signature methods, establishing a
name-reputation is vital, making CSV vital.  Knowing who is accountable
without question is also vital.

CSV also protects the network, whereas SIDF and digital-signatures do
not.  CSV will be needed long into the future.


-Doug