Rand,
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?
Let me phrase the question this way. My understanding from
listening to the audio of the face to face Marid in early
August, one of the major rationales for a version string
change was implementation.
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.
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.
(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.)
With the premise of enhanced email delivery, along with
protecting against domain spoofing, SPF is gaining
implementation momentum among domain owners.
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.
Why? It seems the theory behind the justification for the
change does not reflect reality. Thoughts? Comments?
John
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?
Please excuse my naiveté if I have asked a dumb question.
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Rand
Wacker
Sent: August 25, 2004 11:44 PM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I
believe)
With regards to the Sender ID record being published as a
TXT record for the FQDN hostname (in a TXT record for
domain.com), real world usage is already showing that this
dataspace is becoming populated with spfv1 records deployed
by many sites in order to increase deliverability to
certain very large ISPs and others. By publishing
spfv2/pra records in the same dataspace (domain.com), we
are effectively halving the usable UDP packet size for
responses, since a TXT query for domain.com will try to
return *all* TXT records for domain.com in one record.
Real world deployment experience is that most network
firewall operators do not allow DNS queries over TCP except
to trusted secondaries. The indicated wishes of large ISPs
is that they do not want to have to fall back to a TCP
connection anyways for verifying incoming mail because it
will cause too much overhead.
My concern was mollified by people pointing out that "even
AOL's SPF record can fit in 160 bytes, so they can almost
squeeze three parallel records in to the same TXT UDP
response packet." In the past couple of weeks I have
talked to a few *major* .com sites (financial, media,
consumer) whose real-world outbound architecture is
waaaaaaaay more complex than AOLs. In particular, with the
number of global sites they run, the number of third party
delivery services they contract with, and their general
focus being on running their business instead of their
email, many of these large companies are going to have
trouble fitting a single SPF-like record in a UDP-sized
query, let alone fitting it in half that size.
My concern for Sender ID is that since SPF has already
claimed the FQDN TXT dataspace for itself (and since SPF is
seeing parallel adoption regardless of where Sender ID
goes), trying to stuff a second Sender ID record in the
same data space will be problematic for some, and if we
ever try to evolve this to a third version then it will
*never* fit.
The solution I would suggest is to put spfv2/pra records in
a sub-domain such as _marid.company.com. While it would be
nice to recommend that people begin allowing TCP DNS
queries, it is unlikely that the highest volume sites would
ever want to implement such.
This is a concern that has been voiced to me by several
major sites that are exactly the same set of sites we use
as examples for where we need to stop phishing from. They
are most likely going to publish *both* spfv1 and spfv2/pra
records, and their initial investigation of their email
architectures has indicated that those records are going to
be pushing this real-world 240-byte limit (a 480 byte
effective UDP packet split in two)
-Rand
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004