Slashdot Mirror

It happened in 1998 when the assignment for port 465 as SMTPS was revoked.

I just reread your link. In it DJB explicitly advises against running authentication on port 25. In fact, for security reasons, he wrote two separate programs, qmail-smptd and ofmipd, to keep the tasks of relaying authenticated email and accepting mail for local delivery as removed from one another as possible.

He defends the idea of separating these two tasks, not only to separate ports but separate programs, on this thread on the IETF-SUBMIT mailing list.

So, yeah, his complaint against port 587 was simply that if you can't implement the SUBMIT standard correctly (which according to him noone can), you should use a different port then the one specified in that standard. The rest of the world doesn't care, because it sees all the various authentication methods (including SUBMIT) as extensions to SMTP, and not as a different protocol (OFMIP as DJB calls them collectively), and have no qualms running a standard (non-SUBMIT compliant) SMTP server on port 587.

Furthermore, the ITU---and telecomms in general---aren't exactly known for good, simple (cheap to implement from scratch) protocol design. They tend to produce overcomplicated beasts like OSI, GSM, and ASN.1.

Why anyone in-the-know would want to leave Internet protocols in the hands of the telecomms is a mystery to me.

> SPF is, supposedly, a solution to this but the penetration seems pretty low.

SPF is part of Microsoft's SenderID patent and its license is incompatible with the GPL, therefore I will personally never republish an SPF record again.

Microsoft and other big companies develop big patent portfoloes to protect themselves, and to use against competitors with even vaguely similar projects.

That's one theory, that the only patent trolls are these huge conglomerates. In reality, small predatory licensing companies without any products or interest in cross-licensing are going to start hurting the bigger players.

It's exactly why Sendmail rejected using Microsoft's patented "SenderID", as described by Eric Allman here.

Err, no. Are you thinking of Apache?

it's exactly why GPLv3 has all this complex and oddly writtten patent material

Microsoft distribute SFU which contains GPL code. All we have to do is resync against the Microsoft distribution to be freed from the constant threat of patent lawsuits on the stuff they're redistributing. The original SenderID license had similar patent language designed to shield Microsoft, unfortunately for them it was not sub-licensable and therefore unworkable.

I hope the Mono project can be re-licensed under GPLv3 to avoid repercussions from this sort of suit.

Really? I hope it dies a horrible death.

There are several forms of PKI (ie, SSL X.509 certs, PGP/GnuPG/OpenPGP keypairs) which can be used with email: see RFC's 1991, 2440, 2487. There's also some good links off the IETF's S/MIME page here: http://www.imc.org/ietf-smime/

These have been around for several years, but the uptake of TLS/SSL aware SMTP servers has been slow, and the adoption of signed/secure email has also been very slow. The first problem lies mostly with mail server admins, because setting up even self-signed certs is time-consuming and complex unless you do it regularly, but is more likely to make progress than convincing the majority of users to deal with PGP's "web of trust", keysigning parties, and so forth.

Some of what you write is debatable, but some isn't.

The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

Saying that is ignoring the facts. Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies, are a very particular problem because a very large (if not the larger) part of the e-mail server world runs on free software. Go read the ASF's and Debian's explanations, they certainly did do their homework.

Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way.

(To be explicit about my motives: I am the one who appealed to the IESG/IAB on behalf of the SPF project about the reuse of "v=spf1" records for the PRA algorithm in the Sender ID specification.)

You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.

We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

Again you are missing the facts. Quoting from my appeal to the IESG:

