Mailing List Archive

From: Jeremy Pullicino Sent: October 26, 2004 3:57 AM

<snip>

|I understand that technically SPF and SenderID are
|practically the same thing and that now Microsoft has
|removed patents, making SenderID acceptable to companies
|such as AOL who have already announced renewed support for
|it.

<snip>

As to your technical conclusion, quoting from
draft-lyon-senderid-core, the authors, Messrs. Lyon and Wong
write:

|This document defines a pair of closely-related tests. One
|validates a message's Purported Responsible Address (PRA)
|as defined in [PRA]. The other validates a message's
|Reverse-Path (also known as MAIL-FROM address) as defined
|in [SPF].
|
|An e-mail sender SHOULD publish information for both tests,
|and SHOULD arrange that any mail that is sent will pass
|both tests.

[.Section 1, Introduction - page 2 of Sender ID:
Authenticating Email]

The authors go on to write:

|The PRA version of the test seeks to authenticate the
|mailbox associated with the most recent introduction of a
|message into the mail delivery system. In simple cases,
|this is who the mail is from. However, in the case of a
|third-party mailer, a forwarder or a mailing list server,
|the address being authenticated is that of the third party,
|the forwarder or the mailing list.
|
|On the other hand, the MAIL-FROM version of the test seeks
|to authenticate the mailbox that would receive Delivery
|Status Notifications (DSNs, or bounces) for the message. In
|simple cases, this too is who the mail is from. However,
|third-party mailers, forwarders and mailing list servers
|MUST specify an address under their control, and SHOULD
|arrange that DSNs received at this address are forwarded to
|the original bounce address.

[.Section 2, Problem Statement - page 3 of Sender ID:
Authenticating Email]

http://www.spfhelp.com/downloads/draft-lyon-senderid-core-00.txt

I agree conceptually the approaches for PRA and MAIL FROM
authentication are similar.

However, the test for the check host function involves
authenticating different identities. This can give rise to
different results depending on how a sender has arranged
his, her or its affairs.

On this point, see the following on backward compatibility
in the proposal:

|Administrators who have already published "v=spf1" records
|SHOULD review these records to determine whether they are
|also valid for use with PRA checks. If the information in a
|"v=spf1" record is not correct for a PRA check,
|administrators SHOULD publish either an "spf2.0/pra" record
|with correct information, or an "spf2.0/pra ?all" record
|indicating that the result of a PRA chek is explicitly
|inconclusive.

[.Section 3.4, Backward Compatibility - page 6 of Sender ID:
Authenticating Email]

http://www.spfhelp.com/downloads/draft-lyon-senderid-core-00.txt

On the patent issue, I quote from an article published in
CNET news:

|Among other changes, Microsoft removed language in its
|pending patents for Sender ID that could have included
|claims to Sender Permitted From, or SPF, a widely used
|system for email authentication that was merged with
|Microsoft's CallerID for Email to create Sender ID,
|according to Microsoft's Ryan Hamlin.

http://news.zdnet.co.uk/internet/security/0,39020375,39171356,00.
htm

However, MS has not withdrawn its patent claim on the
concept of PRA operating in combination with CORE, which
forms the basis for the technology being licensed under
Microsoft's Royalty Free License which is not compatible
with the Open Standard Alliance model.

John

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 19/10/2004


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 05:47:01AM -0400, John Glube wrote:
|
| However, MS has not withdrawn its patent claim on the
| concept of PRA operating in combination with CORE, which
| forms the basis for the technology being licensed under
| Microsoft's Royalty Free License which is not compatible
| with the Open Standard Alliance model.

Yes, this is correct. This seems like a novel situation,
though. Now there are essentially two halves to Sender
ID. As a receiver you can leave the PRA half untouched if
you don't like the patent situation, and implement SPF
Classic; as a sender you need to be careful your records
will work for both.

Is this state of affairs sufficiently satisfactory for the
industry as a whole to move forward?

I acknowledge that there are certain members of the
community who feel very strongly that as long as any part of
the spec is patent-encumbered, the entire thing should not
be allowed to proceed.

But in practice, Sender ID is being defined as a family of
drafts anyway; and it breaks down like this:

Lentczner's SPF Classic spec defining the protocol
+ the PRA spec
+ the new "Sender ID" core spec extending the protocol to PRA

So people who object to the PRA/Sender ID stuff can still go
ahead with the SPF Classic, which is what they would have
done anyway if the PRA stuff had never come along in the
first place.

Unless, of course, they are so disgusted by the whole thing
that they abandon SPF Classic as well. But that seems a
little bit like cutting off your nose to spite somebody
else's face.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

