Jon;
What does it take for someone to be recognized as a large ISP and adopter of
SPF?
Is AOL big enough?
Is MSN big enough?
I think SPF is already PAST the experimental phase and should be treated as
such.
Please feel free to flame - I'm headed outside to sit under the sprinkler in
95 degree summer weather so no one on this list can make my life any hotter!
<sprinkler on>
Bruce Barnes
ChicagoNetTech
-----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: Tuesday, June 07, 2005 11:52
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: (SPF-Pass) RE: [spf-discuss] This is ridiculous.
From: wayne Sent: June 6, 2005 6:17 AM
|In <009101c56a67$6e5272c0$6c62fea9(_at_)ibmrkydk2ufvdd> "John Glube"
|<jbglube(_at_)sympatico(_dot_)ca> writes:
|
|> I thought all this was clear when I made my initial post in
|> this thread. But since it seems at least once person was
|> confused, I am clarifying matters by way of a top post.
|
|Thanks for clearing things up.
Your welcome.
|> As to what Wayne wrote on June 5, 2005 in this thread in
|> response to my post:
|>
|> |<snip>
|> |
|> |> 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.
|> |
|> |Right, which doesn't describe the SPFv1 protocol that has
|> |been in use and largely unchanged since late 2003/early
|> |2004.
|>
|> I believe the record shows there has been something like 6
|> draft protocols for v=spf1 since 2003,
|
|The question is not "how many draft specs have there been?"
|but "how compatible are the draft specs with each other?"
|Actually, the most critical one is "is the final spec
|compatible with the install base?"
|
|Yes, ther (sic) there have been many draft specs released, but
|the goal since I took over editing was to make them as
|compatible as possible. I have posted the list of changes
|between most of the specs, and a great deal of the changes
|in the most recent ones have been due to discovering
|incompatible changes were made during the MARID process and
|they need to be fixed.
|
|> Since the last 2 protocols, senders are now being asked to
|> publish v=spf1 records for both the domain in the SMTP mail
|>>From and the EHELO/HELO commands.
|>
|> Yes, yes I know, the mantra is that publishing a v=spf1
|> record for the domain in the EHELO/HELO command was always
|> part of v=spf1. However, since my involvement in June,
|> 2004, I don't recall any emphasis being placed on
|> publishing a record for the domain used in the EHELO/HELO
|> command until October/November 2004.
|
|I once went back and investigated the subject of the
|optional HELO checking in SPF. There were a lots of people
|who wanted back in the summer of 2003, and people kept
|asking for it after the "frozen" spec in Dec 2003. Hector
|is almost certainly the one who actually managed to
|convince Meng to change the spec in early 2004, but he
|wasn't the first or only person to try.
|
|As I have said many times, the SPF wizard that Meng created
|back in 2003 recommended publishing SPF records for the
|HELO domain and would generate them for you, just like the
|SPF record for the MAIL FROM domain. I bet if you use
|archive.org you would be able to verify this.
|
|What happened was that during MARID, the emphasis on HELO
|checking via SPF was not mentioned much (although it was
|mentioned). There were two primary reasons for this.
|First, when CallerID and SPF were merged after the MARID
|interim meeting, MS *REALLY* didn't want to do HELO
|checking, so all references to it were dropped in SenderID.
|Secondly, the workgroup chairs said we were supposed to
|focus on SenderID and we would deal with the other
|identities later. As a result, discussions of SPF's MAIL
|FROM and HELO checking didn't come up very often, but the
|CSV folks kept bring up their system.
|
|> As such, looking at the record in its entirety, I must
|> strongly disagree with your statement and no, I am not
|> going to go through the record at this time and dig up
|> every relevant statement.
|
|Well, um, I'm not sure what to say. I *have* gone dug up
|the relevant statements, and I *was* there throughout, not
|just since June 2004. If you don't believe what I tell you,
|and you won't investigate things your self, then I guess we
|will just have to agree to disagree.
I appreciate your going through the record, although I
don't fully agree with your interpretation of certain
events.
However, that is not the basic problem. My underlying
concern?
Based on all that I have read and seen, the SPF council
should clearly state given the present state of network
security, along with the time needed for mail forwarders to
adjust, to minimize false positives, while avoiding back
scatter, the highest and best use of SPF v1 is for
receiving networks to check the domain in the SMTP mail
from, or in its absence the domain in the EHELO/HELO and
use the result to filter mail against external or internal
white lists.
Otherwise, given the concept, "your network, your rules,"
if networks start using SPFv1 to do more, this is when you
get into the experimental stage.
Why? Although the proposal itself may now be reasonably
well documented, folks need to fully understand the
implications of what happens if receiving networks start
checking and rejecting mail, instead of simply filtering
mail using SPFv1 records.
There are a number of presumptions in the protocol,
including:
* Sending networks have established appropriate network
security; and,
* Mail forwarders have implemented the needed changes.
If these presumptions are not satisfied, this leads to a
variety of edge cases. In turn, given the potential
significance of these edge cases, it can create a
significant level of false positives.
This is especially true if receiving networks use SPFv1
records for more than filtering against white lists and
senders other than bulk mailers sending mail from fixed IP
addresses are encouraged to publish SPFv1 records.
(In making this statement, I don't have actual numbers,
just anecdotal evidence and the comments filed by MAAWG
with the IETF.)
For all these reasons, I am suggesting it is best to
publish SPFv1 as an experimental protocol.
This will ensure the needed research, development and
implementation work can go forward, so that once a network
has put in place all the needed security changes and mail
forwarders have implemented the needed changes, testing can
be done on a sufficiently large enough scale to verify that
these changes will in fact resolve the edge cases.
If not, then what can then proceed as a standard is a
protocol which gives receivers a way to check mail from
fixed IP addresses against internal or external white lists.
If it does, then the broader protocol can proceed as a
standard. But to ask for a standard track at this stage in
my view is premature.
|> Having said this, I appreciate the acknowledgement that:
|>
|> <snip>
|>
|> |Even if we do come up with something new to address the
|> |problems with SPFv1, I don't see the deployment of SPFv1
|> |ending any time in the near future.
|>
|> <snip>
|>
|> The acknowledgement that there are "problems with SPFv1" is
|> the strongest reason for keeping v=spf1 as an experimental
|> protocol.
|>
|> Why? So that those who use this protocol will understand it
|> is an experiment and so subject to change.
|
|By that logic, almost every protocol on the internet is
|"experimental". I mean, the whole idea of the various
|sender verification checks is to fix known problems with
|SMTP.
That's a presumption on your part.
I would argue that SMTP works, but the protocol relies on
certain trust assumptions. To thwart trust abuses, we need
to build in certain security measures. Some of these
security measures are already standards, such as SMTP
authentication.
Other security measures, such as setting up a protocol for
"Certified Server Validation," Bounce Address Tag
Validation" and "Domain Keys Identified Internet Mail" will
help to thwart trust abuses that have been identified.
By proceeding in this fashion, instead of developing a
protocol which is based on certain presumptions about how
the mail world needs to change, for the protocol to work,
you take existing protocols and best practices and then put
forward security measures to support these protocols.
This is why I favour the underlying design philosophy
behind CSV, BATV and DKIIM, over the approach taken with
SPF (and SIDF).
I appreciate this is a fundamental matter and in the
circumstances, I suggest it is best that we agree to
disagree.
John
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com