It is also worth noting that at the time the MARID WG was closed [in September 2004], the then-current Sender ID specification draft-ietf-marid-protocol-03 did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in [Microsoft's] individual submission draft-lyon-senderid-core-00 in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October, when they began generating only "v=spf1" records.

Read the appeal. It connects a lot of dots that many do not like to remember.

This weakness was first described at the CRYPTO conference in August, and a technical explanation of the exploit was public on Aug. 27, Open SSL issued its advisory and patch on Sept. 5 and the Netcraft article cited by ZDNet has been online since Sept. 7. So while this is a potentially problematic security issue, it's not brand new, has been patched by OpenSSL and quite a few vendors have issued patches as well.

If you are interested in the work on RSA signatures, check out this OpenPGP posting. The chances are that there are other RSA signature implementations out there that are vulnerable to this sort of subversion and it will be interesting to see what other products actually publish fixes and acknowledge the flaw.

Cheers,
Toby Haynes

This article is useful in that it gets people thinking about the problem. Now some clever person can come up with a proposed solution and post an article about it. That's how it works.

It's not like nobody's ever discussed these issues before. Or have they?

Well, just imagine how damn silly you must look

Indignation and personal attacks are indicative of a diminished capacity to reson. Lets leave them out of the conversation or it is over. If you have a beef with my information then attach my information as attacking me will show its hollow end.

As for the HTTP Authentication comment you are talking about HTTP authentication vs "role your own" in which I will defer you to this discussion as the problems with HTTP Authentication are so numbered that it would be redundant to spew them all out here

http://ask.metafilter.com/mefi/21446
http://www.imc.org/atom-protocol/mail-archive/msg0 4511.html

No one in the field actually uses Http Authentication. I mean who EBay? Amazon? E-Trade? Yahoo? Microsoft? So I don't see your point. They all roll their own many of them use built in system accounts (which is a whole other argument) and put a front end on it. I mean really no one has used HTTP Authentication in years.

Further, the IMC (Internet Mail Consortium) keeps a list of all the mail related RFC's, you'll find the list here.

Haydn.

Why use RSS for that when vCard and iCalendar specs already cover that and are implemented by many groupware suites out there. The RFCs cover from HTTP transport of calendar and contact data as well as other MIME enclosures... And it's a simple and elegant format, it's not XML based but it works! Why reinvent the well this time? more info on vCard and iCalendar at http://www.imc.org/pdi/

Good ole Pollard's page concerning spf is very rantish, true. But if you think that's bad, try having an exchange with him sometime.:0

However, that doesn't make him wrong. The primary criticism of spf lies in the "it's not an anti-spam measure, it's a reputation system" mantra on the one hand, coupled with "spf is a great anti-spam tool" on the other. There's something strange about this approach.

Again, I can continue to point folks to the marid archives http://www.imc.org/ietf-mxcomp/mail-archive/mail12 .html and ask them to read for themselves. But overall; for my 2cents, spf relies on dns to do things it isn't designed to do, in order to accomplish things I feel (and others) are better accomplished in other ways. A very short list begins with bringing MX and SMTP hosts up to full compliance with the published relevant rfcs and their bcp recomendations. That would be a better start, imho, than just jumping on spf.

As to the antiquated features, well, a lot of them are still very much in use, and still very valid. Agreed, hardly anyone still does uucp email anymore, and I dropped support for bang-path email when I moved to Postfix last year. Those 1 percenters are still real however, and the job of the postmaster is to see that the mail gets delivered, not dropped. And to take the extra effort if required.

There was a really nice presentation on this at MAAWG a couple of months back.

and btw, I will always criticise stuff that breaks things that are configured correctly and according to the published best current practices.

Also that rational was only one of many considerations for totally rejecting it.

There's a discussion about this very subject going on on the IMC's discussion list for OpenPGP. From reading the posts, particularly the ones by PGP's Jon Callas, I don't think that PGP has officially decided to implement this change just yet. (On the list, the thread titled "SHA-1 broken" is the one you will want to follow.)

But then, I could have missed something.

How does this affect Jabber, which also uses IDN?

Note that this was discussed three years ago on the IDN mailing list.

It's perfectly possible to build authentication on top of SMTP without introducing needless compatibility problems. What's more, it already exists! All that's needed is for people to start using it.

Now if it takes this long for people to consider using authentication at all (and apparently even longer for the Slashdot mods to get a clue), what in the bleep are people thinking to suggest SMTP could realistically be replaced overnight?

http://www.imc.org/ietf-mxcomp/mail-archive/msg051 35.html

The war, of course, is not over. The IETF (Ted, and maybe the former co-chairs?), Meng, and MS (Harry, Jim, Bob, et al) appear to have learned nothing from what has happened. They have done an end-run around the working group last call by closing down the working group, but they are still pushing ahead with the PRA under the current license. Apparently, they think that when the "individual" I-Ds are submitted to the IESG and there is an IETF-wide last-call, things will go better. I don't see it.

One definition of insanity is doing the same thing again and again and expecting different results. Under this definition, Ted, Meng, Harry, Jim, et al, are acting quite insane.

I see four choices:

1) Forget about getting a de-jure standard.

