> >> Humm, with my lashup here that Joanne helped me setup, S78spamassassin
> >> starts a few copies of spamd, and fetchmail is started much later in
> >> S99local. Its fetchmail that calls procmail, and its procmail that
> >> calls the spamd's, so there is no time that SA can be bypassed.
> >>
> >> I thought everyone was doing it. Somebodies better idea isn't?

> >
> >Problem is that the S78 will start spamassassin but that start does not
> >necessarily get a valid rule-set. For that, the internet connection must
> > be up at the time.

> And why would it not be when the network start is S10network?

I have:

S99 is what is being hit.

This is Debian box originally set up from a Knoppix hd installation. I have=
not fiddled with any of these. I assume there is decent reason for the=20
numbering schemes for these scripts.

The network connection is not immediate. Often must poll several times befo=
it gets logged in. I saw this with repeated attempts by ntpdate to get its=
connection. I currently try five times with 15 second waits. Sometimes hits=
the first time, sometimes needs a few tries.

>> Problem is that the S78 will start spamassassin but that start does not=

>> necessarily get a valid rule-set.

>This is the bit puzzling me: =A0Why must sa-update complete sucessfully=20
>for spamd to start? =A0The default SA rules should be shipped in the=20
>package, and be placed in (typically) /usr/share/spamassassin; =A0rules=20
>from sa-update will be placed somewhere like /var/lib/spamassassin (by=20
>default), and the SA rule-loading code will check both locations.

>Where do you get your SA package from? =A0It sounds like the package=20
>maintainer may need to learn a bit more about how SA works for the next=20
>package release...

This is from Debian "Sid" which I assume is legit enough. I discovered that=
sa_update failed, spam was getting through which was why I set it up as I=20