spf-discuss
[Top] [All Lists]

Re: SPF 2/3 maybe it is time to get this going.

2005-06-18 16:04:24

----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, June 18, 2005 6:25 PM
Subject: Re: [spf-discuss] SPF 2/3 maybe it is time to get this going.


Its not that I disagree with what you said, but I thought you had enough
experience with IETF by now to understand why they'd never agree to it ...

I have experience to know that a separating of disciplines - enough to
confuse any matter,  but I do think they are just industry veterans
(managers) and if I ever did had the privy to argue the case with them,  we
wouldn't be in this position :-)

I don't think many can argue with sound technical common sense and in that
vain, I am an optimist and always felt that common sense always does
prevail.

But I also think the way SPF is being done here can be better - better
argued for.  Too much political conflicts.  Stay away from that and just
present the facts - the common sense - make them realize this.

ESPF sounds nice though and easier to use then saying unifiedspf.

Its all about how you put things, and if ESPF is presented as the Extended
Features to SPF in the same vain ESMTP presents the extended features to
SMTP,   they will have very little to argue again this.  So its more than
just "sounding good,"  it is common sense.

After all,  SPF1 is the current pseudo standard and there is NO way on earth
people are just going to DROP it for SPF2 when there is no clear advantage
and in fact, could cause more problems.

Just consider this: We and many mail server vendors existed in the
commercial BEFORE the internet.  Do you really think we added SMTP just
because it was the "IETF" standard?   No the standard existed for YEARS - we
added it because people wanted a common framework that was not proprietary
and since more and more people demanded it, it was then offered.   But we
just didn't add SMTP because it now the IETF.

SPF1 is here. No one can change this.  Not even IETF.

So you compromise - SPF people should welcome "extensions" including SID as
long as it is published as ESPF draft and the IETF should also welcome this
and other new ESPF extended drafts because we have a basic framework in
place - SPF.   The basic framework SHOULD not begin with SPF2 because it
basically enforces only 1 way to operate - it enforces the PAYLOAD  and this
is by far the single most barrier to its acceptance.

We all can see new ESPF idea that are not related to SID.  Suppose someone
proposes a new 2822 HEADER such as:

        SENDER-DOMAIN: <responsible domain>

Then a ESPF draft can be written for it

I won't be able to do this with SID if it was the official standard and not
SPF.

That is what you have to present to the Hardies.

You need to talk about the future because we still have to research the spam
problem.  We can't lock ourselves into a patented SID - single solution -
framework that has absolutely NO guarantee of working whatsoever and if fact
present more problems than it solves.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com








<Prev in Thread] Current Thread [Next in Thread>