|-----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 Julian
Mehnle
|Sent: June 3, 2005 10:43 AM
|To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
|Subject: Re: [spf-discuss] This is ridiculous.
|
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA1
|
|John Pinkertun (sic) wrote:
|
|> SPF is dying on it's feet and you guys are wasting time
|> arguing about the semantics of wording which has limited
|> practical interest, [...]
|
|So SPF is dying, yes? Have domain owners started removing
|their policies?
You will not see discussions on the SPF mailing lists about
the issues system administrators and delivery folks have.
Folks don't want to put their flak jackets on.
A couple of weeks ago I posted a couple of "rants."
My reason for doing this was to point out to people and in
particular the Council that based on information which had
come to my attention, after much testing in certain
sectors, the consensus view seem to have developed, because
of all the edge cases, the use of v=spf1 records was
limited on the sending side to bulk mail senders sending
from a fixed source and by receivers to check the SMTP mail
from records and to filter against white lists.
I urged the Council at that time, get with AOL, talk to
them.
Subsequently:
* Carl Hutzler graciously made a post to ietf-mxcomp in
which he pointed out that AOL was using SPF records to
check the domain in the SMTP MFROM address for filtering
against white lists.
* John Levine said on ietf-mxcomp, no one would have any
real objection if folks were saying the benefit of
publishing v=spf1 records is for senders of bulk mail from
a fixed source, so allowing receiving networks to filter
against white lists; and,
* Andy Newton, while applauding the work being done by
Wayne to document existing usage, also suggested a
'framework' approach would have better likelihood of
acceptance.
Since then the issue has come up elsewhere and yes, folks
are pulling v=spf1 records and not just Outblaze, because
of the concern about edge cases and that receiving networks
won't use the records "responsibly."
Now, I appreciate folks think, well this is a cop out. We
should be writing a spec which compels senders to change
their behaviour and address issues such as the
cross-forgery issue and so forth, while giving receiving
networks a completely free hand.
My point? Yes, there is a need for people to secure their
networks to stop outbound spam. But this is not the
providence of email authentication. The lead on this charge
has to come from a different direction.
Guess what, it has been? Who has been leading this charge?
America Online. The very same folks who have been urging
folks to publish v=spf1 records and I would suggest have
determined that there is value in having bulk senders
mailing from a fixed source publish v=spf1 records which in
turn allows checking of the domain in the SMTPS mail from
records to filter against internal or external white lists.
And please remember that Carl Hutzler, in his posts to
ietf-mxcomp went on to write, in essence, if you want to
use it (referencing v=spf1 and speaking of SMTP mail from)
for anything else, it is your network and your rules, but
...
(I am paraphrasing.)
So, let's accept the limits of v=spf1 given the general
state of affairs, let the folks who are pushing network
security, push network security, acknowledge the edge cases
and tell network administrators what is the highest and
best use.
If you want to apply for a standard for v=spf1, see the
IESG reject the request and then proceed to set up your own
standards body, hey that's your choice. But, that is a road
I can't follow.
We need to remember what the IESG said when closing down
MARID:
<snip>
|Rather than spin in place, the working group chairs and
|Area Advisor believe that the best way forward is
|experimentation with multiple proposals and a subsequent
|review of deployment experience. The working group chairs
|and Area Advisor intend to ask that the editors of existing
|working group drafts put forward their documents as
|non-working group submissions for Experimental RFC status.
|Given the importance of the world-wide email and DNS
|systems, it is critical that IETF-sponsored experimental
|proposals likely to see broad deployment contain no
|mechanisms that would have deleterious effects on the
|overall system. The Area Directors intend, therefore, to
|request that the experimental proposals be reviewed by a
|focused technology directorate. This review group has not
|yet been formed but, as with all directorates, its
|membership will be publicly listed at
|http://www.ietf.org/u/ietfchair/directorates.html once it
|has been constituted.
<snip>
That was and is the whole purpose of the IESG process from
the perspective of the SPF community. To have a focused
technical review of the protocol for v=spf1, before
proceeding with publication of an authorized IETF
experimental document to allow for wide spread
implementation.
Keep in mind the purpose of an experimental protocol:
|The "Experimental" designation typically denotes a
|specification that is part of some research or development
|effort. Such a specification is published for the general
|information of the Internet technical community and as an
|archival record of the work, subject only to editorial
|considerations and to verification that there has been
|adequate coordination with the standards process (see
|below). An Experimental specification may be the output of
|an organized Internet research effort (e.g., a Research
|Group of the IRTF), an IETF Working Group, or it may be an
|individual contribution.
<http://www.ietf.org/rfc/rfc2026.txt>
I appreciate that while the IESG process has been ongoing,
field testing of various proposals has continued.
The benefit? The Community is getting a fairly good idea of
the strengths and weaknesses of v=spf1 as part of the
ongoing effort to come up with a scheme for email
authentication that works.
But, the whole exercise of email authentication, despite
remarks of the marketing folks and the convictions of many,
continues to be a research and development exercise,
although the outlines of what can work and how best to
proceed have become much clearer, as a result of intensive
efforts by the large mail box providers since the fall.
All right, I am going to stop. I appreciate the efforts
Wayne is making to document existing usage. Since this is a
community effort, it takes time and the lack of focus is
frustrating.
But I strongly urge the Council to heed what is being
conveyed as you proceed forward.
- John