Slashdot Mirror

Your tracker is still 440'ing, so I have put up an alternative tracker. As I write this, I only have about 9% of the avi downloaded, so if someone else can seed the complete cormack-spam-xvid.avi file, I would greatly appreciate it.

Uh, your servers are supposed to only reply with *ONE* packet.

That said, I have also had a few people complain to me about my machine attacking them because they have configured their machine to use the NTP pool. Over the last 2 years, it has totalled around 3, so you must have had really bad luck.

Overall, I have been very happy with my involvement with the NTP pool. It has been working very well and I like being to help others out. I have also created a bunch of NTP monitoring scripts to help NTP pool members make sure things are running smoothly. These scripts confirm that being in the pool really doesn't generate that much traffic, so even people with cable modems/DSL (with static IP addresses) can easily participate.

AMEN!

As someone who has recent scars (SPF, MARID) from dealing with the IETF, it is clear to me that they are no longer an engineering organization, but rather a highly political one. No longer is there much concern about adopting patent encumbered technology into key Internet protocols (MS SenderID) like they used to object to things like the RSA patents.

Instead, the IESG is actively working to push through this patented technology by shutting down the MARID WG so that they can advance the SenderID proposal without any public review. More over, the IESG has declared that it is ok for the SenderID spec to re-use SPF records in incompatible ways, that the SPF RFC must be held back until MS is ready ("to be fair to MS"), and the IESG is going to ignore the last 1.5 years of SPF deployment experience and start fresh with collecting data since MS has only recently started doing SenderID checking (again "to be fair to MS").

The IETF needs to take the "E" out of their name and become the Internet Political Task Force.

You may be interested in another point of view on this:

To: spf-announce@v2.listbox.com
From: wayne@schlitt.net
Date: Fri, 24 Jun 2005 17:15:33 -0500
Subject: The IETF has accepted the SPF specification for RFC status!

Sender Policy Framework (SPF) News
by Wayne Schlitt, June 24, 2005

Greetings!

The IETF has accepted the SPF specification for RFC status!

A little over a month ago, we restarted this spf-announce mailing list
with a few updates of what had happened in the last year. Since
then, we have been hard at work on several things, and the first to
bear fruit is the SPF specification.

This SPF specification aims to clearly define the semantics of SPF,
based on the older SPF specifications from late 2003 and early 2004,
taking into account the state of SPF implementations and making
adjustments that have been requested by the IETF. This latest SPF
specification has undergone considerable review, not only by the SPF
community, but also by various IETF groups.

On June 6th, we submitted the completed draft for consideration by the
IETF, and today, the IETF has voted to accept the SPF specification as an
"Experimental" RFC[1]. The SPF specification still needs to go through the
RFC Editor, and this can take weeks or even months to complete.
(There are currently around 300 draft RFCs in the editor queue.)

We had asked for consideration as a "Standards Track" RFC rather than
"Experimental", but the IETF has informed us that they would only
consider "Experimental" status[2]. This was not a big surprise, but we
were surprised at some of the other actions that they took.

The IETF has decided that the SPF specification can not be made into
an RFC until the Sender ID specification is also ready. This appears
to be in order to be 'fair' to Microsoft[3]. Moreover, the IETF has
declared that the last 1.5 years of SPF deployment will not count
toward the two year requirement for experimental testing that they
have set. Again, this is to be 'fair' to Microsoft since their
testing has barely begun.

The Sender ID specifications call for the reuse of SPF version 1
records in incompatible ways in conflict with the SPF specification.[4]
We have made our objections clear to the IETF, but so far, the IETF
appears to be ready to bless this abuse of SPF records.[5] We will
continue to work to try and make SPF as reliable as possible.
__________________

[1] https://datatracker.ietf.org/public/pidtracker.cgi ?command=view_id&dTag=12662&rfc_flag=0

[2] http://thread.gmane.org/gmane.mail.spam.spf.counci l/312

[3] http://thread.gmane.org/gmane.mail.spam.spf.counci l/314

[4] http://www.schlitt.net/spf/spf_classic/draft-schli tt-spf-classic-02.html#anchor6

[5] http://thread.gmane.org/gmane.mail.spam.spf.counci l/333

hamers1 (35MB)
hamers1 (11MB)

hamers1 (35MB)
hamers1 (11MB)