2) Drop the PRA.

3) Change the PRA license to be compatible with F/OSS MTAs.

4) Find one or more widely accepted alternative to the PRA that covers the 2822.From: identity so that people can reasonably choose between the PRA and the alternatives.

Ted, Meng, Harry, Jim et al: PLEASE! Wake up and smell the coffee! We need a anti-forgery system that protects the 2822.From: identity, we don't need another two-week blowup when the IESG last-call happens.

It appears that my predictions are coming true. Meng, MS and the IETF shut down the MARID WG so that they could more easily push the patent encumbered SenderID through. They no longer have to deal with a WG last call.

Expect more steps to happen after IETF-61 when the individual drafts will be "reviewed".

Well, if Google, Yahoo (who created the spec, and indicated that they would be using it shortly), and AOL (who says they will begin testing in Q1) all use DomainKeys, we probably have a de facto email authentication standard.

I would say it's a good thing.

PGP is dying.. (not to sound like the FreeBSD is dying troll though.. ;).
Have you heard about any PGP advancements during the last years?
Have a look at the S/MIME Working groups homepage..

The negative side of S/MIME is that it's so damn hard to get a certificate.. (that will hopefully change soon)

-K

PS.
JEP-027 is about OpenPGP, though the only clients that follows it that I'm aware of is PSI and Kopete.

> We do welcome any statements directly from AOL or any network
> operations group regarding their plans for Sender ID or CSV. However,
> we ask that they respect the fact that this is a discussion list and be
> prepared to answer any technical questions that may arise from their
> statements.
>
> -andy, MARID co-chair

We remain committed to sender identity technologies.

We intend to begin beta testing SPF on our inbound systems very soon (weeks
from now). SPF is low hanging fruit that will benefit AOL and many other
domains although it will not work for 100% of the mail we receive. But it
will work for >80% of the mail we receive and that is good enough for a
first strike.

We also believe that the best way to secure the 822 FROM address is a
content signing approach which is out of the scope of this working group. We
hope to see a new group formed to tackle the issues in this arena.
DomainKeys, IIM and TEOS are all reasonable technologies in this arena. We
are sure their will be more which is a good thing for a working group :-)

We remain committed to other IP based approaches and see a lot of benefit to
the "newer" CSV idea. AOL already gets >85% of our spam from other ISPs main
outbound MTAs. SPF, SenderID, and Domainkeys will not change that as this
mail also uses the legit domain of that local ISP in the 821/822 headers.
CSV and certain best practice documents (BCPs) shift the responsibility to
the sending organization for the mess they create through their insecure
networks and insecure practices (like lack of SMTP AUTH of any form, lack of
any outbound controls, inability to suspend accounts, insecure web servers,
etc).

-Carl

--
Carl Hutzler
Director, AntiSpam Operations
America Online Mail Operations
cdhutzler@aol.com
703.265.5521 work
703.915.6862 cell

To: IETF MARID WG
From: Andrew Newton
Subject: Work plan for Sender ID
Date: Mon, 13 Sep 2004 18:03:23 -0400

Due to the fact that we released statements in two separate messages,
there seems to be some confusion on how we intend this working group to
proceed on Sender ID.

First, the PRA document is not being dropped. Instead, we are
proceeding with a document set that includes a non-encumbered (as far
as we know) scope, "mailfrom", in addition to the "pra" scope. As we
stated before, the objection to PRA is based on questions of deployment
caused by incompatibilities with open source licenses. However, there
were also a significant number for responses from participants stating
that they had no such deployment issues.

Second, it does not make sense to discuss alternatives to PRA if those
alternatives may be reasonably inferred to be covered by the patent
application (though not necessarily the license) since this working
group does not wish to discount Microsoft's patent application. And
since we do not know the specific claims of the patent application,
construction of such an alternative would need to take into account a
few things we do know:
1. The patent application covers at least -core and -pra in
combination. There is no reason to think that Microsoft's application
is limited to the technology in these two drafts.
2. It does not cover MAIL FROM because this question has been
specifically asked of Microsoft.
3. The algorithm in -pra has changed through multiple revisions of
the draft(s).
This would seem to at least exclude any scopes that use 2822 headers to
identify the party most recently responsible for injecting the message.

