John, thanks for the reply. One thing I want to start by saying (and then
I'm going to leave the discussion for after last call), its becoming clear
that the most fundamental disagreement on this list has to do with the
approach of doing *channel* authentication versus *message*
authentication. I say this because you tend to hold SPF Classic and
Sender ID as equivalent in your response, which I do not.
From your discussions with managers of large email
infrastructures, who are seeing a problem with packet size;
along with the big ISPs who are not interested in using TCP
to receive email because of cost, does it make more sense
not to change the version string?
No. Both I and the people looking to implement these records feel quite
strongly that using the same record for both is very dangerous. In fact,
these largest sites are the ones who are *most* likely to have different
records (bit of a Catch 22 there).
It was felt folks who implemented SPF were early adopters.
By changing the version string, this would freeze SPF and
folks would move ahead with Sender-ID.
What you are telling us is the direct opposite.
The truth is that there are some very large sites which have already begun
asking senders to publish SPF records. There are other large sites that
will be asking senders to publish Sender ID records. (I can think of a
third large site that will ask for DomainKeys later ;) The goal of all of
these senders is to get their mail through, they don't care so much how
they have to do that.
Some of the Big ISPs are using SPF to detect email forgery
at the pre data stage, while telling folks, do you want
less content filtering? Publish an SPF record.
^email forgery^channel forgery. Also for most receivers I've talked to,
"pre data" doesn't matter since for the worst spam the packets are already
wedged in to their TCP receive buffers.
(Of course this achieves the desired objective of sender
authentication, thwarting spoofing and other steps taken to
hide identity, by getting everyone out in the open.)
No offense John, but this is a sub-concious troll to bring the debate back
to SPF Classic vs Sender ID. ;)
With the premise of enhanced email delivery, along with
protecting against domain spoofing, SPF is gaining
implementation momentum among domain owners.
Enhanced email delivery, yes, but no-one I've talked to is under the
delusion that SPF Classic protects against domain spoofing in the "what
the user sees" context
This leads one to the conclusion the solution is instead of
creating a sub domain for Sender-ID records, rather it is
not to change the version string.
Incorrect conclusion.
P.S. Another question. Since the Big ISPs do not want to
use TCP to check authentication for email delivery, does
this mean from a practical perspective, the Big ISPs would
prefer to create a mirror data base of authentication
records within their own networks and when a domain owner
makes a change, the domain owner's DNS server could
propagate the change through out the mirrored sites?
This is functionality already inherent in DNS, which is one of the things
that makes it appealing for a task like this.
Cheers - Rand