In <p06110406bd0a5228452d(_at_)[129(_dot_)46(_dot_)227(_dot_)161]> Ted Hardie
<hardie(_at_)qualcomm(_dot_)com> writes:
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.
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
<16612(_dot_)26827(_dot_)511433(_dot_)89759(_at_)giles(_dot_)gnomon(_dot_)org(_dot_)uk>
Roy Badami <roy(_at_)gnomon(_dot_)org(_dot_)uk> writes:
"wayne" == wayne <wayne(_at_)midwestcs(_dot_)com> writes:
wayne> 1) [...] transition from using ?all to using ~all or -all
wayne> 2) if the scope macro variable [...]
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.
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.
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.
The two records are needed because you generally want to cover the
different domain names (the email domain and the mta domain)
differently.
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.
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