I love this idea.

I'd make the description more explicit:

WARNING: This version of SpamAssassin is no-longer supported by active rule development or bug fixes.  Please upgrade.

I'd still love to see some stats on the percentage of hosts running spamassassin by version, from the people hosting the sa-update data.  I'm hoping the http agent mentions the version number?

A very good idea and ties in very well with getting an official policy on what is supported (which doesn't really exist right now).

And yes, the http [sic] referer does contain the version.  Here's some live logs from the mirror I run:

X.X.X.X - - [03/Jun/2011:19:55:34 -0400] "GET /895075.tar.gz HTTP/1.1" 200 123707 "-" "sa-update/svn607589/3.2.4" "X.X.X.X.80861307145334721"
X.X.X.X - - [03/Jun/2011:19:55:35 -0400] "GET /895075.tar.gz.sha1 HTTP/1.1" 200 56 "-" "sa-update/svn607589/3.2.4" "X.X.X.X.81111307145335101"
X.X.X.X - - [03/Jun/2011:19:55:35 -0400] "GET /895075.tar.gz.asc HTTP/1.1" 200 823 "-" "sa-update/svn607589/3.2.4" "X.X.X.X.81131307145335186"
X.X.X.Y - - [03/Jun/2011:19:55:35 -0400] "GET /1083704.tar.gz HTTP/1.1" 200 255326 "-" "sa-update/svn607589/3.3.1" "X.X.X.Y.327331307145333240"
X.X.X.Y - - [03/Jun/2011:19:55:36 -0400] "GET /1083704.tar.gz.sha1 HTTP/1.1" 200 80 "-" "sa-update/svn607589/3.3.1" "X.X.X.Y.6324130714533640"
X.X.X.Y - - [03/Jun/2011:19:55:50 -0400] "GET /1083704.tar.gz HTTP/1.1" 200 255326 "-" "sa-update/svn607589/3.3.1" "X.X.X.Y.8113130714535059"
X.X.X.Y - - [03/Jun/2011:19:55:50 -0400] "GET /1083704.tar.gz.sha1 HTTP/1.1" 200 80 "-" "sa-update/svn607589/3.3.1" "X.X.X.Y.327331307145350442"
X.X.X.Y - - [03/Jun/2011:19:55:50 -0400] "GET /1083704.tar.gz.asc HTTP/1.1" 200 823 "-" "sa-update/svn607589/3.3.1" "X.X.X.Y.63241307145350527"

Regards,
KAM

(In reply to comment #2)
> And yes, the http [sic] referer does contain the version.  Here's some live
> logs from the mirror I run:

Ohh, can you give us the output of this?

cat logfile | grep 'tar.gz HTTP' | cut -d'"' -f6 | cut -d'/' -f3 | sort | uniq -c

And the timestamps of the first and last line?
(That command will just count hits per SA version.)

Possibly more interesting, number of distinct IPs per version:

cat logfile | grep 'tar.gz HTTP' | tr '"/' '  ' | cut -d' ' -f1,23 | cut -d' ' -f2 | sort | uniq -c

If you want to use multiple compressed and uncompressed logs, in bash, replace "cat logfile" with something like, parentheses included:

(cat name.log name.log.1 ; zcat name.log*.gz)

("[sic]" is supposed to go after the relevant word.)

     7 3.1.5
      7 3.1.6
     77 3.1.7
     25 3.1.8
    143 3.1.9
     21 3.2.0
   3973 3.2.1
     68 3.2.2
    771 3.2.3
   4442 3.2.4
   7082 3.2.5
    284 3.3.0
  33605 3.3.1
    553 3.3.2
     24 3.4.0

This is May 31st from midnight to 6/4 around 5:50PM for my mirror only.

(In reply to comment #5)

Which one was that?

3.1 259    0.6%
3.2 10057 22.5%
3.3 34442 76.9%
3.4 24     0.5%

Over a fifth of the people running spamassassin are using version 3.2.x.  Woo.

(In reply to comment #6)
> Over a fifth of the people running spamassassin are using version 3.2.x.  Woo.

That's not an accurate statement at all.  All the other people who have already updated 3.3.x versions since the last update was released over 10 weeks ago (March 24) aren't represented.  There are way more people systems running 3.3.x than 34k (or even 68k, doubled to count my mirror).

(In reply to comment #7)
> That's not an accurate statement at all.  All the other people who have already
> updated 3.3.x versions since the last update was released over 10 weeks ago
> (March 24) aren't represented.  There are way more people systems running 3.3.x
> than 34k (or even 68k, doubled to count my mirror).

I'm not following your logic.  You're saying that 34,000 machines running 3.3.x didn't run sa-update at all for 10 weeks, then just happened to run it during this several day sample period?  

Perhaps DNS logs (looking up the version number of the latest update) would be more useful.

The problem with the methodology is that it assumes that no-one has upgraded since March 31st.  The clean way to distinguish would be:
1. gather the uniq set of ip addresses.
2. find the most recent entry for those addresses
3. summarize those records.

That's considerably challenging in a one-liner bash script.  Wouldn't be terribly difficult to code in perl.

(In reply to comment #8)
> I'm not following your logic.  You're saying that 34,000 machines running 3.3.x
> didn't run sa-update at all for 10 weeks, then just happened to run it during
> this several day sample period?  

Yes, that is correct logic.  sa-update checks DNS first before going to download a tar.gz file which is what you asked for.

> Perhaps DNS logs (looking up the version number of the latest update) would be
> more useful.

I believe this is an unfeasible request.  DNS is a distributed and caching system that doesn't lend itself well to these type of checks.  

What is the exact goal you are trying to reach?  What is the number you want to know?

regards,
KAM

(In reply to comment #10)
> What is the exact goal you are trying to reach?  What is the number you want to
> know?

Mostly I guess my goal is to get an official announcement that 3.2.x is no-longer supported, and this rule added to a 3.2.x rule update.

Having some numbers on what percentage of servers are running which versions are just a curiosity toward that goal.

> Mostly I guess my goal is to get an official announcement that 3.2.x is
> no-longer supported, and this rule added to a 3.2.x rule update.

To my knowledge, the project currently has no official position of supported or unsupported beyond prima facie lack of updates being released.  I'm working to get that changed.

But having a policy is a blocker to this bug and that's a PMC issue currently.

However, I'd likely look for a change that is a bit more intrusive in sa-update that checks for a DNS entry for a support flag and requires a --force-update-check or something like that parameter.

RW's idea of a short term update isn't bad but I don't know that we have a way to inject rules into a specific version of SA and if/else rules aren't necessarily parsed well enough during a lint to be useful.

Regards,
KAM

I like this idea, but I also would like to make things clear about it.

I would refrain the SA team from doing any step resembling the "ClamAV EOL case" (http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/). I wouldn't really like to see the SA team mudding their userbase to avoid being flooded by the flames returned by that policy...

So, please, a 0.001 score is fine. But don't even think to rise it to "teach" how to admin a system to your userbase.