Discussion:
Obstacles between us and the finish line
wayne
2004-07-01 05:39:15 UTC
Permalink
Deadlines for this working group are rapidly approaching. According
to Andy's recent post, we have about 2 weeks (until 07/18) to finish
things up.

In my (oh so very humble) opinion, I see the following obstacles in
the way:

1) Proposals must have solid I-Ds

2) Proposals must have working code

3) Proposals must have been tested on real world data

4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.

5) Proposals must not have gratuitous incompatibilities with an
installed base.


I have said from very early on that I think we may well need more than
one RFC to handle the various identities. To be quite honest, I don't
care if we have a dozen overlapping proposals, I think the market can
easily decide which are useful.

As such, I see the following proposals that may be considered:
SPF-classic, CSV, Sender-ID and Unified-SPF.

It appears to DMP, FSV, and Caller-ID are no longer being pushed by
anyone.


I'm going to go over all the proposals in a sec, but I think I should
make a few comments on the requirements.

1) solid I-Ds: Proposals must have been gone over with many eyes,
especially with developer's eyes when they are trying to implement the
proposal. I think it is far too late to do anything with a proposal
other than use it to implement code and make adjustments based on that
experience.

2) working code, and 3) testing, I think are pretty obvious.

4) IP licensing: I'm not dogmatic about the GPL or commercial
licenses, but there are significant MTAs and mail filters that fall
under both kinds of licenses, and several others to boot. I think
that any proposal that has incompatible IP licensing needs to be
dropped.

5) Incompatibilities: Proposals such as SPF have a significant install
base and doing things like moving the location of the TXT records,
dropping macros, or using a different RR, etc. make no sense to me and
will likely run into a buzz saw with SPF adopters.



Ok, so how do the current proposals stack up?


**** SPF-classic ****

1) solid I-D: Yes
It was supposed to have been submitted as an experiemental RFC, but I
don't know the status.

2) working code: Yes
Lots of working code in fact. New announcements of commercial
products using SPF a couple of times a week.

3) Tested: Yes
It is being used to check millions of emails per day.

4) IP Licensing: No problems

5) gratuitous incompatibilities: None.


I think SPF-classic should certainly be *one* of the proposals put
forth by this working group.



**** CSV ****

1) solid I-D: pretty good
To the best of my knowledge, no one has tried to implement code based
on it, but it appears to have been well reviewed by a fair number of
people. I think there is time to get implementation experience if the
backers hurry.

2) working code: none

3) testing: none

4) IP Licensing: No problems

5) gratuitous incompatibilities: None.


I think that CSV could be one of the proposals, if its backers quickly
start creating working code and doing testing.



**** Sender-ID ****

1) solid I-D: No
I have looked again at the draft-ietf-marid-core-01.txt I-D, and
frankly, it is not even close to being in a state worth commenting on.
It is hugely incomplete and incompatible with SPF, which it tries to
be compatbile with. I can't see it becoming solid in the next couple
of weeks.

Heck, it still has the XML stuff in it and the changes from the -00
version are very minor. It appears that little work is being done on
this and it is unlikely to be ready.

The SUBMITTER I-D appears to be in better shape, but again, no one has
tried using the I-D to implement the spec, so there could be
significant errors.

2) working code: none
In particular, the PRA and SUBMITTER are both on paper only.

3) testing: none
I requested results of the PRA algorithm the first day that the
Caller-ID spec was proposed to this working group. I made a point of
raising the issue at the interim meeting. In the many months since
then, nothing has been forth coming. I am getting seriously worried
about this.

4) IP Licensing: problems
It appears that the Sender-ID's license is incompatible with the GPL.
This could, in theory, be fixed very quickly, but the issues of IP
disclosure and licensing problems has been known since before the
interim meeting and nothing has been done.

5) gratuitous incompatibilities: None.
In theory, the only incompatiblity is that it tries to use existing
SPF records for 2822 checks. Since SPF records were published with
the idea that they would be used for 2821.FROM and 2821.HELO, there
could be problems.

In practice, there are many incompatiblities with the current
Sender-ID spec and the SPF spec.


While Sender-ID appears to be the RFC-apparent for this WG, I have
very serious doubts that it will be in any shape to be advanced before
the deadlines. I am beginning to think this proposal should be
dropped as the backers of key parts appear to be moving way too
slowly.



**** Unified-SPF ****

1) solid I-D: fuzzy
As Dave Crocker pointed out in a message earlier today, there is no
Unified-SPF I-D. This needs to be fixed ASAP or this proposal must be
dropped. Fortunately, the differences between SPF-classic and
Unified-SPF are small enough that I think I-Ds could be written fairly
quickly and yet remain pretty solid.

2) working code: none

3) testing: none

4) IP Licensing: No problems

5) gratuitous incompatibilities: None.
The Unified-SPF proposal needs to make some changes to the SPF records
in order to support the various scopes that it tries to cover. This
can be solved several ways.


I think that Unified-SPF has a chance to be a solid proposal, but the
I-Ds need to be written and the changes to the SPF-classic code needs
to be tested.



**** DMP ****

Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway

1) solid I-D: Yes

2) working code: Yes

3) testing: Yes

4) IP Licensing: No problems

5) gratuitous incompatibilities: None.


I think that DMP is in far better shape than most of the other
proposals that appear to be much more likely to advanced by this
working group. *boggle*


Right now, I would say that SPF-classic and DMP are the only proposals
that are ready for RFC consideration. For backers of other proposals:
you have two weeks to finish.


-wayne
Gordon Fecyk
2004-07-01 06:03:13 UTC
Permalink
Post by wayne
Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway
1) solid I-D: Yes
2) working code: Yes
3) testing: Yes
4) IP Licensing: No problems
5) gratuitous incompatibilities: None.
I think that DMP is in far better shape than most of the other
proposals that appear to be much more likely to advanced by this
working group. *boggle*
In some anti-spam mailing lists this would warrant a "C&C" warning. :-)

But thanks for bringing this up. I was thinking about adding support for
marid-submitter and portions of marid-core (notably the RFC2822 Resent-From:
header) as I've asked about earlier. The end result will be fewer lookups
per message - a minimum of one and maximum of two, compared to a maximum of
*four* - thanks to the information provided through the above drafts.

How about I throw that on the table and see who pokes at it?
--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting-***@public.gmane.org>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>
Tony Finch
2004-07-01 11:59:22 UTC
Permalink
Post by wayne
Ok, so how do the current proposals stack up?
**** SPF-classic ****
5) gratuitous incompatibilities: None.
Incorrect. It breaks alias-forwarding.
Post by wayne
**** CSV ****
5) gratuitous incompatibilities: None.
Correct.
Post by wayne
**** Sender-ID ****
5) gratuitous incompatibilities: None.
Incorrect. See http://www.imc.org/ietf-mxcomp/mail-archive/msg02419.html
Post by wayne
**** Unified-SPF ****
5) gratuitous incompatibilities: None.
Incorrect for the reasons stated for SPF-classic and Sender-ID above.
Post by wayne
**** DMP ****
1) solid I-D: Yes
There appears to be a security problem caused by the way a failed MAIL
FROM check may fall back to an EHLO check, allowing unintended forgery.
Alternatively this is a source of troublesome interoperability problems
if some servers fall back to EHLO and some don't.
Post by wayne
5) gratuitous incompatibilities: None.
Wildcard MX records.

