John Glube wrote:
In closing MARID, the IESG invited individual submissions
for consideration as experimental proposals.
v=spf1 supports checking the domain in SMTP mail from and
the present draft includes checking the domain in
HELO/EHELO.
(Personally, I would have preferred that the experimental
draft for v=spf1 focus solely on providing a protocol
concerning SMTP mail from, but that is a separate issue.)
spf2.0 supports checking the domain in SMTP mail from or
PRA.
What is the purpose of the experiment?
The experiment's purpose is to determine which scope, if
any, is best suited for e-mail authentication using an SPF
type record.
The scopes which are on the table are HELO, MFROM as
supported by v=spf1 and MFROM, PRA as supported by spf2.0.
I think this is not an appropriate view of the situation. HELO/MFROM
checking (and thus SPFv1 in particular) serves to prevent forgery of
envelope (transport-level) identities, and thus prevent misdirected
bounces et al. This has always been the intended function of SPF, right
from the beginning. Header checking (PRA) serves to prevent forgery of
header (content-level) identities, and thus prevent phishing et al.
Those are essentially disjunct functions, and that's also why most of the
SPF community think it is not acceptable to allow the use of v=spf1
records, which were published with envelope identities in mind, for
anything else, such as checking header identities in particular.
Both frameworks use SPF type records. This was the essence
of the understanding that Meng reached last fall, allowing
for backward compatibility.
Let me clarify that: both frameworks use the basic SPF record syntax, but
not the same type of record. In general, v=spf1 is not v=spf2, and
Microsoft's attempt to fall back on v=spf1 records for header identities
is, by definition, technically broken.
Since we are discussing an experimental RFC and not an RFC
standard, what hard evidence can justify language other
than that proposed by the IESG?
The SPF experiment has already begun a long time ago (see the many v=spf1
records that have been published over the last two years), and we don't
want to jeopardize that and start anew. That would be pointless as SPF
has shown good success within its intended field of operation. I don't
think any other "hard evidence" is required, do you?
Do you think there would be a need for any more pro-active
efforts in this direction?
*** My questions go to a fundamental issue, what is the
objective?
Is the objective to fashion a DNS based protocol using IP
addresses that allows for e-mail authentication within the
existing SMTP framework without doing detrimental harm to
the existing e-mail infrastructure?
This was my take of the IESG directive when it closed MARID
and asked for individual submissions.
I think this description of yours fits.
Basically, SPFv1 is supposed to be a more sophisticated counter-part to MX
records.
In the circumstances, since the SPF community has chosen to
make a submission within this framework, then I would
suggest you need close collaboration with the large ISPs
that are using SPF to ascertain what issues have been
identified and ultimately adjust the protocol accordingly.
No, we are not going to make incompatible changes to SPFv1, as that would
break most of the installed base out there. However, after the SPFv1
specification has been frozen (through standardization with the IETF or
through other means), we plan to take on SPFv2 or (if Microsoft claims
sole authority over v2) v3 -- possibly in cooperation with the developers
of other sender authentication protocols. Any feedback we receive that
suggests the necessity of incompatible changes will be considered then.
One of the core problems with SPF is that path based
authentication using SMTP mail from breaks mail forwarding.
This issue has been on the table forever. The proposed
solutions are:
* Have everyone upgrade to SRS and/or Submitter; or,
* Abandon mail forwarding.
Given the time it has taken to get ISPs and web hosts to
consider blocking port 25 and mandating SMTP
authentication, is this realistic?
I think it is realistic. In fact, many large and very large forwarders
have already adopted one or another sender rewriting scheme.
The point is, however, that as long as we want to solve the misdirected
bounces and related problems, we really do not have any alternative to
breaking the kind of forwarding that doesn't rewrite the sender address.
Another core problem with SPF is that relying on path based
authentication using SMTP mail from poses significant
difficulty for the vast multitude using vanity domains.
Does it? Or can that be solved by rewriting the envelope sender?
Remember, people can use header identities for purposes that are not
appropriate for envelope identities -- in fact, that has always been the
point of having separate envelope and header identities, and separate
"From:" and "Sender:" headers in particular. See RFC 821/822.
Presently, given these and other issues, the only realistic
way to publish an SPF record is to end it with ~all.
I don't agree. For a trivial counter-example, domains that should never
ever send mail can live very well with "v=spf1 -all".
You (and others who make the claim that "-all" is useless) have a wrong
notion of the purpose of envelope identities checking. No offense. :-)
The whole purpose of an experiment is to put forward a
hypothesis, learn from real world experience and adjust the
design accordingly, or scrape it, if the design is fatally
flawed and try something entirely different.
Therefore, in response to your question, my answer would be:
* You need pro-active interaction with the large ISPs;
* You need to identify the underlying issues with path
based authentication and determine whether: (i) the
proposed solutions are realistic; or (ii) you need to
change the design.
We are aware of that, but we are not going to make incompatible changes to
SPFv1. See also the two paragraphs of section 1.1 of
draft-schlitt-spf-classic-00. SPFv{2,3} is an entirely different matter.
At day's end PRA checking will become redundant with the
implementation of a light weight cryptographic solution
based on the work presently being done with DMK and IIM.
I doubt that's the way things will be going, as said lightweight crypto
solutions have problems on their own, noting in particular the problem of
messages getting munged by certain forwarders.
Yes, these problems can be solved by a "how not to munge message parts
when forwarding" campaign (similar to our "how to rewrite the envelope
sender when forwarding" campain), but then we can just use full message
crypto (PGP, S/MIME) right away, which is the appropriate long-term
solution. From my personal viewpoint, DK and IIM (and Sender-ID/PRA) are
nothing more but crooks for the non-path-based sender authentication
problem.
One of the concerns that I have is that many in the SPF
community believe that e-mail authentication is the vehicle
for "fixing" SMTP and so permanently thwarting online abuse.
SPF does fix one or two ambiguities in SMTP, which of course requires
incompatible changes, i.e. breaking certain legacy behavior that was
previously allowed. You won't be able to fix SMTP's fundamental problems
without making incompatible changes. Your only alternative is to abandon
SMTP altogether, and I doubt that is going to be any more enjoyable
(although it will certainly happen all by itself sooner or later if we
don't fix SMTP).
Still, SPF is only a first step. Many problems remain, and other
solutions will be required to fix them all. I seriously doubt anyone of
the SPF community thinks that SPF alone could do that.
E-mail authentication is not the solution to online abuse,
but simply a tool which can be used to aid in solving
present delivery issues facing those who wish to
legitimately use the "common green."
Who would object to that? :-)
The underlying solution to online abuse? Network security
backed up by law enforcement and consumer education.
[...]
Unfortunately, this is going to be a never ending battle.
As is democracy. So should we stop caring because it is a never ending
battle?
Why am I making these comments?
* Unless and until the SPF community comes forward with
solutions for the known issues and these solutions are
acceptable to the community at large, path based e-mail
authentication will have limited value in providing a basis
for sender authentication and reputation.
Look, the problems of the current e-mail system (of which SMTP is the
biggest part) can be fixed in several distinct ways. People are arguing
over what are the right ways, but that doesn't mean one way is wrong and
another is right. Thinking that requiring envelope senders to be
rewritten during forwarding is a good solution doesn't imply thinking
other solutions are wrong (although of course people always consider
certain other solutions to be "wrong", whatever that means).
In our eyes, SPF has the potential to solve a real problem, and possibly a
few more, and if implemented correctly, it does no harm, even if it
doesn't succeed. We will see if SPF's way is viable and if it will be
accepted by the e-mail world. That's the point of doing the experiment,
and we are not going to abandon the experiment simply because some think
our solution is wrong for philosophical or strategical reasons.
(Technical objections are most welcome, of course.)
* If the solutions for the known issues are not acceptable
to the community at large, then stock must be taken of the
situation and adjustments made to achieve the larger
objective.
Agreed.
I apologize for going on at length, but hopefully my
comments will allow people to move ahead in a fruitful
fashion.
Thanks for your comments!