This problem is probably due to the way Rules Emporium is handling
traffic. If requests come too fast from the same address, or if their
server is busy, they send an HTML redirect page instructing the client
to try again in 0.1 second. Curl and wget don't understand "<meta
http-equiv="Refresh" ...>" and simply store the refresh page as the
output of the request. rules_du_jour is just a shell script so a proper
fix should be pretty easy. The following is a quick and dirty patch
which sort of solves the problem, at least for the next run of
rules_du_jour.
-------------------- <cut here> ------------------------
--- /root/rules_du_jour.orig 2007-06-17 21:01:24.000000000 -0500
+++ /var/lib/spamassassin/rules_du_jour 2007-06-18 12:37:44.000000000 -0500
@@ -907,6 +907,8 @@
[ "${SEND_THE_EMAIL}" ] && echo -e "${MESSAGES}" | sh -c "${MAILCMD} -s
\"RulesDuJour Run Summary on ${HOSTNAME}\" ${MAIL_ADDRESS}";
fi
+grep -il 'META HTTP-EQUIV' ${TMPDIR}/*|xargs -n1 rm -f
+
cd ${OLDDIR};
exit;
-------------------- <cut here> ------------------------
rules_du_jour will still fail, but this will clean up the mess and next
time (hopefully) it'll run properly. A proper fix would sense when this
happens and retry the download after a suitable short wait. It may also
be helpful to insert some "sleep .5" instructions at appropriate points
(or "sleep 1" if your implementation of sleep(1) doesn't understand
floating point numbers).
On Thu, 2007-06-28 at 11:22 +0100, Nigel Frankcom wrote:
> On Wed, 27 Jun 2007 16:42:39 -0400, "Daryl C. W. O'Shea"
> <[EMAIL PROTECTED]> wrote:
>
> >Nigel Frankcom wrote:
> >> On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> I?ve been getting the lint failures found below on my Rules Du Jour
> >>> updates for a few weeks now. Yes this would be since the DDoS attacks
> >>> on rulesemporium. It looks like the same problem people have been
> >>> having with the tripwire but for me it?s the adult and since just
> >>> recently the spoof rules. The solutions I've seen don't seem to work
> >>> for me. I see that my cron job (run nightly) is pulling some HTML
> >>> source instead of the rules. I?ve tried removing the faulty
> >>> 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually
> >>> replacing it with the ?actual? file using wget. I?ve even manually
> >>> updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure
> >>> that it was correct. When I us ?wget
> >>> http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it
> >>> works without problems. Does anyone have any ideas on how I might fix
> >>> this problem?
> >>>
> >>> <snip>
> >>> ***WARNING***: spamassassin --lint failed.
> >>> Rolling configuration files back, not restarting SpamAssassin.
> >>> Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf
> >>
> >> The quick cure is to delete anything in the
> >> /etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand.
> >>
> >> That worked for me on CentOS 4.5
> >>
> >> The bug has been reported and a fix is due in 3.2.2 I believe.
> >
> >Huh? What's SA have to do with RDJ triggering Prolexic's DoS protection?
> >
> Daryl is right, there is no fix due in 3.2.2 - I got the RDJ and the
> sa-update errors confused. I guess maybe I should dye my hair blonde.
>
> Apologies for any confusion I've caused.
>
> Kind regards
>
> Nigel
--
Lindsay Haisley <[EMAIL PROTECTED]>
FMP Computer Services
