Julian,
Thanks for getting back to me. See my comments inline.
John
John Glube
Toronto, Canada
|-----Original Message-----
|From: Julian Mehnle [mailto:bulk(_at_)mehnle(_dot_)net]
|Sent: April 6, 2005 6:12 PM
|To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
|Cc: jbglube(_at_)sympatico(_dot_)ca
|Subject: RE: [spf-discuss] IESG evaluation of SPF
|
|Hi John.
|
|Thanks for contacting us. I am one of the council members,
|and this is what I can answer without consulting the
|council:
|
|John Glube wrote:
|> Can anyone from the Council tell us what is the present
|> status of the IESG evaluation of
|> draft-schlitt-spf-classic-00.txt?
|
|We are generally aware of the IESG's comments on
|-spf-classic-00, and we are preparing a -01 revision of the
|draft in which we are going to address some of them.
|Sorry, I, personally, cannot give you a timeframe for that
|right now.
*** Understood.
|> In particular, I ask the following questions:
|>
|> * Are the authors prepared to make the proposed change to
|> the final sentence in section 2.4?
|>
|> The sentence in issue presently reads:
|>
|> "Checking other identities against SPF records is NOT
|> RECOMMENDED because there are cases that are known to give
|> incorrect results."
|>
|> The IESG suggested this sentence read:
|>
|> "Checking other identities against SPF records is not
|> defined in this document."
|
|Although the council has not made a formal decision on that
|(and perhaps won't), I can predict with high confidence
|that this proposed change will _not_ be approved the
|council.
|
|Rationale: The current SPF Classic specification --
|unfortunately, some might say -- defines not just the SPF
|algorithm, but also how it is to be applied to "v=spf1"
|records in particular. A large number of "v=spf1" records
|have already been published, and making the above change
|would imply allowing the semantics of those records to be
|changed by another specification. This exact issue has
|been discussed in the past by the council and at least
|three of five of the council members consider such an
|implication to be absolutely prohibitive (and the majority
|of the project community supports that decision). Also see
|our latest press release[1].
|
|A way out of this might be to abstract the SPF algorithm
|from the application of "v=spf1" record checking into a
|separate draft. I don't know what implications that would
|have on the standardization process, but I will incite
|discussion of this possibility.
*** I have read the follow up discussion on this point on
the SPF discuss list, along with your comments and the
press release.
Without getting involved in the language issue, I think
people need to take a step back for a moment and understand
what is transpiring.
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.
Both frameworks use SPF type records. This was the essence
of the understanding that Meng reached last fall, allowing
for backward compatibility.
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?
(As an aside, I felt the course chosen by Meng was the
wrong path and voiced my objections quite strongly. A
crisis had been created, along with a deadline, being the
FTC/NIST e-mail authentication summit. I felt the crisis
could be used to kill off PRA as a viable option, or at
least compel Microsoft to abandon its patent license in
exchange for accomodation. Meng felt that since PRA was not
a long term solution, it made sense to reach an
accomodation and move forward. All of this is now water
under the bridge and there is no point in regurgitating
ancient history.)
|> * What other issues if any are outstanding before
|> draft-schlitt-spf-classic-00.txt can move forward for last
|> call and then adoption as an experimental proposal?
|
|As I wrote above, we are currently preparing a -01 revision
|that will solve most of the outstanding issues. As I
|haven't been in contact with our draft editor lately, I
|cannot confidently and concludingly elaborate on those
|changes at the moment. The first of several pre-releases
|of -01 is planned for this week-end.
*** Understood and thanks.
|> Presuming this draft achieves experimental status, one other
|> question:
|>
|> * Since draft schlitt-spf-classic-00.txt is an experimental
|> proposal, what steps if any is the SPF council going to take
|> to assess user feedback and testing results by the large
|> consumer ISPs in deciding how to move forward with a DNS
|> based proposal for e-mail authentication?
|
|The spf-discuss mailing list is an open forum, and anyone
|who has to offer constructive comments on the SPF
|specification (or related matters) is most welcome to voice
|them here. Meng Weng Wong and several members of the
|project community are in contact with large ISPs and are
|collecting input from them; this has been happening
|semi-actively so far. The SPF project has also been in
|loose contact with alternative e-mail sender authentication
|projects, specifically including Yahoo's DomainKeys,
|Identified Internet Mail (IIM), and Microsoft's Sender-ID.
|
|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.
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.
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?
If it is not realistic, what are the alternatives?
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.
Presently, given these and other issues, the only realistic
way to publish an SPF record is to end it with ~all.
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.
As to PRA, we need to keep in mind that this is a band aid
proposal to provide an interim solution for the phishing
problem facing the financial sector.
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.
Also, what is the overall objective?
To build a scaleable solution which allows for sender
authentication and reputation, without impairing the e-mail
infrastructure, that:
* respects individual privacy;
* can be realistically used from the smallest operation,
being a one man band to the largest organization;
* allows recipient networks to reject bad e-mail and
deliver good e-mail;
* aids in mitigating the present problems surrounding the
delivery of requested bulk e-mail and individual e-mail
messages.
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.
I suggest this is an unrealistic objective and quite
frankly in my view beyond the underlying project scope.
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."
The underlying solution to online abuse? Network security
backed up by law enforcement and consumer education.
(See the article titled "How To Stop Spam," written by John
Levine quoting from a letter written by Carl Hutzler.
http://www.circleid.com/article/917_0_1_0_C/)
Unfortunately, this is going to be a never ending battle.
However, hopefully over time, the level of abuse will be
reduced to acceptable levels, so that e-mail remains a
viable communication tool.
In that regard, I would suggest that the path provided by
large organizations like AOL is taking us in the right
direction, although we must remember that one size does not
fit all.
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.
* 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.
I apologize for going on at length, but hopefully my
comments will allow people to move ahead in a fruitful
fashion.
|Julian Mehnle,
|SPF Council Member.
|
|References:
| 1. http://spf.mehnle.net/Press_Release/2005-03-23