>-----Original Message-----
>From: owner-spf-deployment@v2.listbox.com
>[mailto:owner-spf-deployment@v2.listbox.com]On Behalf Of Meng Weng Wong
>Sent: Tuesday, October 26, 2004 9:52 AM
>To: spf-deployment@v2.listbox.com
>Subject: Re: [spf-deployment] Practical guidance for ESP's (SPF renamed
>to SenderID?)
>
>
>On Tue, Oct 26, 2004 at 05:47:01AM -0400, John Glube wrote:
>|
>| However, MS has not withdrawn its patent claim on the
>| concept of PRA operating in combination with CORE, which
>| forms the basis for the technology being licensed under
>| Microsoft's Royalty Free License which is not compatible
>| with the Open Standard Alliance model.
>
>Yes, this is correct. This seems like a novel situation,
>though. Now there are essentially two halves to Sender
>ID. As a receiver you can leave the PRA half untouched if
>you don't like the patent situation, and implement SPF
>Classic; as a sender you need to be careful your records
>will work for both.
>
>Is this state of affairs sufficiently satisfactory for the
>industry as a whole to move forward?

For myself, I would find it acceptable if there were an unburdened
alternative for 2822 (or at least a placeholder for it as a scope). Leave
it to the market to decide only works if there is a real choice. Currently,
if one wants to work with the 2822 header, there is no choice, only PRA. If
there were room for a free alternative in the same domain, then I think a
lot more people would be ready to move on.

Scott Kitterman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

In <20041026135228.GI6162@dumbo.pobox.com> Meng Weng Wong <mengwong@dumbo.pobox.com> writes:

> On Tue, Oct 26, 2004 at 05:47:01AM -0400, John Glube wrote:
> |
> | However, MS has not withdrawn its patent claim on the
> | concept of PRA operating in combination with CORE, which
> | forms the basis for the technology being licensed under
> | Microsoft's Royalty Free License which is not compatible
> | with the Open Standard Alliance model.
>
> Yes, this is correct. This seems like a novel situation,
> though. Now there are essentially two halves to Sender
> ID. As a receiver you can leave the PRA half untouched if
> you don't like the patent situation, and implement SPF
> Classic; as a sender you need to be careful your records
> will work for both.
>
> Is this state of affairs sufficiently satisfactory for the
> industry as a whole to move forward?

This is the situation as the last drafts of SenderID before the IETF
shut the MARID working group down. This is not new. The response to
this direction was underwhelming and was, in part, why the IETF shut
down MARID.

If it didn't get the necessary support last time, why do you think it
will this time?


I have *long* said that:

1) The PRA patent license is a deal killer and can not be accepted.

The Microsoft license prevents most mail servers on the internet
from easily deploying SenderID. This creates a wedge issue where
Microsoft can use its monopoly as granted by its patent to try and
take over the MTA market. I hate markets that aren't free.

2) The PRA is untested, in theory doesn't work well, and what little
practical experience has been gained so far shows that theory
matches practice.

This, however, is something I think the market will be able to deal
with. There is something called "reality" that won't go away, even
when a very powerful company says something that conflicts with it.


Now the thing that really puzzles me Meng is that just yesterday you
told me that you do *not* support the PRA. That you think the PRA is
a terrible idea. And yet, I see you advocating that domain owners
support the PRA. Why are you telling others to do something that you
don't support and thing is terrible?


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 09:21:37AM -0500, wayne wrote:
|
| Now the thing that really puzzles me Meng is that just yesterday you
| told me that you do *not* support the PRA. That you think the PRA is
| a terrible idea. And yet, I see you advocating that domain owners
| support the PRA. Why are you telling others to do something that you
| don't support and thing is terrible?

One-button mice are a terrible idea too, but they're part of
the environment, and if we're to be realistic, then we need
to react to them whether we like them or not. I'm not
advocating that domain owners support the PRA: domain owners
are asking what they'll need to do about the PRA, and I'm
telling them how to deal with it.

You can pretend that something you don't like doesn't exist,
you can deal with it, or you can fight it. I'm not going to
fight Microsoft on this one; it's something they want very
much to do and from where I stand it looks like they're
going to do it no matter who fights them on it.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Tue, Oct 26, 2004 at 10:30:34AM -0400, Meng Weng Wong wrote:
|
| One-button mice are a terrible idea too, but they're part of
| the environment, and if we're to be realistic, then we need
| to react to them whether we like them or not. I'm not
| advocating that domain owners support the PRA: domain owners
| are asking what they'll need to do about the PRA, and I'm
| telling them how to deal with it.

BTW, under Mac OS, if you have a one-button mouse, to get
the equivalent of a right click, you have to either
control-click, or hold down the button for a second or two.
Or you can go out and buy a three-button mouse from a third
party vendor.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

Jeremy Pullicino wrote:

> I understand that technically SPF and SenderID are
> practically the same

That's not the case, they are very different. Sender-ID
tries a hostile takeover, but it will fail, like MARID.

> The time has (finally) come for us to accept that SPF and
> SenderID were, are and will be the exact same thing.

If you have the time to support unhappy users losing their
inbound mail and threatening to sue you, go ahead and apply
PRA tests on v=spf1 policies. If you don't have this time
just wait until it hits the fan. If some of your users use
"their" 2822-From anywhere, not only in mails sent via your
relays, this won't take long.
Bye, Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com