Subject: Re: The problem with Unified SPF

From: Roy Badami <[email-masked]>
Date: Thu, 1 Jul 2004 20:40:59 +0100

>>>>> "wayne" == wayne  <[email-masked]> 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.

      -roy

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Jul 2004 15:38:41 -0700

> 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

---

From: Roy Badami <[email-masked]>
Date: Fri, 2 Jul 2004 00:16:23 +0100

>>>>> "Douglas" == Douglas Otis <[email-masked]> writes:

    Douglas> There is no advantage defining duplicate records
    Douglas> types using TXT records composed with ad hoc syntax that
    Douglas> seem to be solutions searching for a problem.  To do so,
    Douglas> in this case, would suggest all DNS record types should
    Douglas> be defined using a TXT record.

I would disagree that SPF is a solution waiting for a problem; I think
many people here regard SPF (and its derivatives) as a solution to a
problem their very interested in (albeit a slightly different one to
the one that CSV/CSA solves).

I was simply suggesting that if this WG chooses to advance a proposal
based on both the marid-core and marid-csv drafts, there is an
argument for using a consistent record syntax for both aspects. But
that if we go down that route we should still (IMHO) keep the records
separate, contrary to what the Unified SPF folks are proposing.

Of course, using SPF syntax for CSA records loses us the additional
data processing in the DNS server, so there's still an argument for
staying with SRV for CSV and TXT for Sender ID.

	-roy

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Jul 2004 16:55:09 -0700

At 12:16 AM +0100 7/2/04, Roy Badami wrote:
>argument for using a consistent record syntax for both aspects.

There is an important design question here--the tradeoff between the
advantage of  reusing a single parser and the disadvantage of
lockstep development in what may be two very different axes of
extension.   The choices need not be quite so binary, of course;
they range from "Use ASN.1 for 1 and XML for 2" to "Every feature
needed by is shared in a common parser and a protocol MUST".
If the working group does decide it would be an advantage to
have consistent record syntax, I think there needs to be an
explicit statement of what level of consistency is at issue.

As an aside, in an earlier message, Meng suggested using the same syntax in
several contexts (HELO, PRA, and PTR, if I recall correctly), but with
different semantics in each context.  Speaking personally, this does
not strike me as optimal design, as it could easily result in confusion
for both those developing the code and deploying the records.  I think
that form of reuse would need very careful thought indeed.

Again, speaking personally,
			regards,
				Ted Hardie

---

From: wayne <[email-masked]>
Date: Thu, 01 Jul 2004 20:13:12 -0500

> that form of reuse would need very careful thought indeed.

I guess I'm somewhat amused by the concerns of using SPF-classic to
cover the HELO domain and thus be an alternative to CSV.  SPF-classic
has *always* covered the HELO domain.  There *is* no change in
semantics of the SPF records for the HELO domain or the 2821.FROM.

SPF-classic is not some vague, new concept, it was one of the input
documents to this working group.

The change in semantics of the SPF record in this working group
occurred when people decided that SPF records could/should cover the
2822.From:/Sender:/etc. headers in the Sender-ID proposal.  I can't
remember anyone other than Margaret and me expressing any concerns
about this change in semantics.  

What Unified-SPF does is add a scope macro variable to make the
slightly different contexts work better in some cases.  It allows the
use of the SPF records, syntax, and semantics to be *optionally* used
in several identities/scopes.  This is in contrast to SPF-classic that
*only* covers 2821.HELO/2821.FROM, and Sender-ID that *only* covers
2822.From:/Sender:/etc.  Unified-SPF also says you can do either, or
both, or you can even optionally cover the in-addr scope, similar to
MTAmark.

In <[email-masked]> Roy Badami <[email-masked]> writes:

>     wayne> 1) [...] transition from using ?all to using ~all or -all
>     wayne> 2) if the scope macro variable [...]
>

No, both records can be used in all scopes under the Unified-SPF
proposal.  Both records been recommended as part of SPF-classic since
before this working group was started.  

> might not be used for those purposes.

The two records are needed because you generally want to cover the
different domain names (the email domain and the mta domain)
differently.  

> intended for HELO identities.

Uh, in the very message you replied to, I said:

: Actually, there has also been a third suggested way for Unified-SPF to
: fix this.  Use a different version tag, such as:
: 
: domain.com.      TXT "v=spf1 include:this include:that a mx ?all"
: domain.com.      TXT "v=spf1-helo -all"

Now, whether the new tag is v=spf1-helo or v=csv1, or v=<rfc-number>
doesn't make much difference.  I think the macro variable for a scope
is a slightly cleaner solution than a different magic number.

If all you want to do is to cover the HELO domain, then CSV is a
cleaner solution than SPF-classic.  For people who want to cover one
of the 2821.FROM/2822.From: identities, using the long-standing
SPF-classic semantics to cover the HELO domain is a cleaner solution
than CSV.

I really don't care one way or the other as to whether this working
group advances CSV to being an RFC.  I do care about all the FUD being
spread, much of it apparently caused by people not reading or
understanding the proposals.

-wayne

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Jul 2004 14:23:13 +0100

> SPF plate is overflowing.)

Should the syntax for SPF be DDDS?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
<TABLE WIDTH="602" BORDER="0" CELLSPACING="1" CELLPADDING="5" ALIGN="LEFT">.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 2 Jul 2004 14:55:19 +0800

Meng,

MWW>   HELO domain.com
MWW>   MAIL FROM:<[email-masked]>
MWW> In this situation, an SPF record could easily become
MWW> unnecessarily complex for HELO purposes.
MWW>   domain.com. TXT "v=spf1 include:this include:that a mx ?all"
MWW> If the domain admin changes the HELO string to be:
MWW>   HELO mta1.domain.com
MWW>   MAIL FROM:<[email-masked]>

Actually, this is a remarkably concise demonstration of the problem
inherent with trying to multiplex two, entirely separate semantics into
the same record.

The way to solve it is not to dictate to users how they administer
their namespace, such as telling them what kinds of names to use in
HELO strings.

Rather, it is to separate the mechanisms that have different
semantics.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>