Here's an idea:
Forget about it! Take it all out. Don't mention it at all.
If anything, just say
"Microsoft SENDERID uses SPF technology. See Microsoft Web Site."
period.
All you guys are doing are creating more of a mess with concepts you
shouldn't be involved with in the first place.
Look. We (my company) decided a long time ago we will not incorporate
SenderID. I know SENDMAIL and AOL has decided to support it, but it
doesn't make them right. I know they made a stupid decision and I am going
to jump just because they decided to support it. Besides the marketing
value they feel is gained with advertised SenderID support, I strongly
believe any SMTP vendor who supports it only putting their customers at risk
and quite frankly, it puts companies with products like WCSMTP on the map
because we are already telling our customers why we will not support it.
This news is getting out and I believe this coming week, I'm scheduled for
some Internet Radio Interview to discuss how we addressed the spoofing
problem. If its brought up, I don't think I will be able to avoid
mentioning how and why I feel SenderID is flawed.
If the interview should ask:
"Yet Hector, it is said SPF 2.0 will incorporate SenderID? Will SPF 2.0 be
supported then?"
I believe I will say:
"Our system concentrates at transaction level authentication - protecting
the envelope per se. However, 3rd party developers can add programmable
DATA point hooks to add additional SPF 2.0 support or if they choose,
perform the task in a POST SMTP manner. In either case, it is outside the
scope of what we offer and we will not do it for reasons explained which
include product liability reasons. SMTP will need to change with a HEAD
concept in order to support SenderID. Until that happens, we will not
support SPF 2.0 if it attempts to enforce SenderID support. We have not
been wrong yet with our designs and in this case, I strongly believe it is
mistake for a SMTP vendor to add SenderID."
Sorry, but that is how I feel about it. Don't mean much to Meng. I know
that. But I'm confidence enough to know when that if its walks like a duck,
looks like a duck, smells like a duck, the odds are good its a duck.
You can't have it both ways. Either you support it 100% and do your best to
make it work with no bashing (concerns yes, but no bashing). Or don't
mention it at all because as it is now, its has many issues, it is not going
to work well and if you are worry about getting a bad rap - well, you
already have by continuing to promote it just by talking about it.
Did I even mention the bad pr and will developed with the open source
citizens and community?
Recommendation:
R&D on a improved backward compatible language. Get the HELO issue
cleaned up. Get RID of the relaxed provision or strongly urge against its
usage. Put the R&D efforts to address the Forwarding Problem or offer the
current integration solutions.
Anyway, that's my take.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, December 12, 2004 8:32 PM
Subject: Re: [spf-discuss] Re: spf-statement-on-SenderID
In <87837583(_dot_)1102808910(_at_)[192(_dot_)168(_dot_)0(_dot_)2]> Greg
Connor <gconnor(_at_)nekodojo(_dot_)org>
writes:
The statement as posted by Chuck and in the meeting transcript is, a
little fuzzy around the edges. I think it says what the council
wanted to say but comes out with the purpose a bit obscured.
I agree.
Keep in mind that this was the last subject to be brought up at the
meeting and it was after an hour and a half of discussion. What Chuck
posted was basically a dump of the last version we worked on and we
all agreed it needs more work.
After reading the meeting transcript, my understanding is that the
council sees a need for the following:
1. Differentiate SPF and SenderID, so that people don't think SenderID
is the inheritor of SPF. Make it easier for those who choose to bash
SenderID to do so without smearing SPF's good name.
Yes, I think this is very important.
2. Clarify that even though the SPF language is used to build PRA
records as well, this is an "off-label" use and not really related to
the core of SPF.
Yes.
3. Make sure that people reading the statement understand that SPF
Classic is still "going strong" and is not going to be replaced by
SenderID.
Several of us would object to even saying that it is 'still' going
strong, because that implies that SPF may be running out of steam.
SPF is not only the leading email anti-forgery system out there, it
has more deployment than all others combined and is growing more
rapidly.
4. NOT saying that PRA is bad, or that we discourage its use, just
that we recognize a couple of barriers, and these barriers to SenderID
don't apply to SPF Classic. (Subtext: If PRA fails, SPF will not be
affected by that).
5. NOT mention technical issues such as reuse of v=spf1 records in
this statement, because this statement needs to go to a non-technical
audience. Reuse of records deserves attention, but should be its own
statement separate from this one.
Greg suggested a while ago on the SPF position statement on SenderID
that we break up that statement into several parts. I think this was
what the council was trying to do (or, at least that was my intent).
My intent was to try and craft another statement about the problems
with the PRA, if we actually decide we need to say something about
that. So, I don't view this as being off the table, but could be
depending on other factors.
I also think that a vote about the SPF position statement on SenderID
is still a possibilty, if for no other reason than I said I was going
to bring it to a vote on the council.
-wayne
-------
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