On Aug 24, 2004, at 07:11, Meng Weng Wong wrote:
I have a feeling that Sender ID will proceed with an
exclusive focus on the PRA.
If we want to protect the return path, we will have to do
it in the context of a Unified SPF model which embraces and
extends Sender ID.
Several other people have recommended this approach as
having less friction.
One of the early debates surrounding Sender-ID was whether
to have the email policy record published in a separate
sub-domain file. Ultimately this was abandoned. Then of
course we had the decision to change the version string, so
resulting in implementers having to publish two policy
records, one for SPF and the other for Sender-ID.
Rand Wacker of Sendmail has made the following post to the
MARID mailing list:
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)
His post leads to two possible solutions:
The initial design logic behind changing the version string
was flawed. Why? The momentum for publishing SPF records is
gaining speed, because of domain owners' desire to protect
against domain spoofing and the tacit understanding from
certain Big ISPs, publish an SPF record to ensure you meet
our criteria for white listing and enhanced deliverability.
This runs contrary to my understanding of the reasoning
expressed at the Marid face to face in early August for the
version string change, which was to freeze SPF and force
early adapters over to Sender-ID.
Also, Big ISPs and large corporate networks are not
interested in using TCP to check data when authenticating
email.
The result? Don’t change the version string. Allow
implementers to use the same version string to comply with
SPF (to protect against domain spoofing) and Sender-ID (to
protect against domain phishing).
Receivers can if they wish run both checks, SPF at the
pre-data stage to protect against email forgery, along with
Sender-ID at both the pre-data (if the sending MTA has
enabled submitter) and the post data stage through
extracting of headers to protect consumers against domain
phishing.
The alternative approach?
Given the desire of the community at large to protect
against domain spoofing, along with some Big ISPs wanting
to use SPF to protect against email forgery using return
path checks at the pre-data stage, while encouraging
senders to publish SPF records to achieve or maintain white
list status and Sender-ID’s focus being to protect against
domain phishing:
* Let SPF and CSV be the vehicles for stronger email checks
at the pre-data stage.
* Do not push for stronger email forgery checks at the
pre-data stage using Sender-ID.
* Don’t object to the change of version string for
Sender-ID.
* Accept a sub-domain for publishing the txt email policy
record for Sender-ID.
(The problem? Large corporations will not have a problem
with this. This will require a change by some (many ?) web
hosts to allow for sub domains for this purpose.)
The result? Those senders who do their own emailing and
have a legitimate concern about protecting their domains
against phishing can enable submitter, presuming Sender-ID
becomes the weapon of choice for the Big ISPs in checking
for phishing.
Keep in mind, the CSV folks have come up with an
alternative approach.
The rest of the community can simply publish an spf2/pra0
record in the appropriate sub-domain and let the check
occur at transport stage by those which wish to implement
Sender-ID, through extraction of headers, which is what
Sender-ID calls for any way, not bother with submitter and
simply proceed as normal.
Sender-ID will then rise and fall on its own depending on
the level of ‘false positives.’ If these are unacceptable,
user complaints and a desire not to break email any more
than it is broken, will lead to the market swiftly
delivering the answer.
Conclusion:
I am not certain which is better, although my gut favors
the first approach which is why I responded to Randy’s
message, by suggesting in essence, let’s not have a change
of version string, so resolving the problem.
But I am now wondering, as folks recognize the value of SPF
to protect against domain spoofing (the sender perspective)
and email forgery (the receiver perspective), is this
really the best approach?
Instead is it better to simply let Sender-ID fall or rise
on its own as Andrew suggests and if the SPF community
wants to develop a solution focused on phishing, let it
come forward through this group.
At the same time, keep in mind the CSV folks have put
forward a suggested structure which is open source and not
subject to an IPR claim or license.
Meaning? Users of Spam Assassin, other open source filter
solutions and receivers relying on open source technologies
would not have to rely on or implement Sender-ID to deal
with phishing. Let MS make its IPR claim and request a
license. Instead receivers who prefer unencumbered open
source methodologies could implement SPF and either the CSV
anti-phishing solution and/or any SPF anti-phishing
solution which is developed.
I realize this runs contrary to the suggestion to 'embrace
and enhance' Sender-ID.
But keep in mind 'boots on the ground' or in this case 'SPF
implementations' as driven by receivers.
So, unless MS comes forward and says okay, we agree it is
best to also run SPF checks at pre-data stage, irrespective
of the presence or absence of Submitter, who should be
doing the embracing?
Thoughts? Comments? Suggestions?
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
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