ScamNailer update STILL not working

[Mark Sapiro]

On 06/12/2013 02:22 PM, Robert Lopez wrote:
> On Sat, Jun 8, 2013 at 6:44 PM, Mark Sapiro <mark at msapiro.net> wrote:
>> ScamNailer gets the information about current data by doing a DNS lookup
>> of a TXT record for emails.msupdate.greylist.bastionmail.com. For over 6
>> weeks, this has been returning "emails.2013-164.6", i.e. week 16, day 4
>> update 6. It is currently week 23, day 0.
>>
>> I posted a patch at
>> <http://lists.mailscanner.info/pipermail/mailscanner/2013-May/100746.html>
>> that works around this by guessing the current update, and it seems to
>> work for me ...
[...]
> I confess to not trying your patch because I do not understand it.


The string such as "emails.2013-164.6" identifies the most recent
ScamNailer update. It is very structured and predictable.

In this string, 2013 is the year, 16 is the week # within the year, 4 is
the day number within the week and 6 is the 6th update of the day.

The patch first figures for the current date (GMT) what the year, week
and day of week are. It's a bit tricky because the perl gmtime function
doesn't return a week number so we have to calculate it from day of
year, but it also depends on what day of the week Jan 1 fell on. Anyway,
the only thing it can't determine is the update number. For each day,
update 0 is the current full file at the beginning of the day and the
remaining updates are incremental changes added as needed.

So the first thing the patch does after computing the above is put
together the year, week and day into something like 2013-234 which is
the correct string for Thursday, 13 June, 2013. It then compares that to
the string it got from the TXT record, and if the one from the TXT
record is >=, it just accepts that and effectively does nothing, but if
it's <, the patched code replaces the string from the TXT record with
its own and arbitrarily says the update # is 99.

The patched ScamNailer then retrieves the base if necessary and the
sequential updates from the last cached one until it gets a 404 or some
other error (or retrieves update 99, but so far that hasn't happened.
Then it resets the update # to the last one retrieved and proceeds.

The rest of the patch just adds another condition around a piece of the
code to avoid the issue described in the comment.

I hope this explanation helps. The patched code has been working well
for me because the updates are actually being pushed to the update
server(s), it's just the information about the current update name that
isn't there.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan