----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
The whole idea of NEUTRAL and SOFTFAIL or "relaxed provisions" as I
called
it was flawed. In my strong technical design opinion, it is a MAJOR
loophole in the SPF specification.
Yet, I understood the migration reasons. My suggestion was to make it
TIME
LIMITED.
Are you also going to do the same thing for None? If you treat
Neutral worse than None, you are just going to discourage people from
publishing SPF records because it is safer to not publish them.
A NONE means there is no policy exist for the domain. The question of how a
receiver system handles this depends on a different concept of ESMTP
enforcement. That is an entirely different general idea but can be related
too.
For example, a "Closed System" can mandate via an ESMTP extension that is
SPF required. But again, a different concept.
I'm talking about existing SPF relaxed policies, those with ~all or ?all.
In my view, if the domain are not ready to publish a proper and secure SPF
record, then the domain shouldn't be screwing with it until their network of
machine is ready to use it properly.
But I can understand a migration concept if and only if it is a time
limited.
I see nothing wrong with a Receiver Policy that limits the length of
time email can be accepted from a domain which gives None/Neutral
results.
Again, I mean SoftFail or Neutral results. None, Pass or Fail are ok.
If I had my choice, I would be more client/server driven to negotiate the
authentication. But this can be part of the SPF future. What you need to
do now is make sure it is ready for the future.
In my view, you are going to come across this relaxed policies in every step
of the way and until it is solidly addressed policy wise, it just make SPF
weak in the eyes of developers, atleast my eyes <g>
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com