-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of John
Glube
Sent: Thursday, August 26, 2004 5:43 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Unified NOT Sender-ID Was (RE: [spf-discuss] Sender ID and Return
Path)
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.
I've been thinking along similar lines. It seems to me that there is
potential for a great deal of synergy between CSV and SPF. One of the major
objections I see regularly voiced on the MARID list against Sender-ID now
and SPF before is the impact on DNS. I believe that there ought to be a way
to unify CSV and SPF to give us a technically and socially superior design
to either alone.
As I understand it, the idea behind CSV is that when an SMTP session starts,
the receiving SMTP server will check the HELO/EHLO name (it must be a FQDN
for CSV) provided by the SMTP sender against a SRV record retrieved from
DNS. This can tell the receiver if the sending server is who it says it is.
If this test fails, then the entire SMTP session can be rejected. If it
passes, then other tests can be applied (it says that in the CSV ID).
Nominally a reputation check would come next (this is the subject of the DNA
ID).
The relevant IDs are here:
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt
At this point, if the sending SMTP server has a very good reputation, it
might be safe to dispense with additional checks. If the SMTP server has a
very bad reputation, then the entire session might be refused. If the
reputation is uncertain then additional checking would be in order. What
constitutes good/bad reputation would be a matter of local policy.
As an MTA operator, the above would, I imagine, be useful and have
substantially less impact on DNS than SPF or Sender-ID because it's one DNS
query per SMTP session (unless HELO/EHLO changes in midstream, but I would
imagine that's unusual). As a domain owner, this means nothing to me.
Since I don't operate my own MTA, there should never be a case where
HELO/EHLO contains one of my domains.
The next step would be SPF classic. If CSV has produced a pass, that could
be considered an equivalent to an SPF pass for HELO/EHLO, so HELO/EHLO
checking SPF engines wouldn't have to redo that check if passed a pass
result from CSV.
The one change that I think we could make to SPF classic to really integrate
it with CSV would be to change the way include: works. If I
include:bigisp.net in my SPF record, what I am saying is that any MTA from
bigisp.net may send mail for my domain. If I have a CSV pass for a
bigisp.net HELO/EHLO, then I know that an MTA from bigisp.net sent the mail.
So, the change would be to make a CSV pass count as matching the include:
mechanism.
This would give us a response to those in the CSV camp who complain that SPF
will overwhelm DNS. If someone does CSV and has a very good reputation,
their SPF record will be less likely to be queried. That is for mail sent
from user(_at_)bigisp(_dot_)net, if the reputation is good enough, a CSV pass
will be
sufficient. For mail sent from a bigisp.net MTA, but from
user(_at_)somedomain(_dot_)com, then a CSV pass will match the include: and the
SPF
record will not have to be queried.
This could help encourage deployment of CSV (which I think the CSV
proponents would like). It could alleviate some concerns that may be
causing some people to hesitate to deploy SPF records. It would unify the
two camps that are proposing MARID solutions that do not have IP issues.
I also believe that this can be done with no changes to the CSV and DNA IDs.
They don't have to change, we just change a bit to leverage the information
that CSV might have already obtained.
Scott Kitterman