ietf-mxcomp
[Top] [All Lists]

Re: The problem with Unified SPF

2004-07-01 15:38:48

On Thu, 2004-07-01 at 12:40, Roy Badami wrote:
"wayne" == wayne  <wayne(_at_)midwestcs(_dot_)com> writes:

    wayne> 1) domain.com can transition from using ?all to using ~all
    wayne> or -all

    wayne> 2) if the scope macro variable is allowed (it was suggested
    wayne> as part of the Unified-SPF), then you would need to have
    wayne> something like this:

But the problem is artificial in origin.  In the example that Meng
cites (which he suggests would be the norm) one of the records is only
intended for authenticating email address identities (MAIL FROM and
PRA) and the other is only intended for authenticating HELO strings.

If these records were identifiably different in some way, there'd be
no risk of using the record intended only for email addresses to
attempt to authenticate a HELO string (or vice versa).

I don't see the benefit in writing two records for different purposes,
then having to construct workarounds for the fact that the records
might not be used for those purposes.

Why not just have the records begin with different prefixes? eg v=spf1
if it's intended for PRA/MAIL FROM identities, and v=csv1 if it's
intended for HELO identities.

Or, to put it another way: leave SPF/Sender ID to authenticate
mailboxes, and CSV/CSA to authenticate HELO identities.  If you want
to unify the syntaxes, then that might not be a bad idea.  So use SPF
_syntax_ for CSA records, but change the prefix to v=csv1 so as to
avoid any ambiguity.

Meng's example of

mta1.domain.com. TXT "v=spf1 a -all" 
domain.com.      TXT "v=spf1 include:this include:that a mx ?all"

then becomes:

mta1.domain.com. TXT "v=csv1 a -all" 
domain.com.      TXT "v=spf1 include:this include:that a mx ?all"

which is hardly any more complex, and avoids the need for any workarounds.

SPF is of a complex matrix of linked DNS records to list an array of
acceptable message mailbox domains. This matrix and array imposes high
levels of complexity outstripping current DNS capabilities and thus
requiring the proposal of a new linked set of records. SPF is currently
being proposed to use the DNS TXT record with yet unknown syntax. (The
SPF plate is overflowing.)

CSV authorizes and authenticates acceptance of a single host name. This
closely matches current DNS capabilities and does not require a new
record type to do so. CSV is currently proposed using the SRV record
with fully defined syntax. (Next to no syntax actually. Why make a meal
out of a mouthful?)

Living in its small packet, DNS normally provides specific and concise
answers already understood by the libraries in hundreds of programming
languages.  There is no compelling reason to reject the use of suitable
record types. There is no advantage defining duplicate records types
using TXT records composed with ad hoc syntax that seem to be solutions
searching for a problem.  To do so, in this case, would suggest all DNS
record types should be defined using a TXT record. Such a departure
introduces thousands of lines of new code to replace the use of a few
(while forgoing useful automation).

-Doug