Subject: RE: Motion to abandon Sender ID

From: "Ken" <[email-masked]>
Date: Thu, 2 Sep 2004 09:48:07 -0700

I encourage the MARID working group, it's Chairs and the IETF to embrace
SenderID and help to promote it as a standard.
 
There is wide agreement, myself included, that the Microsoft IPR license
would be best removed from the proposal.  However, SenderID is a good
solution and the it's the best that we can offer the internet user
community at this time.  We can work through the licensing, it cannot be
a deal breaker.  MARID's objective is to put forth an authentication
solution that can be a best first-step in solving the spam problem that
plagues all of us. Whether we represent the open source community or the
furtune 500, we have a responsibility to the users of the internet and
to protect the email medium.

The IETF and the MARID group is comprised of individuals who are
involved in *developing* and *improving* the internet.  The IETF has a
long tradition of significant contributions to the internet.  The
internet would not be relevant today, if not for the IETF, and the IETF
is relevant to the internet.  We have a responsibility to the *users* of
the internet. 

If the MARID chairs abandon SenderID, SenderID will not die.  Microsoft
will move forward with SenderID at MSN, HotMail, within Outlook and
Exchange.  SendMail will move forward with SenderID.  That represents
enough user email boxes that the spam-fighters BrightMail, CloudMark,
Senderbase, Tumbleweed have already announced SenderID support.  The
Email Service Provider Coalition, representing a very significant
portion of legitimate commercial email will publish SenderID in DNS.
ISP's that want their users email to reach inboxes at MSN, HotMail,
Exchange or SendMail supported email boxes may want to publish SenderID
records in DNS.  My company will certainly publish both SPF1 and SPF2
regardless of the MARID decision.

If MARID abandons SenderID, it might be a step towards IETF irrelevance,
as both SPF Classic and SenderID will live on.  If MARID embraces
SenderID, with it's flaws, there is hope for a unified approach to
solving the SPAM problem (SenderID as step 1).  The flaws can be
addressed, the licensing can be addressed, the solution must start now.
We all know that the solution starts with authentication; it can be
improved with accreditation and reputation.

Thank you for your consideration.

--KEN

Ken Schmidt
VP Operations
Savicom

---

From: "Michel Bouissou" <[email-masked]>
Date: Thu, 2 Sep 2004 19:18:37 +0200 (CEST)

> SenderID and help to promote it as a standard.
[...]
> Exchange.  SendMail will move forward with SenderID. [...]

What I read above is "Resistance is futile. You will be assimilated.", or
am I mistaken ?

Is it really the role of IETF to "follow what BigCompany decides, because
they'll do it anyway" ?

-- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: "Ken" <[email-masked]>
Date: Thu, 2 Sep 2004 11:26:44 -0700

Michel:

I'd say a more precise interpretation of the extracted sentences would
be:

"Think about the consequences of our actions.  Imagine what the world
will be like following a MARID abandonment of SenderID?"  You do not
have to be assimilated, but it seems unrealistic to believe that
SenderID will die.  It's a good technical solution for today.

--KEN

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michel Bouissou
> Sent: Thursday, September 02, 2004 10:19 AM
> To: [email-masked]
> Subject: RE: Motion to abandon Sender ID
> 
> 
> 
> Ken a écrit :
> >
> > I encourage the MARID working group, it's Chairs and the IETF to 
> > embrace SenderID and help to promote it as a standard.
> [...]
> > If the MARID chairs abandon SenderID, SenderID will not die.  
> > Microsoft will move forward with SenderID at MSN, HotMail, within 
> > Outlook and Exchange.  SendMail will move forward with 
> SenderID. [...]
> 
> What I read above is "Resistance is futile. You will be 
> assimilated.", or am I mistaken ?
> 
> Is it really the role of IETF to "follow what BigCompany 
> decides, because they'll do it anyway" ?
> 
> --

---

From: "Peter Bowyer" <[email-masked]>
Date: Thu, 2 Sep 2004 19:47:16 +0100

> SenderID will die.  It's a good technical solution for today.

Technically, there is far less of an issue. But what am I, and the thousands
like me, to do when I cannot implement the acknowledged good technology
because the maintainer of my MTA cannot incorporate it for non-technical
reasons?

The solution has to be technically sound AND deployable.

Peter

---

From: "Michel Bouissou" <[email-masked]>
Date: Thu, 2 Sep 2004 20:50:56 +0200 (CEST)

Ken a écrit :
> will be like following a MARID abandonment of SenderID?"

Will it be that terrible ? Will the world collaYou are presenting things
as if there were no alternative, as if we were in a "Sender-ID or nothing"
situation.

But this is not the case. There are numerous possible alternatives, which
may be as efficient or possibly better than the (yet untested on a large
scale) Sender-ID.

Among them SPF-Classic, which has a true (presumably happy, at least, I
am) installed base, and is unencumbered.

> You do not have to be assimilated, but it seems unrealistic to believe
> that SenderID will die. It's a good technical solution for today.

I don't care whether it actually dies or not as a technical solution, but
I care that a "solution" that is encumbered in such way, and that serves
the interests of a single big company at the detriment of the rest of the
community, should never be raised to a "standard".

---

From: <[email-masked]>
Date: Thu, 2 Sep 2004 15:22:43 -0400

> [mailto:[email-masked]]On Behalf Of Ken
> Sent: Thursday, September 02, 2004 2:27 PM
> To: 'Michel Bouissou'; [email-masked]

So is SPF Classic, but without encumberances.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

---

From: Rand Wacker <[email-masked]>
Date: Thu, 2 Sep 2004 14:05:20 -0700 (PDT)

On Thu, 2 Sep 2004 [email-masked] wrote:

> > [If the IETF were to abandon it]

And which solves a different problem.

-Rand