We hope to have a schedule as soon as possible.

-andy

Insight into the current situation can be found in a post by Matt Sergeant (Spamassassin/messagelabs):

http://www.imc.org/ietf-mxcomp/mail-archive/msg040 45.html

I pressed [Craig Spietzle of Microsoft]: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft.

Yakov Shafranovich (the former chair of the IRTF's ASRG) did some digging for prior art and turned up quite a bit. One of the examples that he gave was fetchmail.

I just realized that another way to look at this is not that fetchmail is prior art, but that if the MS patent goes through, fetchmail will be infringing on MS's patent and you will need to get a license from MS to continue to distribute fetchmail.

Mind you, lawyers from places like the OSI, FSF and the Apache Software Foundation have found MS's SenderID license to be incompatbile with various F/OSS licenses, including the GPL. So, if you don't want to run the risk of MS sueing you, you will not only have to get a license from them, but you will need to change your license.

Yeah, there *is* a chance that the USPT might reject MS's license because of the prior art, but, gee, we both know what the chances of that happen are.

Messages of interest to you include:

http://www.imc.org/ietf-mxcomp/mail-archive/msg039 39.html http://www.imc.org/ietf-mxcomp/mail-archive/msg039 30.html

In <20040903064727.GE4436@thyrsus.com> "Eric S. Raymond" [snip] writes:

> wayne <wayne@midwestcs.com>:
>> Yakov Shafranovich (the former chair of the IRTF's ASRG) did some
>> digging for prior art [on PRA] and turned up quite a bit. One of the examples
>> that he gave was fetchmail.
>
> Oh, that *is* interesting. So why back down? Let's fight Microsoft on this.

Oh, I just realized. If MS's patent goes through, you (and all distributors of fetchmail) will not be able to get a SenderID license from Microsoft to keep you from risking being sued by MS.

Not only does fetchmail not implement all required aspects of SenderID (a requirement of the license), but fetchmail's use of header checking appears to be used for different purposes than implementing SenderID. MS's license only covers SenderID usage. You will have to negotiate directly with MS to see if they will permit you, and all users of fetchmail, to continue using the functionality that you have had for years.

I had missed interesting detail when I first read the following post by Matt Sergeant:

http://www.imc.org/ietf-mxcomp/mail-archive/msg040 45.html

I pressed [Craig Spietzle of Microsoft]: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft.

Yakov Shafranovich (the former chair of the IRTF's ASRG) did some digging for prior art and turned up quite a bit. One of the examples that he gave was fetchmail.

I just realized that another way to look at this is not that fetchmail is prior art, but that if the MS patent goes through, fetchmail will be infringing on MS's patent and you will need to get a license from MS to continue to distribute fetchmail.

Mind you, lawyers from places like the OSI, FSF and the Apache Software Foundation have found MS's SenderID license to be incompatbile with various F/OSS licenses, including the GPL. So, if you don't want to run the risk of MS sueing you, you will not only have to get a license from them, but you will need to change your license.

Yeah, there *is* a chance that the USPT might reject MS's license because of the prior art, but, gee, we both know what the chances of that happen are.

Messages of interest to you include:

http://www.imc.org/ietf-mxcomp/mail-archive/msg039 39.html http://www.imc.org/ietf-mxcomp/mail-archive/msg039 30.html

In <20040903064727.GE4436@thyrsus.com> "Eric S. Raymond" [snip] writes:

> wayne <wayne@midwestcs.com>:
>> Yakov Shafranovich (the former chair of the IRTF's ASRG) did some
>> digging for prior art [on PRA] and turned up quite a bit. One of the examples
>> that he gave was fetchmail.
>
> Oh, that *is* interesting. So why back down? Let's fight Microsoft on this.

Oh, I just realized. If MS's patent goes through, you (and all distributors of fetchmail) will not be able to get a SenderID license from Microsoft to keep you from risking being sued by MS.

Not only does fetchmail not implement all required aspects of SenderID (a requirement of the license), but fetchmail's use of header checking appears to be used for different purposes than implementing SenderID. MS's license only covers SenderID usage. You will have to negotiate directly with MS to see if they will permit you, and all users of fetchmail, to continue using the functionality that you have had for years.

I had missed interesting detail when I first read the following post by Matt Sergeant:

http://www.imc.org/ietf-mxcomp/mail-archive/msg040 45.html

I pressed [Craig Spietzle of Microsoft]: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft.

Yakov Shafranovich (the former chair of the IRTF's ASRG) did some digging for prior art and turned up quite a bit. One of the examples that he gave was fetchmail.

I just realized that another way to look at this is not that fetchmail is prior art, but that if the MS patent goes through, fetchmail will be infringing on MS's patent and you will need to get a license from MS to continue to distribute fetchmail.

Mind you, lawyers from places like the OSI, FSF and the Apache Software Foundation have found MS's SenderID license to be incompatbile with various F/OSS licenses, including the GPL. So, if you don't want to run the risk of MS sueing you, you will not only have to get a license from them, but you will need to change your license.

Yeah, there *is* a chance that the USPT might reject MS's license because of the prior art, but, gee, we both know what the chances of that happen are.

Messages of interest to you include:

http://www.imc.org/ietf-mxcomp/mail-archive/msg039 39.html http://www.imc.org/ietf-mxcomp/mail-archive/msg039 30.html

In <20040903064727.GE4436@thyrsus.com> "Eric S. Raymond" [snip] writes:

> wayne <wayne@midwestcs.com>:
>> Yakov Shafranovich (the former chair of the IRTF's ASRG) did some
>> digging for prior art [on PRA] and turned up quite a bit. One of the examples
>> that he gave was fetchmail.
>
> Oh, that *is* interesting. So why back down? Let's fight Microsoft on this.

Oh, I just realized. If MS's patent goes through, you (and all distributors of fetchmail) will not be able to get a SenderID license from Microsoft to keep you from risking being sued by MS.

Not only does fetchmail not implement all required aspects of SenderID (a requirement of the license), but fetchmail's use of header checking appears to be used for different purposes than implementing SenderID. MS's license only covers SenderID usage. You will have to negotiate directly with MS to see if they will permit you, and all users of fetchmail, to continue using the functionality that you have had for years.

I had missed interesting detail when I first read the following post by Matt Sergeant:

http://www.imc.org/ietf-mxcomp/mail-archive/msg040 45.html

I pressed [Craig Spietzle of Microsoft]: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft.

I came across this message on Exim-users where one of the core developers flatly rejects the license, and it also indicates the Sendmail folks feel the same. Courier has also rejected it in a similar manner.

Sender ID needs rapid adoption, and it won't get off the ground with rejection from all the major FOSS MTA's.

I believe MS knows it, but they appear to fail to understand that licensing means at least as much for FOSS developers as it does for them. They said that they would update their FAQ with a promise that they will never charge for Sender ID, but miss the point that that isn't enough for developers.

I think this is extremely interesting, because it is the first time MS and the FOSS community comes together over something like this, where everyone knows that we have to get a standard up working. We're seeing a clash of worldviews, but if MS steps down now, they will have learned a valuable lesson.

I pressed him: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft.

(emphasis added)

A few good articles on sender-ID controversy:

http://www.eweek.com/print_article/0,1761,a=134028 ,00.asp
http://www.circleid.com/article/730_0_1_0_C/
http://www.eweek.com/article2/0,1759,1639880,00.as p
http://www.newsforge.com/article.pl?sid=04/09/01/1 555212
http://trends.newsforge.com/14/04/08/26/1326244.sh tml?tid=137

Also, here are the opinions of Eben Moglen of FSF and Larry Rosen of OSI:
http://www.imc.org/ietf-mxcomp/mail-archive/msg036 78.html

RMS E-Mail to IETF MARID WG ML

All listen to the man!

Yes, the statements can be found here.

On the open source side, the sendmail MTA is routinely bundled into other larger systems, notably open source operating system releases such as Linux and BSD distributions as well as commercial closed-source systems such as Solaris and AIX. Bundlers would need to execute their own copy of the RFSIPL. Those systems are in turn sometimes incorporated into other products, which would seemingly require another layer of patent licenses, and so on down the tree. As a practical matter, this makes the decision to include sendmail with Sender ID into their release more problematic. This is obviously not desirable from our point of view.

And...

While these are pragmatic rather than legal reasons, our likely decision at Sendmail will be to distribute our Sender ID implementation as a separate package that is not required to run the sendmail MTA under a distinct (possibly modified) Sendmail Open Source license. Open source users will have the option of downloading and installing the Sender ID package should they want the additional functionality. Bundlers will be able to choose whether they want to include the Sender ID technology or not, but will still be able to use the base sendmail MTA without additional IPR issues.

vCard ?

From: Ted Hardie
Subject: Regarding the recent licensing thread
To: ietf-mxcomp@imc.org
Date: Mon, 19 Jul 2004 11:27:41 -0700

Some points on the recent licensing postings:

1) This discussion has been unprofessional in the extreme. Contributors to this working group have been accused of failing in a duty they did perform, and that is rude and unproductive. The Microsoft IPR filing related to callerid was posted with their first ID, which is exactly what is required. Those who have been waiting for such a statement either don't understand the process or have not been paying attention, and their acting offended about things now carries no weight. A refresh with the new name and some details on coverage is warranted for clarity before the documents go to the RFC editor, but that is a paper trail issue, not substantive.

2) The IETF is an engineering body, and it makes engineering decisions. It cares about licensing only as it affects the ability to implement and deploy a standard. Religious opinions on the sanctity of specific license texts belong elsewhere. The sudden appearance of this as a separate topic without reference to the engineering choices misses the point of how the IETF makes these calls: in the context of the engineering decisions. 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.

3) The IETF has published standards with defensive patents many times, and the use of a reciprocal/royalty free license is a common way for contributors to protect themselves from later claims while still encouraging the creation of an interoperable, open standard. Trying to persuade the working group that something is outside the norm when the IETF IPR page is full of contrary examples insults the intelligence of the group, as well as insulting the contributors who are providing a royalty free license.

4) Armchair lawyers often assume things about patents and licensing which aren't true. Get a real lawyer to read things you're concerned about and have them talk to the contributor's lawyers about things that concern you. The creation of a licensed "libipr" called by other applications may be all it takes to have licenses with severe restrictions co-exist with royalty free/reciprocal licenses; this isn't something you can assume one way or the other. You really have to have professionals check. And when you find things that concern you, be aware that this license isn't responsible for ways you may already have bound yourself; if you signed an agreement with HP Lovecraft that said "I will only acknowledge Chthulhu in my code", don't blame Microsoft for requiring an IPR notice. Take it up with the Elder Gods.

5) Generic rants about patents belong on your national I-hate-the-patent-office list. Rants about the IETF's standing decision *against* requiring a specific license or class of licenses belong on the IPR list, but are very likely to be redundant to arguments already made. Read the archives.

New drafts are now out, waiting for careful review. I urge the working group to review them carefully and to focus on how they can be interpreted, coded, and deployed. We have a lot of work to do.

Ted Hardie

A member of the working group mailing list already answered your question here

• It conflicts with existing, open projects with the same goal.
  So What? I think its great that there are multiple proposals out for the same goal, may the best one win. Or is there going to be a boycott-photoshop.org since Adobe is writing software that conflicts with GIMP?
• It is patent-license encumbered.
  Doesn't look to "encumbered" to me. Its free for anybody to use, even in GPL code, as long as you pass along the license agreement. Or wait, would that be considered "Viral licensing" like the GPL itself? :)
• It is not the de-facto standard
  WTF? Its not the standard - in other words, they are trying to innovate! We wouldn't want someone come up with a new way of doing things. Were these people around in 1994 saying "who needs HTTP/HTML, gopher/archie/wais is the de-facto standard".
  Also, SPF is quite far from being "the standard". It might have 10,000 hosts, but how many users send mail through those hosts? Face it, until aol/yahoo/hotmail pick something, it wont be the standard.
• It is not an RFC
  Read this article which points out that boycott-email-caller-id.org is biased, and wrong. That article links to this msg from microsoft where they say they are working on submitting it.
• It is more verbose
  I'm no expert on either of these formats, but it appears that hotmail is sending back a lot more data (unique IP addresses). Thats more a server-config issue for hotmail.com vs aol.com than any comment on the protocol. Obviously XML has more overhead, but this example is contrived. A real apples-to-apples comparison would be returning the exact same data in each format...
• This site is not affiliated with any anti-spam solution. How dare they even claim that? The site is so obviously shilling for SPF its rediculous.

After that, if your company server isn't able to send mail to anyone, you will update fast, I bet.

That's the thing. It won't happen, becuase nobody wants to take the first step. Just like IPv6, where the first major provider that changes gets to deal with every IPv6 bug in every piece of network equipment that is around. Thus, it's easier to keep using IPv4. Similiarly, nobody would change the mail servers because then they get to deal with all the problems inherent with doing this (when they would rather wait for someone else to deal with it).

Updating server software. Thats what admins are for. Should be possible to do in a year or so.

Just getting this through the IETF would take a year, assuming it wasn't insane. You are discussing a mandatory change to a widely used Internet standard. I don't know if you're aware of how this works, but it's not just "Hey! Let's do X" and it magically happens.

If you don't believe me, then go here, sign up to the SMTP WG list, and get SMTP changed. Then, if you like, you can come back and laugh at me and remind me how wrong I was.

There is: vCalendar.

The standards exist, but no one has written the server.
You can't really blame them since the Calendar Access Protocol (CAP) which is going to be the IMAP+SMTP of Calendaring, providing synchronous calendaring to clients is on it's 10th draft. Read this email if you have lost hope that the IETF would have calendaring anytime soon. Appearently draft 11 is coming soon and it will be the last one. So it looks like CAP will be finalized RSN. (Thank God, this thing was becoming like Duke Nukem Forever)

You could poke a stick at the OpenCap Server project and see if you get a response. But I haven't heard anything in months.

I don't know what's up with the Libical guys. The mail archive has been dead since December 16. Of course some of them are working on Free Association which is supposed to be a server and client. Since the mailing lists for libical seem dead I couldn't tell you what the status of CAP support currently is. My understanding was that they had been keeping up with the drafts, but since the 10th one was released about a month ago, I have no idea what the current status is.

Mozilla should be getting Calendaring in 1.4. IIRC, the calendaring uses libical. The College of Charleston computing dept has taken on enhancing the client (Go Cougars!). Hopefully they'll be putting CAP support in.

If anyone wants to know what it would take to write a calendar server and put an end to the Notes/Exchange duopoly in groupware, visit the Calendaring and Scheduling Working Group of the IETF. These are the guys that have brought you iCAL (RFC2445), iTIP (RFC2446), iMip (RFC2447), iCal Locating and LDAP (RFC2739) and the Guide to Internet Calendaring (RFC3283).

Read the iCalendar Guide then all the other documents at the site. Next go write the server. Then make sure Mozilla's Calendar client works with it, and email me so I can go replace exchange servers with it.

If you find a solution that does not use CAP, beat the authors with a ClueStick till they give in and write something that uses IETF protocols so we can interop with it.

Personally I'd really like to see the Cyrus IMAP server get a CAP piece put in. Combined with OpenLDAP and Mozilla as the client, it would be a Notes/Exchange killer.

While I'm sitting here making demands from the Open Source messaging community, why the hell doesn't Mozilla get SIEVE (RFC3028) support so we can have a standard for server-side email filtering rules, Cyrus supports it in the IMAP server. Oh, and I also want write support for LDAP address books in Mozilla.

To answer the original question, I think it's coming, slowly, but coming. Lord knows, I've only been waiting for 4 years or so.

I think James Clarke's RELAX NG and W3C XML Schema is the best description (if slightly biased ;--) of the relative strength of the 2 technologies. Note that James Clarke also just released a new version of Trang , a tool that does conversions between Relax NG, Schemas and DTDs.

>You'd piss away miore time than your bill is worth even trying to get them to acknowledge you.

I agree it would take time. That's the idea, they don't want to deal with piss-ant cases.

The process seems more than clear enough to me, and if they don't acknowledge you, then you have even more case to sue (you can sue the city court for refusing to apply the law). The process should be:

- Write the courthouse in Yahoo!'s state.
- Tell them you want to sue over a cross state unpaid bill.
- They write you, telling you the filing fee is $80.
- You send them the filing fee, they send you a mound of papers to fill out.
- You happily spend an hour or two reading and filling out forms.
- You return the forms to the court.
- You wait 6-12 months for a court date letter to appear. If you are lucky it is in your state. If not, it isn't. It can go either way.

There you go. But don't take my word for it, take the words of someone better informed about suing people out of state.

However, according to this lawyer, you may need to elevate it past small claims level to get anywhere if it is out of state. Again, just keep tallying up the bills until they reach the point where it becomes worth your while to sue in civil court ($1000 maybe?). I do not believe the federal court will be prohibitively priced assuming you represent yourself (it's such a cut and dried case, why shouldn't you?). And now if Yahoo! doesn't get their ass down to court, the judge will be _seriously_ pissed off.

You can find out much more information about suing in small claims court here.

I hope this helps.

Is there a standard PIM messaging format to interchange appointments, contacts, etc., between various apps?

Not that you [cw]ould (necessarily) use Jabber as a means of storing and propagating a profile, but it might be a more appropriate model than Napster (anyone can host a Jabber server in front of, or behind a firewall, and the server is a single point designated by the Jabber address, much like an e-mail address).

Just thinking out loud here, but what might be nice is if everyone said, "Okay, we'll all use the Mozilla bookmarks format and the vCalendar and vCard standards, and we'll devise an (XML?) indexing format (telling a client where to find all the various files with the respective information) and make them accessable via WebDAV." Now all you have to do is convince every major client out there to use WebDAV, the new indexing format, vCalendar, vCard and the Mozilla bookmarks format.

Wait a minute...that sounds like it may be a job for an LDAP directory (which one can always host oneself if one doesn't like the availabe service providers). Most mailers already have some ability to interact with an LDAP server. Are there any standards for putting address/calendar/bookmark info in there? I know that's probably not what it was designed to do, but really, does that information change that often to be ill-suited for LDAP?

Sorry...just ranting about ideas here.... My point is that I know there's enough standards and protocols out there to meet this need without too much development. I'm sure there's just too much differing ideas about how to do it, so it hasn't been done yet.

Korganizer's native format is vCalendar (was anyway). So it is quite likely that these things would be able to talk together. After all they are all internet standards (more about iCal/iCard).

maybe this will help:
(and yes it's blatant googled karma whoring)

icalendar mailing list page
IETF iicalendar working group site

remo

Untill there is a standard calendar protocol, and that protocol is supported by exchange, you won't be able to get rid of it.

What ever happened to iCalendar, sometimes known as vCalendar?

Aren't there any LDAP-based solutions or proposals?

This is NOT the first time that class action suits have been brought up, and I think it is VERY interesting, because some claim the law was only intended to give individual claimants the chance to get damages. Still, class action suits like this have been won before. Funny -- even fax.com
has been sued before!.

There's also the question of whether junk fax statutory damages can be appropriate for class action, although obviously this is only one perspective.

Sorry, tezza, but you're spouting absolute crap. The ICAP draft specifies that it is layered over BEEP (see http://www.imc.org/draft-ietf-calsch-cap ) and where you got that crap about IMAP i don't know.

The credentials used in a public key infrastructure (PKI) typically consist of a public/private key pair, a corresponding certificate or certificate chain and some trust or root certification authority information. They are usually stored on a desktop or laptop system as part of an application specific store. Currently, support for credential export/import is uneven and end users need to get too involved with the mechanics of creating and maintaining their PKI credentials.

Application specific stores also mean that users cannot easily use the same credential in multiple applications or on multiple devices. In effect, today, credentials aren't portable. PKIs that use hardware tokens (e.g., smart cards, PCMCIA cards) do allow for portability of the user's credentials, however, most systems do not use hardware tokens, but would benefit if similar portability features were available. Ideally, users would be able to use a common set of credentials with their desktop and laptop PCs, PDAs, cell phones, and other Internet-ready devices. Even where hardware tokens are used, there may also be substantial benefit derived from using credential portability protocols in support of management functions such as, for example, installation, token recovery (e.g. locked PIN), or token replacement.

part of the problem is that the IDEA algorithm is licensed technology from the Swiss company that owns the patent.

What PGP needs is a pluggable-encryption component, so that it could leverage something like AES