spf-discuss
[Top] [All Lists]

Re: Trying to specify SPF Classic?

2004-10-01 20:04:01

----- Original Message -----
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, October 01, 2004 9:04 PM
Subject: Re: [spf-discuss] Trying to specify SPF Classic?


On Tue, Sep 28, 2004 at 11:03:56AM +0200, Koen Martens wrote:

I have proposed to the IETF AD and co-chairs that we publish
an Experimental RFC to document SPF Classic, and also
publish Experimental RFCs for Sender ID to make Microsoft
happy, and also publish Experiemental RFCs that head in the
direction of Unified SPF.

How do people feel about this course of action?

Please don't take this the wrong way.

Personally,  you confuse me.   In all honesty I can't help but feel you have
"more connection" with this MS situation than you make it out to be or care
to be publicly known.   If I am wrong, then I sincerely apologize. But
something doesn't smell right here.  MS patent applications lacking obvious
reference to LMAP, SPF or your contributions raises eyebrows. See issue #2.

Three issues:

1) SenderID is a flawed, half-baked idea:

I personally feel purely based on the technical merits that Sender-ID is
flawed.  It is something we will simply not support.  I have a good feel for
this and I will go on record to predict that if MS does indeed implement
SenderID in her products, it will suffer some major PR issues once the
companies/enterprise begin to see the danger of using SenderID.  Look, it
isn't like MS was never wrong in its "designs" that were borderline
problematic in the security area, designed in name of "integration"  but
inevitably became a world wide nightmare for them.  I strongly believe this
will one of them.  There is one way I can see where it will not and that is
to change SMTP with a HEAD like command.  If that is the intent of MS, then
they need to speak up now, because there is NO way on earth the acceptance
of the PAYLOAD will be done for unreliable SenderID purposes. Sorry.

2) Conflicts - any protesting vs. any promotion.

It just doesn't make sense.  There can't be any complaining yet trying still
references the patented technology. If there is a fundamental problem with
SenderID licensing issues for many across the board, then how in the world
do you expect SPF2 promotion of SenderID will help its adoption?    This is
what I am confuse about for your actually position in all this.  Something
doesn't give.  If it was me,  I would be screaming bloody hell simply for
the fact that the patents did not make any reference to SPF.

3) Complexity - "All in One" solution lowers acceptability.

Even then, I strongly believe the two systems are completely independent
concepts.  The "direction" of adding more complexity to SPF as to making it
a "do all" product will raises the barriers to acceptability and adoption.

I understand FULLY the philosophically technical opinions of "Admins" vs.
"developers" to create a "complete product" is the reason behind continued
pace.   Case in point - you exploration into the "next do-everything
generation."    It is natural to see this occurring.

But it is the wrong placement of work especially when you need to get the
support of software vendors as well.  I understand you believe that you can
create various scripts, plugins for the various mail servers, but it will
not cover all and if you lack the consideration for the general smtp server
industry, open source, free and commercial, then I see problems.

In short, let "script" writers, software developers implemented these
technologies in their own way.  Absolutely, that implementation will come
with the help of their customers, including administrator who have the
practical knowledge base for operations.  But as sure there is will be a
tomorrow, this continued pace will fail in the long run.

I've said this before, the reason SPF was successful in getting industry
consideration was 100% because of it simplicity - plug and play concept with
little to no conflicts to current operations.    What you are doing now is
"stepping on these toes" and that is where you begin to see why SPF2 will
get less attention.

Finally,  I am not saying SPF2 should not continue.  The mail forwarding
problem will be there.  Let people decide how they want to solve that
problem.  Since SenderID is not the solution, Clearly, there will be
continued exploration in this area.  Don't muddy the water with it.  But if
that is truly what you are looking for and what, then I believe it will be
fair to all that you clearly state your position with this.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office