Tony.
--
f.a.n.finch <dot-***@public.gmane.org> http://dotat.at/
FAIR ISLE: WESTERLY 4 OR 5 BECOMING VARIABLE 3. OCCASIONAL RAIN. MODERATE WITH
FOG PATCHES.
Gordon Fecyk
2004-07-01 15:08:09 UTC
Permalink
Post by Tony Finch
Post by wayne
**** DMP ****
1) solid I-D: Yes
There appears to be a security problem caused by the way a failed MAIL
FROM check may fall back to an EHLO check, allowing
unintended forgery.
Alternatively this is a source of troublesome
interoperability problems
if some servers fall back to EHLO and some don't.
Would be eliminated if the EHLO fallback were replaced with checking
Resent-From / SUBMITTER. A domain that wants to forward mail should start
using these, which is the case with marid-core anyway.

That alone wouldn't fix null reverse paths unless EHLO were used exclusively
for those, or the extra information in Resent-From / SUBMITTER were provided.
Post by Tony Finch
Post by wayne
5) gratuitous incompatibilities: None.
Wildcard MX records.
Use an identical wildcard DMP record alongside it, such as:

$ORIGIN example.com.
@ IN MX mailhost1
* IN MX mailhost1
* IN TXT "dmp="

That would at least prevent forgeries of undefined subdomains until you had
an actual host you wanted to send mail as (like user-I0GvoLgrCZOkmABc3PwzPQC/***@public.gmane.org), at
which point you'd create records for it or have the sending server provide
records via dynamic DNS update[1].

Doesn't everything tabled so far break when faced with a wildcard MX record
anyway?

[1] Someone told me providing records dynamically was a problem but never
provided an explanation.
--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting-***@public.gmane.org>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>
Tony Finch
2004-07-01 15:19:54 UTC
Permalink
[problems] Would be eliminated if the EHLO fallback were replaced with
checking Resent-From / SUBMITTER.
This is broken for other reasons which I have explained already.
Doesn't everything tabled so far break when faced with a wildcard MX record
anyway?
SPF-classic and CSV do not.

Tony.
--
f.a.n.finch <dot-***@public.gmane.org> http://dotat.at/
ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: WEST 4 OR 5
BACKING SOUTHWEST AND INCREASING 5 OR 6. SCATTERED SHOWERS BECOMING MORE
FREQUENT LATER. GOOD DECREASING MODERATE AT TIMES IN SHOWERS. MODERATE
BUILDING LOCALLY ROUGH.
wayne
2004-07-13 03:18:59 UTC
Permalink
About two weeks ago, I posted the following summary of things I see as
major obstacles between us and an acceptable standard-track RFC.
Post by wayne
Deadlines for this working group are rapidly approaching. According
to Andy's recent post, we have about 2 weeks (until 07/18) to finish
things up.
In my (oh so very humble) opinion, I see the following obstacles in
1) Proposals must have solid I-Ds
I is my understanding that the design-team meeting last Friday made
significant progress on the RFCs. In particular, it is my
understanding that much of marid-core has been replaced by a chopped
up version of the SPF-classic spec, which I personally think is likely
to be a huge improvement.

That said, such significant changes only a week before the IETF-60 I-D
submission deadline does not leave much time for real working group
review and changes/fixes. I am almost certain that I will have a
number of things that I would like see changed in the SenderID
"protocol" RFC in order to deal with issues such as DDoS potentials.
Post by wayne
2) Proposals must have working code
Now that XML has been eliminated, the SPF-classic
libraries/implementations can be used to check the PRA and no new code
really needs to be written. That is, except for the code to extract
the PRA. If the PRA RFC is going to be advanced by this working
group, those that think it is a good idea should create some working
code. Otherwise, I don't think we will reach a rough consensus as to
whether it is a useful RFC to introduce onto such an important part of
the Internet.
Post by wayne
3) Proposals must have been tested on real world data
Like 2), there is *still* zero published data on how effective the PRA
algorithm is on real world data. I know that it would create a false
positive on the only email account that I have forwarded to my main
email address. I know that it will break on many mailing lists. I
don't know much more than that.
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
Again, the PRA RFC has IPR claims. It is my understanding (IANAL)
that there is a very good chance that these license offered with the
PRA is incompatible with the GPL, and may have other problems. There
are significant MTAs out there (e.g. Postfix and Exim) along with spam
filters and MUAs that the current PRA license would prevent the
implementation of SenderID.

If, indeed, the PRA license is incompatible, I do not think we should
advance it as an RFC.
Post by wayne
5) Proposals must not have gratuitous incompatibilities with an
installed base.
It is my understanding that most of the problems between SPF-classic
(e.g. the installed base of SPF records) and Sender-ID have been
resolved.



If forced to hum today, I would have to say that SenderID is not ready
for submission as a standard-track RFC. We don't have much time to
fix things before IETF-60. It is my gut feel that we will not be able
to do a working group last call until after IETF-60, pushing the whole
schedule back by several weeks or a month.


-wayne
Chuck Mead
2004-07-13 18:28:51 UTC
Permalink
wayne wrote:

| Again, the PRA RFC has IPR claims. It is my understanding (IANAL)
| that there is a very good chance that these license offered with the
| PRA is incompatible with the GPL, and may have other problems. There
| are significant MTAs out there (e.g. Postfix and Exim) along with spam
| filters and MUAs that the current PRA license would prevent the
| implementation of SenderID.
|
| If, indeed, the PRA license is incompatible, I do not think we should
| advance it as an RFC.

Licenses which limit a technology make the supporting RFC a waste of
time. I won't use it... nor will I support it's use if there are
artificial limits created by licensing.

|>5) Proposals must not have gratuitous incompatibilities with an
|> installed base.
|
|
| It is my understanding that most of the problems between SPF-classic
| (e.g. the installed base of SPF records) and Sender-ID have been
| resolved.
|
|
|
| If forced to hum today, I would have to say that SenderID is not ready
| for submission as a standard-track RFC. We don't have much time to
| fix things before IETF-60. It is my gut feel that we will not be able
| to do a working group last call until after IETF-60, pushing the whole
| schedule back by several weeks or a month.

I usually don't give a single ditto as it's not typically useful but in
this case I think that would be the wrong approach so... like a clarion
bell let me say as clearly as possible... ME TOO!

NB. Let's get on with it! Shall we?

- --
Chuck Mead
csm-***@public.gmane.org
Chief Tech @ http://moongroup.com - http://anirononline.com
wayne
2004-09-03 01:13:17 UTC
Permalink
Back on July 1, I posted a message with the subject "Obstacles between
us and the finish line". I posted an updated to it two weeks later.
I decided to go back and post another updated.

The first two messages message can be found here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg02651.html
Post by wayne
Deadlines for this working group are rapidly approaching. According
to Andy's recent post, we have about 2 weeks (until 07/18) to finish
things up.
For those who don't remember, 7/18 was the first deadline for MS to
fix the license.
Post by wayne
In my (oh so very humble) opinion, I see the following obstacles in
1) Proposals must have solid I-Ds
2) Proposals must have working code
3) Proposals must have been tested on real world data
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
5) Proposals must not have gratuitous incompatibilities with an
installed base.
I have said from very early on that I think we may well need more than
one RFC to handle the various identities. To be quite honest, I don't
care if we have a dozen overlapping proposals, I think the market can
easily decide which are useful.
SPF-classic, CSV, Sender-ID and Unified-SPF.
It appears to DMP, FSV, and Caller-ID are no longer being pushed by
anyone.
I'm going to go over all the proposals in a sec, but I think I should
make a few comments on the requirements.
1) solid I-Ds: Proposals must have been gone over with many eyes,
especially with developer's eyes when they are trying to implement the
proposal. I think it is far too late to do anything with a proposal
other than use it to implement code and make adjustments based on that
experience.
2) working code, and 3) testing, I think are pretty obvious.
4) IP licensing: I'm not dogmatic about the GPL or commercial
licenses, but there are significant MTAs and mail filters that fall
under both kinds of licenses, and several others to boot. I think
that any proposal that has incompatible IP licensing needs to be
dropped.
Sadly, in response to this post back in July, Ted Hardie (the IETF
Area Director for this WG), told us to stop worry about IP licensing
issues. I believe the mess we are in right now is a direct result of
this. Instead of getting the IP licensing issue resolved *much*
earlier on, we now have a crisis and a no-win situation.
Post by wayne
5) Incompatibilities: Proposals such as SPF have a significant install
base and doing things like moving the location of the TXT records,
dropping macros, or using a different RR, etc. make no sense to me and
will likely run into a buzz saw with SPF adopters.
Ok, so how do the current proposals stack up?
**** SPF-classic ****
1) solid I-D: Yes
It was supposed to have been submitted as an experiemental RFC, but I
don't know the status.
2) working code: Yes
Lots of working code in fact. New announcements of commercial
products using SPF a couple of times a week.
3) Tested: Yes
It is being used to check millions of emails per day.
4) IP Licensing: No problems
5) gratuitous incompatibilities: None.
I think SPF-classic should certainly be *one* of the proposals put
forth by this working group.
I think it is really too bad that SPF-classic was not *one* of the
proposals. It would have made our live much easier right now.
Post by wayne
**** CSV ****
1) solid I-D: pretty good
To the best of my knowledge, no one has tried to implement code based
on it, but it appears to have been well reviewed by a fair number of
people. I think there is time to get implementation experience if the
backers hurry.
Better I-Ds have been put forward, but I know of no change on the
implementation experience part.
Post by wayne
2) working code: none
3) testing: none
4) IP Licensing: No problems
5) gratuitous incompatibilities: None.
I think that CSV could be one of the proposals, if its backers quickly
start creating working code and doing testing.
I think it is kind of funny that CSV has made it on the WG TODO list,
but neither SPF-classic nor Unified-SPF did.
Post by wayne
**** Sender-ID ****
1) solid I-D: No
I have looked again at the draft-ietf-marid-core-01.txt I-D, and
frankly, it is not even close to being in a state worth commenting on.
It is hugely incomplete and incompatible with SPF, which it tries to
be compatbile with. I can't see it becoming solid in the next couple
of weeks.
The SenderID I-Ds have been much improved since July, but I think
there are still a lot of rough edges.
Post by wayne
2) working code: none
In particular, the PRA and SUBMITTER are both on paper only.
There is now some working code for the PRA, but none for SUBMITTER.
Post by wayne
3) testing: none
I requested results of the PRA algorithm the first day that the
Caller-ID spec was proposed to this working group. I made a point of
raising the issue at the interim meeting. In the many months since
then, nothing has been forth coming. I am getting seriously worried
about this.
Ok, a little small-scale testing has been done on the PRA now, but the
results have only shown that it doesn't work very well.
Post by wayne
4) IP Licensing: problems
It appears that the Sender-ID's license is incompatible with the GPL.
This could, in theory, be fixed very quickly, but the issues of IP
disclosure and licensing problems has been known since before the
interim meeting and nothing has been done.
Woah. Here we are two months later and *STILL* nothing has been done.
Post by wayne
5) gratuitous incompatibilities: None.
In theory, the only incompatiblity is that it tries to use existing
SPF records for 2822 checks. Since SPF records were published with
the idea that they would be used for 2821.FROM and 2821.HELO, there
could be problems.
Ah, gratuitous incompatibilities have been introduced with the change
of the version number.
Post by wayne
In practice, there are many incompatiblities with the current
Sender-ID spec and the SPF spec.
While Sender-ID appears to be the RFC-apparent for this WG, I have
very serious doubts that it will be in any shape to be advanced before
the deadlines. I am beginning to think this proposal should be
dropped as the backers of key parts appear to be moving way too
slowly.
Well, Sender-ID wasn't in shape to make the deadline of 7/18, so the
deadline was moved.
Post by wayne
**** Unified-SPF ****
1) solid I-D: fuzzy
As Dave Crocker pointed out in a message earlier today, there is no
Unified-SPF I-D. This needs to be fixed ASAP or this proposal must be
dropped. Fortunately, the differences between SPF-classic and
Unified-SPF are small enough that I think I-Ds could be written fairly
quickly and yet remain pretty solid.
2) working code: none
3) testing: none
4) IP Licensing: No problems
5) gratuitous incompatibilities: None.
The Unified-SPF proposal needs to make some changes to the SPF records
in order to support the various scopes that it tries to cover. This
can be solved several ways.
I think that Unified-SPF has a chance to be a solid proposal, but the
I-Ds need to be written and the changes to the SPF-classic code needs
to be tested.
**** DMP ****
Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway
1) solid I-D: Yes
2) working code: Yes
3) testing: Yes
4) IP Licensing: No problems
5) gratuitous incompatibilities: None.
I think that DMP is in far better shape than most of the other
proposals that appear to be much more likely to advanced by this
working group. *boggle*
Right now, I would say that SPF-classic and DMP are the only proposals
you have two weeks to finish.
I wish I could say we have come a long way, but I don't think we have.



-wayne
Douglas Otis
2004-09-03 02:50:13 UTC
Permalink
Post by wayne
Post by wayne
**** CSV ****
1) solid I-D: pretty good
To the best of my knowledge, no one has tried to implement code based
on it, but it appears to have been well reviewed by a fair number of
people. I think there is time to get implementation experience if the
backers hurry.
Better I-Ds have been put forward, but I know of no change on the
implementation experience part.
Post by wayne
2) working code: none
3) testing: none
Not extensive, but more than none.
Post by wayne
Post by wayne
4) IP Licensing: No problems
5) gratuitous incompatibilities: None.
I think that CSV could be one of the proposals, if its backers quickly
start creating working code and doing testing.
I think it is kind of funny that CSV has made it on the WG TODO list,
but neither SPF-classic nor Unified-SPF did.
Looking to the next step, CSV offers an extremely simple extension to
RFC2821 for authenticating the EHLO domain. I see this as highly
important for reputation services, as identities obtained from either
Sender-ID or SPF are not suitable for basing reputation assertions
without running considerable risk when making assumptions of the
integrity of the mail channel.

Once CSV is in place, to implement something extremely similar to SPF or
Sender-ID becomes just a trivial name list created using PTR records
much like DNA. I was hoping to get some feedback before offering code.
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

I would not expect many to be satisfied with just an EHLO check.

-Doug
Graham Murray
2004-09-03 05:56:48 UTC
Permalink
Post by Douglas Otis
Once CSV is in place, to implement something extremely similar to SPF or
Sender-ID becomes just a trivial name list created using PTR records
much like DNA.
Unfortunately this is not quite as trivial as it seems. I believe that
PTR records are not the easiest records for the domain owner
(especially the owner of small domains) to have control over.
Douglas Otis
2004-09-03 21:38:45 UTC
Permalink
Post by Graham Murray
Post by Douglas Otis
Once CSV is in place, to implement something extremely similar to SPF or
Sender-ID becomes just a trivial name list created using PTR records
much like DNA.
Unfortunately this is not quite as trivial as it seems. I believe that
PTR records are not the easiest records for the domain owner
(especially the owner of small domains) to have control over.
Review the MPR draft at:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

This was not referring to a reverse DNS lookup. This record type is
being used in much the same manner as with the DNA draft but using the
_mp._smtp.xxxx.xxx sub-domain. This would be a forward lookup and
something easily within the control of the domain owner.

-Doug
Ted Hardie
2004-09-03 19:30:28 UTC
Permalink
Post by wayne
Post by wayne
4) IP licensing: I'm not dogmatic about the GPL or commercial
licenses, but there are significant MTAs and mail filters that fall
under both kinds of licenses, and several others to boot. I think
that any proposal that has incompatible IP licensing needs to be
dropped.
Sadly, in response to this post back in July, Ted Hardie (the IETF
Area Director for this WG), told us to stop worry about IP licensing
issues. I believe the mess we are in right now is a direct result of
this. Instead of getting the IP licensing issue resolved *much*
earlier on, we now have a crisis and a no-win situation.
There's no reference to which post of mine is meant, but I
assume http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html
is the one to which this refers.

That post did not say "stop worrying about the licensing issues",
it said "Discuss licensing in terms of the engineering decisions"
Post by wayne
Comments based solely on the licensing terms without regard to the engineering
choices they affect *do not speak to the question working groups need to
decide*. The sudden appearance of new working group participants
after postings inviting them to comment is welcome *if they contribute to
the engineering discussion*. But if you are here to comment on licensing
outside of the engineering context, you are wasting your electrons.
Several posters since that point have made very clear posts describing
the engineering choices and deployment mechanisms which would have to
change in the context of their reading of this license. I again point
to Eric's post as one example; there are others.

Saying "I don't like this" means nothing. Saying "I won't implement this"
or "I will deploy this" means something. Saying "To do this I would have
to implement an external filter mechanism in my MTA and distribute
the Sender-ID
filter separately under this license. The cost of that external filter
mechanism development plus the filter development isn't worth
the spam reduction costs in my environment. If someone contributed the code
for the external filter mechanism, however, I would be willing to work
on code efficiency and provide a pointer to an external filter" gives
a lot more for the group to work with.

Ted Hardie
Sam Varshavchik
2004-09-03 23:09:34 UTC
Permalink
Post by Ted Hardie
That post did not say "stop worrying about the licensing issues",
it said "Discuss licensing in terms of the engineering decisions"
Post by wayne
Comments based solely on the licensing terms without regard to the engineering
choices they affect *do not speak to the question working groups need to
decide*. The sudden appearance of new working group participants
after postings inviting them to comment is welcome *if they contribute to
the engineering discussion*. But if you are here to comment on licensing
outside of the engineering context, you are wasting your electrons.
Several posters since that point have made very clear posts describing
the engineering choices and deployment mechanisms which would have to
change in the context of their reading of this license. I again point
to Eric's post as one example; there are others.
Saying "I don't like this" means nothing. Saying "I won't implement this"
or "I will deploy this" means something.
Right. I'm afraid that this licensing issue has a major engineering impact.
Engineering as in: well, this licensing issue will prevent any engineering
from occuring in the first place.
wayne
2004-09-06 06:12:42 UTC
Permalink
Post by Ted Hardie
Post by wayne
Post by wayne
4) IP licensing: I'm not dogmatic about the GPL or commercial
licenses, but there are significant MTAs and mail filters that fall
under both kinds of licenses, and several others to boot. I think
that any proposal that has incompatible IP licensing needs to be
dropped.
Sadly, in response to this post back in July, Ted Hardie (the IETF
Area Director for this WG), told us to stop worry about IP licensing
issues. I believe the mess we are in right now is a direct result of
this. Instead of getting the IP licensing issue resolved *much*
earlier on, we now have a crisis and a no-win situation.
There's no reference to which post of mine is meant, but I
assume http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html
is the one to which this refers.
I'm sorry, I should have been clearer. I was referring to your
earlier post:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02660.html
Post by Ted Hardie
That post did not say "stop worrying about the licensing issues",
it said "Discuss licensing in terms of the engineering decisions"
In the post I was referring to, Shevek was describing the friction
caused by the use of new/unfamiliar licenses and how people often
picked familiar licenses instead.


In response you wrote, in part:

: I urge the working group to stop fixating on this and go back to reviewing
: and contributing to the specifications. This list is intended to focus on
: the engineering needed to get its charter done, and we have enough distractions
: without raising this spectre from its well-deserved grave.


In neither post did you take steps to get the IPR license issue
resolved. I'm afraid that the IPR issue have never been placed in the
grave and this spectre will continue to be raised as long as the
patent license terms conflict with so much of the existing email
infrastructure.


-wayne

Hallam-Baker, Phillip
2004-07-13 20:38:51 UTC
Permalink
Post by wayne
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
Again, the PRA RFC has IPR claims. It is my understanding (IANAL)
that there is a very good chance that these license offered with the
PRA is incompatible with the GPL, and may have other problems. There
are significant MTAs out there (e.g. Postfix and Exim) along with spam
filters and MUAs that the current PRA license would prevent the
implementation of SenderID.
If, indeed, the PRA license is incompatible, I do not think we should
advance it as an RFC.
I can't find any statement in draft-ietf-marid-submitter-01.txt that
would support this claim.

Note that to go forward the only requirement is code, and that is strictly
speaking only required to go to draft. There has never been a requirement
for open source code, let alone open source code that is compatible with
any given license.

It should be possible to write code to the spec and release it as public
domain (which is in my view the only real open source license). If you
can do that you can meet any other license term.
wayne
2004-07-14 00:08:02 UTC
Permalink
Post by Hallam-Baker, Phillip
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
Again, the PRA RFC has IPR claims. [...]
If, indeed, the PRA license is incompatible, I do not think we should
advance it as an RFC.
I can't find any statement in draft-ietf-marid-submitter-01.txt that
would support this claim.
Indeed, the submitter draft has nothing to support the claim that the
PRA has a license. It is the marid-core document, where the PRA
algorithm is described, that supports that claim.
Post by Hallam-Baker, Phillip
Note that to go forward the only requirement is code, and that is strictly
speaking only required to go to draft.
*sigh*

Let me quote RFC2026 yet again:

4.1.1 Proposed Standard

[snip]

Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.

The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.


Now, whether the IESG considers the SenderID to "have significant
operational impact on the Internet" or not, I can't say. What I can
say is what I think, and I think it does. (Note where I said "I
think" in the stuff you quoted above.)

In fact, I will go so far as to say that if there is no working code
and no testing by several independant organizations, I will argue
against advancing the SenderID proposal both during the WG last call
and during the IETF last call.

I realize that this would create a risk that the SenderID proposal
will not advance. However I consider that slightly more acceptable
than the risks associated with advancing a completely untested
proposal that has such a huge impact on such an important part of the
internet.

Mind you, I would *much* prefer to simply have a well tested RFC. I
would *much* prefer not having a messy "discussion" during the last
call periods.
Post by Hallam-Baker, Phillip
There has never been a requirement
for open source code, let alone open source code that is compatible with
any given license.
Nice red herring there.

I have never said that the code must be open source.

However RFC3668 says that a working group can consider the IPR issues
and that we should prefer technologies that do not have IPR problems.
RFC3668 is a good document, I recommend people read it.

Again, I think that any proposals that will prevent any significant
MTAs/spam filters from implementing this technology, whether the are
GPLed, commercial, or because the developer wears blue shoes, is
simply not acceptable.

The fact that the SenderID proposal has been allowed by the co-chairs
to advance this far without making the required RFC3668 disclosures is
troublesome. I really don't want to see the "discussions" during the
IETF last call that will happen if MARID advances a proposal that is
incompatible with the GPL.

If these IPR issues can't be resolved soon, I suggest that this
working group start considering other technologies that do not have
such problems.
Post by Hallam-Baker, Phillip
It should be possible to write code to the spec and release it as public
domain (which is in my view the only real open source license). If you
can do that you can meet any other license term.
I agree, it *should* possible, but the SenderID requires a license
from MicroSoft.



We have already had enough messy "discussions" here. Let's not repeat
the fun that was had with RSA. For people who like the SenderID
proposal, I highly recommend taking the time to address these
concerns.



-wayne
Gordon Fecyk
2004-07-14 04:08:37 UTC
Permalink
Post by wayne
Post by wayne
3) Proposals must have been tested on real world data
Like 2), there is *still* zero published data on how effective the PRA
algorithm is on real world data. I know that it would create a false
positive on the only email account that I have forwarded to my main
email address. I know that it will break on many mailing lists. I
don't know much more than that.
How about trying the information I was lent by the IMS Users mailing list?
There's over a year and a half of real world data on real and fake sender
domains, HELO identities, message sizes, IP addresses and so on. I'll bet
others can come up with similar logs.

Sure there isn't any DOR/Submitter information or headers or whatever. Some
of this could be synthesized for the purposes of testing, like setting some
bogus rule like, "if [host] has [domain] in part of its name, treat it like
[something]." It would be enough to do inital testing before putting it on a
live server.

I'll yank out the Access database and leave the raw plain text log in a
separate archive. I can provide separate domain and host information in a
different archive if it's difficult to separate it all out.

http://www.pan-am.ca/smtp.zip

In addition, the Win2K event sink shell I've asked to have coded up is being
worked on. The event sink itself will call an external library, which
actually implements MARID.
--
PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting-***@public.gmane.org>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>
Shevek
2004-07-14 16:43:57 UTC
Permalink
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
The requirement to even THINK about licensing terms when one is
implementing a "standard" internet protocol is almost unimaginable. The
IETF is supposed to promote interoperability without precondition. The
introduction of any form of license in order to use a "standard" mail
protocol raises the possibility that certain parties will not be able to
participate fully on the internet for legal reasons.

There is no precedent for such an ugly situation, and I am strongly
opposed to creating it now.

It doesn't matter what the terms are or how open or simple they are.
Licensing terms should NOT exist for an IETF "standard" protocol.
Implementors are not lawyers, and generally have better things to do with
their time.

S.

Optional bootnote: A similar argument applies to the use of well-known
licenses for software. I believe that a large part of the reason for the
success of the GPL, BSD or Apache licenses is that the rights of the user
and developer are particularly well understood in those cases. It's
frequently simpler to pick a GPL'd package than to understand the license
of a (possibly better) package under a custom license.

The same applies here: we should be applying a standard and well
understood set of terms to any proposed protocol, and the "standard and
well understood" set of terms is "You can do what you like with it, and
are beholden unto nobody."

Anything else is an obstacle and will cause division.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Ted Hardie
2004-07-14 17:44:40 UTC
Permalink
Post by Shevek
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
The requirement to even THINK about licensing terms when one is
implementing a "standard" internet protocol is almost unimaginable.
<snip>
Post by Shevek
. I believe that a large part of the reason for the
success of the GPL, BSD or Apache licenses is that the rights of the user
and developer are particularly well understood in those cases. It's
frequently simpler to pick a GPL'd package than to understand the license
of a (possibly better) package under a custom license.
The GPL, BSD, and Apache licenses are just as much licenses
with terms to be followed as are commercial licenses with
RAND, royalty-free, or reciprocal terms. Asserting that
a working group should not THINK about licensing and then
recommending particular licenses is a contradiction.
More importantly, this general topic is not salient for this list.
The IPR mailing list
exists for discussion of the IETF's IPR policy, and general discussion
belongs there. Please see the archives before posting, however, as the topics
raised here have been discussed before.

The group can discuss specific IPR issues with proposals before
the working group, but please note that while the IPR forms request
that a new IPR statement be filed for each document, it is widely understood
that successor documents are covered by the statement relating to the original
version. Getting a new one in for each version is busywork, and
this working group has
no time for such busywork. Getting a final copy in before the
documents become
RFCs can be handled at the appropriate time, and I am recommend to the working
group that they let the chairs follow up with the editors and those
who have filed
early statements at that time.

For those of you not familiar with the IETF's IPR declaration site, it
is at http://www.ietf.org/ipr.html. The caller-id original
is covered in this document:

http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt

with the following licensing declaration:


b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to
All Implementers **
Check here if this commitment to license
is limited solely
to standards-track RFCs ___

I urge the working group to stop fixating on this and go back to reviewing
and contributing to the specifications. This list is intended to focus on
the engineering needed to get its charter done, and we have enough distractions
without raising this spectre from its well-deserved grave.

regards,
Ted Hardie
Shevek
2004-07-14 18:43:11 UTC
Permalink
Post by Ted Hardie
Post by Shevek
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
The requirement to even THINK about licensing terms when one is
implementing a "standard" internet protocol is almost unimaginable.
The GPL, BSD, and Apache licenses are just as much licenses
with terms to be followed as are commercial licenses with
RAND, royalty-free, or reciprocal terms. Asserting that
a working group should not THINK about licensing and then
recommending particular licenses is a contradiction.
I am sorry that you did not actually read my original mail. I will
rephrase the salient parts of it in the hope of better luck this time.

I request that any protocol standardised by the IETF be entirely free of
license restrictions in order that implementors clearly understand their
right to implement the protocol. I specifically oppose the adoption of
SenderID as a standard since it imposes licensing terms on the user.
Post by Ted Hardie
More importantly, this general topic is not salient for this list.
This is not a general topic. This is a specific opposition to SenderID.
SenderID has licensing terms which an implementor must spend time reading
and understanding before implementing, distributing or otherwise sneezing
on SenderID or implementations thereof.

If the implementors do not clearly understand their rights, RAND or
otherwise, then they are unlikely to implement, or implementation will be
divided. We only have to look at the three-dozen competing CDMA
specifications for an example of this.

At no point did I suggest an alternative license, and I do not do so now.
I propose and recommend the absence of any license or restriction
whatsoever on any eventual protocol.

S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
william(at)elan.net
2004-07-14 22:33:22 UTC
Permalink
The group can discuss specific IPR issues with proposals before the working
group, but please note that while the IPR forms request that a new IPR
statement be filed for each document, it is widely understood that
successor documents are covered by the statement relating to the original
version. Getting a new one in for each version is busywork, and this
working group has no time for such busywork. Getting a final copy in
before the documents become RFCs can be handled at the appropriate time,
and I am recommend to the working group that they let the chairs follow
up with the editors and those who have filed early statements at that time.
While I agree with you in general, I do believe in our case, new IPR
statement is appropriate. My undersnding is that before Microsoft claimed
IPR rights because of use of XML in DNS TXT records (or was it in dns in
general? I asked that question and was promised detailed answer during
MARID jabber session, but never got it, eventhough Microsoft people
present were directed to work on it). We're no longer considering
use of XML in DNS and will use original SPF syntax, so my understanding
based on previously expressed IPR claims that none should apply to now.
Perhaps I do not understand correctly and Microsoft had other IPR claims
that dod not concern XML, in that case, Microsoft should explain more
clearly and tell exactly what these IPR claims cover and that is why new
statement seems appropriate.
For those of you not familiar with the IETF's IPR declaration site, it
is at http://www.ietf.org/ipr.html. The caller-id original
http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt
I note that the section V(C) which from that document is which is supposed
to explain which parts of internet draft are covered by IPR is not filled
out by Microsoft nor was there patent# provided under section V(A).
--
William Leibzon
Elan Networks
william-0lLFuDs/***@public.gmane.org
Hector Santos
2004-07-14 17:53:52 UTC
Permalink
I second your concerns. This is completely disturbing. Not only do I think
the proposals are faulty, will incur a high degree of compatibility issues,
will translates to a high revamping and resign cost, I now have to worry
about fighting what would be prior art issues anyway?

No, there is got to be a better answer to all this. This is fast becoming a
"MICROSOFT" only solution and Bill Gates recent quote saying using security
as a "Strategic Competitive Advantage" might come back to bite him in the
anti-trust area.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



----- Original Message -----
From: "Shevek" <ietf-mxcomp-***@public.gmane.org>
To: "IETF MARID WG" <ietf-mxcomp-***@public.gmane.org>
Sent: Wednesday, July 14, 2004 12:43 PM
Subject: Re: Obstacles between us and the finish line
Post by Shevek
Post by wayne
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
The requirement to even THINK about licensing terms when one is
implementing a "standard" internet protocol is almost unimaginable. The
IETF is supposed to promote interoperability without precondition. The
introduction of any form of license in order to use a "standard" mail
protocol raises the possibility that certain parties will not be able to
participate fully on the internet for legal reasons.
There is no precedent for such an ugly situation, and I am strongly
opposed to creating it now.
It doesn't matter what the terms are or how open or simple they are.
Licensing terms should NOT exist for an IETF "standard" protocol.
Implementors are not lawyers, and generally have better things to do with
their time.
S.
Optional bootnote: A similar argument applies to the use of well-known
licenses for software. I believe that a large part of the reason for the
success of the GPL, BSD or Apache licenses is that the rights of the user
and developer are particularly well understood in those cases. It's
frequently simpler to pick a GPL'd package than to understand the license
of a (possibly better) package under a custom license.
The same applies here: we should be applying a standard and well
understood set of terms to any proposed protocol, and the "standard and
well understood" set of terms is "You can do what you like with it, and
are beholden unto nobody."
Anything else is an obstacle and will cause division.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Andrew Newton
2004-07-14 19:46:36 UTC
Permalink
Post by Hector Santos
No, there is got to be a better answer to all this. This is fast becoming a
"MICROSOFT" only solution and Bill Gates recent quote saying using security
as a "Strategic Competitive Advantage" might come back to bite him in the
anti-trust area.
I specifically stated earlier that discussion of hidden agendas and
similar topics is forbidden. This statement does not constitute
constructive technical discussion nor administrative discussion within
the bounds of the working group's chartered scope.

This is your first and last warning.

-andy
Hector Santos
2004-07-15 01:19:11 UTC
Permalink
Wonderful! Now I have to deal with IETF censorship issues because I
discussed critical concerns regarding MICROSOFT IPR issues in a flawed
MARID, directly or indirectly related, which will have an enormous cost
impact across the industry including with own company and customers
regardless of how small you may believe it is? It is no laughing matter and
I take all this very seriously.

Rather than threaten me with censorship, clearing the air with information,
as some have done, for everyone would be better progress.

Sincerely,

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

----- Original Message -----
From: "Andrew Newton" <andy-***@public.gmane.org>
To: "Hector Santos" <hsantos-***@public.gmane.org>
Cc: "IETF MARID WG" <ietf-mxcomp-***@public.gmane.org>
Sent: Wednesday, July 14, 2004 3:46 PM
Subject: Re: Obstacles between us and the finish line
Post by Andrew Newton
Post by Hector Santos
No, there is got to be a better answer to all this. This is fast becoming a
"MICROSOFT" only solution and Bill Gates recent quote saying using security
as a "Strategic Competitive Advantage" might come back to bite him in the
anti-trust area.
I specifically stated earlier that discussion of hidden agendas and
similar topics is forbidden. This statement does not constitute
constructive technical discussion nor administrative discussion within
the bounds of the working group's chartered scope.
This is your first and last warning.
-andy
Harry Katz
2004-07-14 19:04:07 UTC
Permalink
Post by Hector Santos
I second your concerns. This is completely disturbing. Not
only do I think the proposals are faulty, will incur a high
degree of compatibility issues, will translates to a high
revamping and resign cost, I now have to worry about
fighting what would be prior art issues anyway?
No, there is got to be a better answer to all this. This is
fast becoming a "MICROSOFT" only solution and Bill Gates
recent quote saying using security as a "Strategic
Competitive Advantage" might come back to bite him in the
anti-trust area.
First, please read Ted Hardie's posting about our IP filing with respect
to the original Caller ID specification from which Sender ID is derived.

Second, to suggest that this is becoming a Microsoft only solution is
outrageous, abusrd and without any basis in fact!

In reality we have been working in good faith within this group to
arrive at an Internet standard that the whole industry can support with
the objective of addressing a problem that we are all concerned about.
The current drafts, and the revisions we are now working on following
last week's design review, are dramatically different from our original
Caller ID proposal -- a fact that reflects our willingness to compromise
with others in order to arrive at a common solution.

If you cannot restrain yourself from gratuitous Microsoft-bashing, I
strongly suggest that you

A) Do it somewhere else so you won't be disturbing people who are trying
to accomnplish meaningful work, and

B) Get your facts right.
Chuck Mead
2004-07-14 21:41:42 UTC
Permalink
Bitten by the Reply-to! I sent this directly to Harry instead of the
list which was my intent.

Harry Katz wrote:
| On Wednesday, July 14, 2004 10:54 AM, Hector Santos wrote:
|
|
|>I second your concerns. This is completely disturbing. Not
|>only do I think the proposals are faulty, will incur a high
|>degree of compatibility issues, will translates to a high
|>revamping and resign cost, I now have to worry about
|>fighting what would be prior art issues anyway?
|>
|>No, there is got to be a better answer to all this. This is
|>fast becoming a "MICROSOFT" only solution and Bill Gates
|>recent quote saying using security as a "Strategic
|>Competitive Advantage" might come back to bite him in the
|>anti-trust area.
|>
|
|
| First, please read Ted Hardie's posting about our IP filing with respect
| to the original Caller ID specification from which Sender ID is derived.

Sender ID is derived only from Caller-ID? Gee... there's a concept...
Where did SPF come from then?

| Second, to suggest that this is becoming a Microsoft only solution is
| outrageous, abusrd and without any basis in fact!

For my part I don't claim that... I worry about it but I'm not making
the claim. The issue we've been talking about though is that the
Caller-ID spec and it's attendant RAND license is being mis-applied to
what is, essentially, SPF Classic. THAT is what we're talking about and
I don't think any amount of crying that we're wasting *YOUR* time and
effort worrying about it is going to shut those of us who care about it
as an issue *UP*!

| In reality we have been working in good faith within this group to
| arrive at an Internet standard that the whole industry can support with
| the objective of addressing a problem that we are all concerned about.
| The current drafts, and the revisions we are now working on following
| last week's design review, are dramatically different from our original
| Caller ID proposal -- a fact that reflects our willingness to compromise
| with others in order to arrive at a common solution.

'zactly... thus we need to change the point of reference for the license
as we are *NOT* talking about Caller-ID anymore. We are talking about
SPF as far as I can see and that's not under RAND or anything else so
far as licensing is concerned. Is it?

I suspect that if someone would simply clarify it we'd likely be
satisfied as I strongly believe what we've been discussing is *NOT*
Called-ID which, consequently, kicks the CID RAND restriction to the
curb doesn't it?

<snippage>
wayne
2004-07-14 22:44:48 UTC
Permalink
(Burning my third (and last) post for the day...)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bitten by the Reply-to! I sent this directly to Harry instead of the
list which was my intent.
|
|
|>I second your concerns. This is completely disturbing. Not
|>only do I think the proposals are faulty, will incur a high
|>degree of compatibility issues, will translates to a high
|>revamping and resign cost, I now have to worry about
|>fighting what would be prior art issues anyway?
|>
|>No, there is got to be a better answer to all this. This is
|>fast becoming a "MICROSOFT" only solution and Bill Gates
|>recent quote saying using security as a "Strategic
|>Competitive Advantage" might come back to bite him in the
|>anti-trust area.
|>
|
|
| First, please read Ted Hardie's posting about our IP filing with respect
| to the original Caller ID specification from which Sender ID is derived.
Sender ID is derived only from Caller-ID? Gee... there's a concept...
Where did SPF come from then?
Sender-ID is a merger of SPf and Caller-ID, therefore Sender-ID is
dirived from both. It also has news stuff, like the SUBMITTER ESMTP
idea, thrown in.
| Second, to suggest that this is becoming a Microsoft only solution is
| outrageous, abusrd and without any basis in fact!
For my part I don't claim that...
For my part I don't claim that either. I am concerned that some
important MTAs/Spamfilters may be locked out of implementing
Sender-ID.
I suspect that if someone would simply clarify it we'd likely be
satisfied ....
Yes, I think this is the point...
... as I strongly believe what we've been discussing is *NOT*
Called-ID which, consequently, kicks the CID RAND restriction to the
curb doesn't it?
... but, as I mention above, the Caller-ID RAND/Z license still
applies to Sender-ID.



-wayne
Michel Bouissou
2004-07-14 23:19:44 UTC
Permalink
Post by Shevek
I request that any protocol standardised by the IETF be entirely free of
license restrictions in order that implementors clearly understand their
right to implement the protocol. I specifically oppose the adoption of
SenderID as a standard since it imposes licensing terms on the user.
I completely and entirely second Shevek's point.

Especially in a domain as critical for the entire Internet community as is
email exchange and delivery, I believe that IETF should never even consider
adopting as a standard any protocol which implementation could be encumbered
with any kind of patent or license restriction.

Such a standard must be public domain, free for anybody to comply with, use or
implement without any kind of licences or constraints from any entity, in any
kind of MTA or software itself governed by any kind of license, among which
Free Software licenses and the GPL.

License restrictions/obligations on such a protocol would quite probably
forbid it from being implemented and integrated into most if not all of the
mainstream open-source MTAs, which would make this new "standard" basically
useless.

So I request that either parties currently claiming IP rights about any aspect
of the protocol that will be part of the standard officially decide to put
these into the public domain, or that any aspect of the protocol that is
encumbered with known IPR claims should be removed from the future standard.

That's all.

- --
Michel Bouissou <michel-***@public.gmane.org> OpenPGP ID 0xDDE8AC6E
Andrew Newton
2004-07-15 00:24:29 UTC
Permalink
Post by Michel Bouissou
Such a standard must be public domain, free for anybody to comply with, use or
implement without any kind of licences or constraints from any entity, in any
kind of MTA or software itself governed by any kind of license, among which
Free Software licenses and the GPL.
Can you please explain the legal technicalities that lead you to
believe that the license for Caller-ID inhibits (a) development and/or
(b) distribution of open source software, and especially the GPL, under
such license?

-andy
wayne
2004-07-15 04:43:19 UTC
Permalink
(Ok, I know I said I wasn't going to post any more today, but it is
sufficiently close to midnight that I'm going to fudge it. Of course,
everything I say is a lie, so YMMV anyway. :-)
Post by Andrew Newton
Post by Michel Bouissou
Such a standard must be public domain, free for anybody to comply
with, use or implement without any kind of licences or constraints
from any entity, in any kind of MTA or software itself governed by
any kind of license, among which Free Software licenses and the
GPL.
Can you please explain the legal technicalities that lead you to
believe that the license for Caller-ID inhibits (a) development and/or
(b) distribution of open source software, and especially the GPL,
under such license?
IANAL. It is my understanding that several lawyers from the OSS
community (the FSF and OSI) are working with lawyers from MS, but I do
not know what has resulted from those discussions.

I have every reason to believe that folks like Harry, Jim and Bob have
the best of intentions to try and get a license that is acceptable to
all parties. Unfortunately, we all know what road is paved with good
intentions. The hell I want to avoid is having this WG end up with an
RFC that can not be easily uses by parts of the SMTP community, in
this case, open source MTAs/spamfilters.


My layman reading of the Caller-ID license raises the following
issues:

1) In Section 2.1, the license granted by MS is nontransferable and
non-sublicensable. So, it is my understanding that if I create a
hunk of software that implements SenderID, I must license it. Now,
if I upload this hunk of code to sourceforge and source forge
starts to distribute it, do they have to go get a license also?
What about all the linux/*BSD distributions, will each of them have
to obtain a license if they bundle my code? Does each ftp server
that mirrors one of these distribution have to get a license?

These kinds of issues are not as much of a problem for commercial
products since there would be contracts and such saying that these
folks are acting as my agent and that these other distributers
aren't creating a new product. However, in the open-source world,
I would expect many of these distributers to change the code, fix
bugs, or add features.

2) In Section 2.2, the Caller-ID license requires *adding* a term to
the existing licenses. Sorry, but I don't think anyone is going to
want to change the BSD or GPL.

3) In Section 6.3, in order to obtain a license, I must either use
certified snail mail, or a fax machine to request a license. I
don't have a fax machine, so I'm stuck trying to send certified
mail and waiting for a reply. So, if you find a bug in my
open-source implementation of SenderID, you can't just fix it and
put a new version up on your ftp site, you have to go running
around getting licenses and wait until you get a response back from
MS.



This all gets back to what Shevek said: "Implementors are not lawyers,
and generally have better things to do with their time." The fact
that I have to dig through yet another new license that requires me to
modify a bog-standard open source license and do so without messing up
is a big burden.

Again, as Shevek said: "I believe that a large part of the reason for
the success of the GPL, BSD or Apache licenses is that the rights of
the user and developer are particularly well understood in those
cases. It's frequently simpler to pick a GPL'd package than to
understand the license of a (possibly better) package under a custom
license."



As RFC3668 says:

In general, IETF working groups prefer technologies with no known IPR
claims or, for technologies with claims against them, an offer of
royalty-free licensing. But IETF working groups have the discretion
to adopt technology with a commitment of fair and non-discriminatory
terms, or even with no licensing commitment, if they feel that this
technology is superior enough to alternatives with fewer IPR claims
or free licensing to outweigh the potential cost of the licenses.


I do not believe that the advantages of the PRA algorithm outweighs
the costs of licensing, or at least, not the current license.

The fact that the IETF generally prefers technology without IPR issues
is not just a philosophical position, it is also a practical one.
Given that SPF-classic can be freely implemented without any hassles,
the adoption of an RFC that is more burdensome runs a huge risk that
people will widely ignore the RFC and just use SPF-classic. Mind you,
there are people who will do this anyway because they don't feel the
PRA algorithm is as effect, but the licensing issue makes a snappy
justification for not going with the RFC.


The problems with the license need to be addressed before the last
call goes out for the drafts. (According to the schedule, that would
be this month.) If the problems can not be resolved quickly, and this
has dragged on for weeks, then I think the PRA needs to be dropped.
It can be dealt with later on when there is more time.


-wayne
Michel Bouissou
2004-07-15 08:58:58 UTC
Permalink
Post by Andrew Newton
Can you please explain the legal technicalities that lead you to
believe that the license for Caller-ID inhibits (a) development and/or
(b) distribution of open source software, and especially the GPL, under
such license?
As a preamble, please note that I am no lawyer, and a competent lawyer would
probably be necessary to understand all this better.

That said, in his message written today at 04:43:19 UTC, Wayne expressed my
own concerns very precisely, and I share all of the points that he made.

Assuming Microsoft will impose for Sender-ID (or any subpart of it) the
license that their webpage at
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx currently
points to, which actually is the license for Caller-ID gotten from their site
at
http://download.microsoft.com/download/6/0/a/60a02573-3c00-4ee1-856b-afa39c020a95/callerid_license.pdf ,
then this license states :

§ 2.1: That the license granted for "making, using [and] distributing object
code versions of Licensed Implementations", "only as incorporated into
Licensed Products" is "nontransferable, non-sublicenseable [and] personal".

§ 2.2 makes the same provisions for source code distribution, plus request
that the license under which the source code is distributed would include a
supplementary notice "and does not include any other terms that are
inconsistent with, or would prohibit [the said notice]"

§ 4.3 repeats this again

§ 6.3 states that, to benefit from this royalty-free license, somebody needs
to return a signed, written copy of the said license to MS either by fax or
snail-mail.


In my understanding, all these provisions prohibit anybody who wouldn't have
signed the MS license to redistribute a software implementing Sender-ID
either in object or source code in any way.

This would mean that any "Free Software" MTA or antispam incoporating
Sender-ID could not anymore be freely redistributed, either via FTP or
included into, let's says, Linux or *BSD distributions, without each
distributor having previously signed the MS license and sent it back by fax
or snail-mail.

If you consider the number of different softwares and modules that any Free
Software distribution usually includes, and the number or distributors and
FTP or mirror download sites that each of them has, it is simply not
imaginable that any "not-for profit" redistributor or contributor would have
to sign dozens of such licenses, so requiring such a license will certainly
prohibit any software including Sender-ID to be included into Free Software
distributions, or further modified, improved or completed by benevolent
individuals, and this would make any software including Send-ID to slip out
of the Free Software community.



Now let's take a look at Free Software licenses.

The General Public License (GPL Version 2) says :

<<
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
[...]

2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
[...]
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
[...]

3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above [...]
[...]

6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein. [...]

7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.
[...]
This makes clear that the license that Microsoft requires for Sender-ID is
incompatible with the GPL, and as such, prohibits incoporating Sender-ID in
any GPL MTA or antispam software.



Now let's take a look at "IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER", the
license that governs the very popular and widely used Postfix MTA :

<<
1. DEFINITIONS

"Contribution" means:
a) in the case of International Business Machines Corporation ("IBM"),
the Original Program, and
b) in the case of each Contributor,
i) changes to the Program, and
ii) additions to the Program;
where such changes and/or additions to the Program originate
from and are distributed by that particular Contributor.
A Contribution 'originates' from a Contributor if it was added
to the Program by such Contributor itself or anyone acting on
such Contributor's behalf.
[...]
2. GRANT OF RIGHTS

a) Subject to the terms of this Agreement, each Contributor hereby
grants Recipient a non-exclusive, worldwide, royalty-free copyright
license to reproduce, prepare derivative works of, publicly display,
publicly perform, distribute and sublicense the Contribution of such
Contributor, if any, and such derivative works, in source code and
object code form.

b) Subject to the terms of this Agreement, each Contributor hereby
grants Recipient a non-exclusive, worldwide, royalty-free patent
license under Licensed Patents to make, use, sell, offer to sell,
import and otherwise transfer the Contribution of such Contributor,
if any, in source code and object code form. This patent license
shall apply to the combination of the Contribution and the Program
if, at the time the Contribution is added by the Contributor, such
addition of the Contribution causes such combination to be covered
by the Licensed Patents. [...]

3. REQUIREMENTS
[...]
When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy of the
Program.
In my understanding, this prohibits as well the inclusion of Sender-ID into
Postfix and its further redistribution in source code form, as the MS
Caller-ID license would prohibit the Postfix source code including Sender-ID
to "be made available under this Agreement" any further.


I repeat that IMHO, any protocol to be defined as an IETF standard should be
public domain, free for any party to implement, distribute and use in any
kind of software, regardless to the license that currently governs the
concerned software.

The MS license clearly shows incompatible with this goal, which makes it
unacceptable for considering building a standard upon a protocol that is
encumbered with such a license.

If MS was ready to modify its licensing terms, and allow for anybody receiving
Sender-ID in any form to _automatically_ receive a perpertual, royalty-free
license to use it, implement it, redistribute it, build derivative works from
it, and incoporate it into other works without any changes to said other
works licenses, usage or redistribution rights, then things, of course, would
be different.
--
Michel Bouissou <michel-***@public.gmane.org> OpenPGP ID 0xDDE8AC6E
Harry Katz
2004-07-15 21:27:36 UTC
Permalink
On Wednesday, July 14, 2004 9:43 PM (close enough to midnight), wayne
Post by wayne
I have every reason to believe that folks like Harry, Jim and
Bob have the best of intentions to try and get a license that
is acceptable to all parties.
Thank you, Wayne.
Post by wayne
My layman reading of the Caller-ID license raises the following
1) In Section 2.1, the license granted by MS is nontransferable and
non-sublicensable. So, it is my understanding that if I create a
hunk of software that implements SenderID, I must license it. Now,
if I upload this hunk of code to sourceforge and source forge
starts to distribute it, do they have to go get a license also?
What about all the linux/*BSD distributions, will each of them have
to obtain a license if they bundle my code? Does each ftp server
that mirrors one of these distribution have to get a license?
These kinds of issues are not as much of a problem for commercial
products since there would be contracts and such saying that these
folks are acting as my agent and that these other distributers
aren't creating a new product. However, in the open-source world,
I would expect many of these distributers to change the code, fix
bugs, or add features.
2) In Section 2.2, the Caller-ID license requires *adding* a term to
the existing licenses. Sorry, but I don't think anyone is going to
want to change the BSD or GPL.
3) In Section 6.3, in order to obtain a license, I must either use
certified snail mail, or a fax machine to request a license. I
don't have a fax machine, so I'm stuck trying to send certified
mail and waiting for a reply. So, if you find a bug in my
open-source implementation of SenderID, you can't just fix it and
put a new version up on your ftp site, you have to go running
around getting licenses and wait until you get a response back from
MS.
These are good questions. I've added them to the list I'm working on
with our attorneys.
Loading...