Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
On Wed, 2010-08-04 at 15:32 -0700, Happy Chap wrote:
> Karsten Bräckelmann-2 wrote:
> > Uninstalling the old version (Installed by distro packages, right!? You
> > never confirmed this.) would be a very good idea. But beware, if both
> > versions actually share some prefix and thus files, you might end up
> > with some crucial bits removed by the package manager, which have been
> > overwritten by the CPAN install. If so, after uninstalling the old,
> > definitely do re-install the new.
>
> Maybe I'll just delete the old spamd executable in /usr/sbin so it can't be
> called by mistake rather than risking breaking any dependencies.
No distro provided RPM package for SA possibly can be a dependency. Just
don't also uninstall their dependencies, like Perl Modules.
> Yes, I did run sa-update after installing the 3.3 version (I read that in
> the change log - so I do try and follow the guides, it just didn't say don't
> install from CPAN if you have a distro version!) and I do have
> /var/lib/spamassassin/3.003001 as well. I guess I can just delete the
> /var/lib/spamassassin/3.002003 now as well as that should be being used
> anymore?
Yes, the 3.002003 one can be removed, if you are actually running SA 3.3
spamd.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
On Wed, 2010-08-04 at 15:23 -0700, Happy Chap wrote:
> Karsten Bräckelmann wrote:
> > What installed that init script? I believe SA built from CPAN does
> > *not*, so that's either your creation, or more likely part of the distro
> > supplied package (I assume) that provides SA 3.2.
> >
> > And, well, in there you probably find the full path of the spamd
> > executable actually started.
>
> Yes, it must have been part of the original SuSE build. However, taking the
> hint, I've killed the old spamd daemons, edited the init.d/spamd script to
> point to /usr/bin/spamd (the new version) and restarted the daemon and all
> *appears* to be working OK, fingers crossed, and X-Spam-Checker-Version is
> now reporting v3.3.1
>
> > I was merely pointing out, that you now have two instances of each
> > executable part of SA. spamc, spamd, sa-update, sa-learn, spamassassin.
> > It all depends on your $PATH, which one is used -- or the path
> > hard-coded into the calling (init) script.
> >
> > The idiots guide? Let's start by never have two different versions
> > installed. :)
>
> Again, lesson learned. I'm older & wiser today than I was yesterday!
>
> One final question - do I just delete the old spamd from /usr/sbin now to
> avoid any confusion (I've never "uninstalled" anything under Linux before)?
Well, I definitely would uninstall the package, as in 'rpm -e' or
whatever that specific version and flavor of SuSE prefers as a magical
package manager and interface (it changed). rpm will work, but there
most likely are more than a single RPM to remove.
Probably spamassassin, spamd, or similarly named, maybe more.
> Thanks for your help Karsten - much appreciated.
However, beware! Keep in mind my earlier note about packages removing
vital stuff in your current environment. Uninstalling some "spamd"
package also will flame your current init script. It is distro provided,
not installed by CPAN. Keep a copy...
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
Karsten Bräckelmann-2 wrote: > > > I guess so. You can quickly test, and revert the init script, if it > doesn't work out. > > Yes, that *appears* to have worked. Karsten Bräckelmann-2 wrote: > > > Well, you got to clean it up anyway. ;) > > Uninstalling the old version (Installed by distro packages, right!? You > never confirmed this.) would be a very good idea. But beware, if both > versions actually share some prefix and thus files, you might end up > with some crucial bits removed by the package manager, which have been > overwritten by the CPAN install. If so, after uninstalling the old, > definitely do re-install the new. > > Maybe I'll just delete the old spamd executable in /usr/sbin so it can't be called by mistake rather than risking breaking any dependencies. Karsten Bräckelmann-2 wrote: > > > Oh, and just in case -- you DID run sa-update with its 3.3 version, > didn't you? Otherwise, you'll end up with no rules after uninstalling > 3.2. > > Something like /var/lib/spamassassin/3.003001/ should exist. 'man > spamassassin' knows about the exact location -- if it's the 3.3 one. > > Yes, I did run sa-update after installing the 3.3 version (I read that in the change log - so I do try and follow the guides, it just didn't say don't install from CPAN if you have a distro version!) and I do have /var/lib/spamassassin/3.003001 as well. I guess I can just delete the /var/lib/spamassassin/3.002003 now as well as that should be being used anymore? Thanks again for all your help. David. -- View this message in context: http://old.nabble.com/X-Spam-Version-Checker-reports-3.2.3-but-running-3.3.1---Why--tp29351374p29351910.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
On Wed, 2010-08-04 at 15:10 -0700, Happy Chap wrote:
> > /usr/bin/spamd is v3.3.1
> > /usr/sbin/spamd is v3.2.3
> > /usr/bin/X11/spamd is also v3.3.1
>
> Is it as simple as I just need to edit my /etc/init.d/spamd script to amend
> any references in their from /usr/sbin/spamd to /usr/bin/spamd ?
I guess so. You can quickly test, and revert the init script, if it
doesn't work out.
> I thought about just giving it a try, but I'm just weary about making it
> worse now!
Well, you got to clean it up anyway. ;)
Uninstalling the old version (Installed by distro packages, right!? You
never confirmed this.) would be a very good idea. But beware, if both
versions actually share some prefix and thus files, you might end up
with some crucial bits removed by the package manager, which have been
overwritten by the CPAN install. If so, after uninstalling the old,
definitely do re-install the new.
Oh, and just in case -- you DID run sa-update with its 3.3 version,
didn't you? Otherwise, you'll end up with no rules after uninstalling
3.2.
Something like /var/lib/spamassassin/3.003001/ should exist. 'man
spamassassin' knows about the exact location -- if it's the 3.3 one.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
Karsten Bräckelmann-2 wrote: > > > Mixing packages and CPAN never is a good idea... > > OK, lesson learnt! Karsten Bräckelmann-2 wrote: > > > What installed that init script? I believe SA built from CPAN does > *not*, so that's either your creation, or more likely part of the distro > supplied package (I assume) that provides SA 3.2. > > And, well, in there you probably find the full path of the spamd > executable actually started. > > Yes, it must have been part of the original SuSE build. However, taking the hint, I've killed the old spamd daemons, edited the init.d/spamd script to point to /usr/bin/spamd (the new version) and restarted the daemon and all *appears* to be working OK, fingers crossed, and X-Spam-Checker-Version is now reporting v3.3.1 Karsten Bräckelmann-2 wrote: > > > I was merely pointing out, that you now have two instances of each > executable part of SA. spamc, spamd, sa-update, sa-learn, spamassassin. > It all depends on your $PATH, which one is used -- or the path > hard-coded into the calling (init) script. > > The idiots guide? Let's start by never have two different versions > installed. :) > > Again, lesson learned. I'm older & wiser today than I was yesterday! One final question - do I just delete the old spamd from /usr/sbin now to avoid any confusion (I've never "uninstalled" anything under Linux before)? Thanks for your help Karsten - much appreciated. -- View this message in context: http://old.nabble.com/X-Spam-Version-Checker-reports-3.2.3-but-running-3.3.1---Why--tp29351374p29351844.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
On Wed, 2010-08-04 at 15:02 -0700, Happy Chap wrote:
> Happy Chap wrote:
> > If I just issue a spamd --version at the bash prompt, it does report back
> > as SpamAssassin Server version 3.3.1 and as to which spamd, I seem to have
> > 3: /usr/bin/spamd /usr/sbin/spamd and also /usr/bin/X11/spamd
>
> OK, I've got a little further:
>
> /usr/bin/spamd is v3.3.1
> /usr/sbin/spamd is v3.2.3
> /usr/bin/X11/spamd is also v3.3.1
>
> so I can see what you're saying. Rather than upgrade the existing
> SpamAssassin installation, by using CPAN I've ended up installing a new one
> in a different location.
Err, any chance the (distro) package provided SA once had a link
from /usr/bin/spamd to /usr/sbin/spamd, where it actually lives? And the
former has been overwritten by the CPAN install?
> However, I'm still confused because the command in the procmailrc is
> /usr/bin/spamc and if I do a /usr/bin/spamc --version from the bash prompt
> that tells me it's SpamAssassin Client version 3.3.1 - so why is the
> SpamAssassin X-Spam-Checker-Version coming up as 3.2.3 when I'm calling it
> through /usr/bin/spamc (which claims to be v3.3.1)?
The version in that header is NOT added, nor affected by the spamc
version. The daemon, spamd, that does the actual processing, also adds
that header.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
Happy Chap wrote: > > > OK, I've got a little further: > > /usr/bin/spamd is v3.3.1 > /usr/sbin/spamd is v3.2.3 > /usr/bin/X11/spamd is also v3.3.1 > > Is it as simple as I just need to edit my /etc/init.d/spamd script to amend any references in their from /usr/sbin/spamd to /usr/bin/spamd ? I thought about just giving it a try, but I'm just weary about making it worse now! Thanks, David. -- View this message in context: http://old.nabble.com/X-Spam-Version-Checker-reports-3.2.3-but-running-3.3.1---Why--tp29351374p29351762.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
On Wed, 2010-08-04 at 14:54 -0700, Happy Chap wrote:
> Karsten Bräckelmann wrote:
> Hmmmthanks for your reply Karsten.
>
> I already had v3.2.3 running on the system, so I thought was upgrading! I
> followed the instructions on the "Upgrading to the latest version" page
> (http://wiki.apache.org/spamassassin/UpgradingVersion) which suggested
> installing by CPAN to upgrade so that's what I did (I didn't think I was
> being foolish!!).
Mixing packages and CPAN never is a good idea...
> No I didn't uninstall 3.2.3 - I didn't know I was supposed to.
>
> > Restarted spamd *how*? Using the same old init script?
>
> Yes, executed /etc/init.d/spamd restart (again I didn't think I was being
> foolish!)
What installed that init script? I believe SA built from CPAN does
*not*, so that's either your creation, or more likely part of the distro
supplied package (I assume) that provides SA 3.2.
And, well, in there you probably find the full path of the spamd
executable actually started.
> > The init script most likely calls spamd, where it has been installed
> > previously. The new 3.3 install probably uses a different prefix, and
> > thus is not used by the init script.
> >
> > Also keep in mind, your $PATH likely uses a different order to find
> > something like sa-update or sa-learn, than Perl uses to pick up its
> > M::SA module.
>
> You're getting beyond the limit of my knowledge here. Is there an idiots
> guide that you could point me to inorder to try and work through your
> suggestions?
I was merely pointing out, that you now have two instances of each
executable part of SA. spamc, spamd, sa-update, sa-learn, spamassassin.
It all depends on your $PATH, which one is used -- or the path
hard-coded into the calling (init) script.
The idiots guide? Let's start by never have two different versions
installed. :)
> > What does 'spamd --version' report? What about 'which spamd'? What about
> > finding all spamd executable scripts on your system?
>
> If I just issue a spamd --version at the bash prompt, it does report back as
> SpamAssassin Server version 3.3.1 and as to which spamd, I seem to have 3:
> /user/bin/spamd /user/sbin/spamd and also /use/bin/X11/spamd
>
> However, I guess I'm now confused as to why spamc is calling the old spamd
> (v3.2.3) when if I issue spamd from a bash prompt it uses the new one
> (v3.3.1).
spamc (the lightweight SA client) does not call spamd (the daemon). It
merely talks to the daemon, which is already running -- started by your
init script.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
Karsten Bräckelmann-2 wrote: > > > So when you confirmed by running sa-learn --dump magic previously, did > you first su to the user in question? The Bayes database does exist in > the user's $HOME/.spamassassin/, right? > Yes, I had su'ed to that user and yes, they have their own bayes_seen, bayes_toks, etc. in $HOME/.spamassassin Karsten Bräckelmann-2 wrote: > > > Despite running per-user, site-wide Bayes DB still is possible IIRC, if > you e.g. use an SQL backend. > > No, we're not using an SQL backend and every users has their own bayes database. Karsten Bräckelmann-2 wrote: > > > Anyway, since you still get BAYES_00 on these, you really should have a > close look at the tokens Bayes considers most confident. And why. With > some training, it most certainly at least should level up near BAYES_50, > not stay at 00. The tokens should help tell you why. > > OK, will do. Thanks again for your help Karsten. David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29351738.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
Happy Chap wrote: > > > If I just issue a spamd --version at the bash prompt, it does report back > as SpamAssassin Server version 3.3.1 and as to which spamd, I seem to have > 3: /usr/bin/spamd /usr/sbin/spamd and also /usr/bin/X11/spamd > > OK, I've got a little further: /usr/bin/spamd is v3.3.1 /usr/sbin/spamd is v3.2.3 /usr/bin/X11/spamd is also v3.3.1 so I can see what you're saying. Rather than upgrade the existing SpamAssassin installation, by using CPAN I've ended up installing a new one in a different location. However, I'm still confused because the command in the procmailrc is /usr/bin/spamc and if I do a /usr/bin/spamc --version from the bash prompt that tells me it's SpamAssassin Client version 3.3.1 - so why is the SpamAssassin X-Spam-Checker-Version coming up as 3.2.3 when I'm calling it through /usr/bin/spamc (which claims to be v3.3.1)? Thanks, David. -- View this message in context: http://old.nabble.com/X-Spam-Version-Checker-reports-3.2.3-but-running-3.3.1---Why--tp29351374p29351698.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
Karsten Bräckelmann-2 wrote: > > I guess the subject is incorrect. You are indeed running 3.2.3. ;) > > Upgraded, you just said. In previous posts you said "installed". That > makes a difference. > > How did you install 3.3? Given the Perl module dependency issues you > mentioned, I guess via CPAN. Did you uninstall 3.2? Nope... > > Hmmmthanks for your reply Karsten. I already had v3.2.3 running on the system, so I thought was upgrading! I followed the instructions on the "Upgrading to the latest version" page (http://wiki.apache.org/spamassassin/UpgradingVersion) which suggested installing by CPAN to upgrade so that's what I did (I didn't think I was being foolish!!). No I didn't uninstall 3.2.3 - I didn't know I was supposed to. Karsten Bräckelmann-2 wrote: > > > Restarted spamd *how*? Using the same old init script? > > Yes, executed /etc/init.d/spamd restart (again I didn't think I was being foolish!) Karsten Bräckelmann-2 wrote: > > > The init script most likely calls spamd, where it has been installed > previously. The new 3.3 install probably uses a different prefix, and > thus is not used by the init script. > > Also keep in mind, your $PATH likely uses a different order to find > something like sa-update or sa-learn, than Perl uses to pick up its > M::SA module. > > You're getting beyond the limit of my knowledge here. Is there an idiots guide that you could point me to inorder to try and work through your suggestions? Karsten Bräckelmann-2 wrote: > > > What does 'spamd --version' report? What about 'which spamd'? What about > finding all spamd executable scripts on your system? > > If I just issue a spamd --version at the bash prompt, it does report back as SpamAssassin Server version 3.3.1 and as to which spamd, I seem to have 3: /user/bin/spamd /user/sbin/spamd and also /use/bin/X11/spamd However, I guess I'm now confused as to why spamc is calling the old spamd (v3.2.3) when if I issue spamd from a bash prompt it uses the new one (v3.3.1). Karsten Bräckelmann-2 wrote: > > >> So why am I getting 3.2.3 still in the header of newly received mails? > > Because... it is actually running. :) > > New I avoid upgrading for a reason. Can you offer any suggestion as to what I should do next to sort the mess I've created out? Thanks, David -- View this message in context: http://old.nabble.com/X-Spam-Version-Checker-reports-3.2.3-but-running-3.3.1---Why--tp29351374p29351627.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On Wed, 2010-08-04 at 14:39 -0700, Happy Chap wrote:
> Bowie Bailey wrote:
> > Stupid question here, but are you sure you are training the same
> > database that SA is using?
> >
> > This is a fairly frequent problem. Common cases are:
> >
> > 1) SA being called as 'mailuser' and you are doing manual training on
> > root's database.
> > 2) You are manually training everything to the 'mailuser' database, but
> > SA is actually using per-user databases.
>
> Good question Bowie.
>
> I don't think that's happening. We do have a generic system-wide procmailrc
> but it's first command is for a DROPPRIVS, which I think/thought then runs
> as the specific user and in the procmail recipe a call is then made to spamc
> (although it is called without the -u option because, as I say, I think by
> issuing a DROPPRIVS it's running as that user so -u shouldn't be necessary).
*nod*
> If this doesn't sound right, by all means say - it's quite a while since i
> set all this up!
>
> Training is definitely happening on a per user basis (ie. the script is
> calling sa-learn -u).
So when you confirmed by running sa-learn --dump magic previously, did
you first su to the user in question? The Bayes database does exist in
the user's $HOME/.spamassassin/, right?
Despite running per-user, site-wide Bayes DB still is possible IIRC, if
you e.g. use an SQL backend.
Anyway, since you still get BAYES_00 on these, you really should have a
close look at the tokens Bayes considers most confident. And why. With
some training, it most certainly at least should level up near BAYES_50,
not stay at 00. The tokens should help tell you why.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
Bowie Bailey wrote: > > > Stupid question here, but are you sure you are training the same > database that SA is using? > > This is a fairly frequent problem. Common cases are: > > 1) SA being called as 'mailuser' and you are doing manual training on > root's database. > 2) You are manually training everything to the 'mailuser' database, but > SA is actually using per-user databases. > > -- > Bowie > > Good question Bowie. I don't think that's happening. We do have a generic system-wide procmailrc but it's first command is for a DROPPRIVS, which I think/thought then runs as the specific user and in the procmail recipe a call is then made to spamc (although it is called without the -u option because, as I say, I think by issuing a DROPPRIVS it's running as that user so -u shouldn't be necessary). If this doesn't sound right, by all means say - it's quite a while since i set all this up! Training is definitely happening on a per user basis (ie. the script is calling sa-learn -u). Thanks, David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29351529.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
On Wed, 2010-08-04 at 14:18 -0700, Happy Chap wrote: > Hi, > > I've just upgraded from SpamAssassin 3.2.3 to 3.3.1 and it all appeared to > install correctly. However, X-Spam-Version-Checker is still coming up as > 3.2.3 after restarting spamd. Can anyone suggest what I've done wrong? I think that's a mailscanner bug... There has been some discussion on this list about this in the past... -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX www.austinenergy.com
Re: X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
I guess the subject is incorrect. You are indeed running 3.2.3. ;)
On Wed, 2010-08-04 at 14:18 -0700, Happy Chap wrote:
> I've just upgraded from SpamAssassin 3.2.3 to 3.3.1 and it all appeared to
> install correctly. However, X-Spam-Version-Checker is still coming up as
> 3.2.3 after restarting spamd. Can anyone suggest what I've done wrong?
Upgraded, you just said. In previous posts you said "installed". That
makes a difference.
How did you install 3.3? Given the Perl module dependency issues you
mentioned, I guess via CPAN. Did you uninstall 3.2? Nope...
> If I try:
>
> perl -MMail::SpamAssassin -e 'print $Mail::SpamAssassin::VERSION."\n";'
>
> it reports 3.003001, so I think I genuinely am running version 3.3.1 and I
> have killed all spamd & restarted them.
Restarted spamd *how*? Using the same old init script?
The init script most likely calls spamd, where it has been installed
previously. The new 3.3 install probably uses a different prefix, and
thus is not used by the init script.
Also keep in mind, your $PATH likely uses a different order to find
something like sa-update or sa-learn, than Perl uses to pick up its
M::SA module.
What does 'spamd --version' report? What about 'which spamd'? What about
finding all spamd executable scripts on your system?
> So why am I getting 3.2.3 still in the header of newly received mails?
Because... it is actually running. :)
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
X-Spam-Version-Checker reports 3.2.3 but running 3.3.1 - Why?
Hi, I've just upgraded from SpamAssassin 3.2.3 to 3.3.1 and it all appeared to install correctly. However, X-Spam-Version-Checker is still coming up as 3.2.3 after restarting spamd. Can anyone suggest what I've done wrong? If I try: perl -MMail::SpamAssassin -e 'print $Mail::SpamAssassin::VERSION."\n";' it reports 3.003001, so I think I genuinely am running version 3.3.1 and I have killed all spamd & restarted them. So why am I getting 3.2.3 still in the header of newly received mails? Thanks, David. -- View this message in context: http://old.nabble.com/X-Spam-Version-Checker-reports-3.2.3-but-running-3.3.1---Why--tp29351374p29351374.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On 8/4/2010 4:24 PM, Happy Chap wrote: > Bowie Bailey wrote: >> On 8/4/2010 4:23 AM, Happy Chap wrote: >> >> You ARE manually training bayes (sa-learn) on these missed spams, >> right? That is probably the most useful thing you can do if you are >> getting Bayes_00 on them. > Hi Bowie, oh yes, every night. Stupid question here, but are you sure you are training the same database that SA is using? This is a fairly frequent problem. Common cases are: 1) SA being called as 'mailuser' and you are doing manual training on root's database. 2) You are manually training everything to the 'mailuser' database, but SA is actually using per-user databases. -- Bowie
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
John Hardin wrote: > > On Wed, 4 Aug 2010, Happy Chap wrote: > > > Apart from BAYES_00 what rules are they hitting? > > Thanks for your reply John. They're all more or less the same triggering: BAYES_00 HTML_MESSAGE MPART_ALT_DIFF RDNS_NONE and occasionally they also pick up one of the HTML_IMAGE_RATIO_xx triggers too. John Hardin wrote: > > > Would they be classified > as spam if Bayes wasn't a factor? > > No, probably not (HTML_MESSAGE, MPART_ALT_DIFF and RDNS_NONE aren't enough, those that have HTML_IMAGE_RATIO_xx might just be enough but borderline). John Hardin wrote: > > > If that's the case, then train them as spam an you should be okay. > > Regardless, 3.2.3 will be much less effective than 3.3.x and will only be > getting critical bugfixes (if anything) via sa-update. You should plan on > upgrading soon. > > Well, I've headed the advice and upgraded the server this evening, which has reminded me why I try and avoid doing upgrades!! It's obviously my lack of knowledge but it always seems so difficult to work out why things fail (tonight I eventually tracked the install fail down to not having openssl-devel installed, which meant not having rand.h, causing Crypt::OpenSSL::Random to fail, etc., etc. which stopped Mail::SpamAssassin installing). Got there eventually but, boy, is it hard work. Anyway, I'll keep on training the bayes database and see if running SA 3.3.1 improves the situation. Thanks everyone for their help. David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29351002.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
Henrik K wrote: > > On Wed, Aug 04, 2010 at 06:58:52AM -0700, Happy Chap wrote: > > Do the tokens look such that they might be used in legimate messages? > Usually you just have to sa-learn --spam enough of such spams to get > atleast > BAYES_50. > > I have no idea what kind of spams they are, but it all depends on whether > they have any tokens in common. But I can tell you that it's very rare to > get BAYES_00 for spam if you just learn them properly. > > Hi Henrik, Certainly some of them look legitimate. Maybe we just haven't got enough into sa-learn yet for it to have any effect. I don't know exactly, but suppose the user's been getting 20 per day for say 8 weeks (these are both guesses). So that's around 800 that should have been used to train bayes IF the user had sent every one for training. I can see they have about 34k identified spam mails in their bayes db, so these extra 800 would amount to about 2%. Perhaps that's just not enough? Thanks, David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29350853.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
Bowie Bailey wrote: > > On 8/4/2010 4:23 AM, Happy Chap wrote: > > You ARE manually training bayes (sa-learn) on these missed spams, > right? That is probably the most useful thing you can do if you are > getting Bayes_00 on them. > > Hi Bowie, oh yes, every night. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29350820.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: spamd: logger: try using --syslog-socket={unix,inet} or --syslog=file
On Wed, 2010-08-04 at 14:14 -0400, Nikolaus Rath wrote:
> For a couple of weeks now, spamd has been occasionally logging messages
> like this:
>
> Aug 4 02:49:58 ebox spamd[]: logger: try using
> --syslog-socket={unix,inet} or --syslog=file
> Aug 4 02:49:59 ebox spamd[30417]: logger: try using
> --syslog-socket={unix,inet} or --syslog=file
>
> Generally this doesn't seem to happen more than once a day and seems to
> coincide with some spamd childs taking exceptionally long to process a
> message:
After a quick grep and briefly looking at the code in Logger::Syslog, my
guess is that logging failed for some reason. That probably also
explains the long processing time. You also should see warnings logged
like this
logger: syslog failed: $eval_stat
where the $eval_stat hopefully will give some more hints. What are you
using for logging in SA?
guenther
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On Wed, 4 Aug 2010, Happy Chap wrote: In that case (and I've been barking up the wrong tree) do you have any suggestion as to what my next move should be to try to trap this type of spam? I'm moderately technical, but I think I've probably reached the limit of my current knowledge but am happy to learn if you could just point me in the right direction. Apart from BAYES_00 what rules are they hitting? Would they be classified as spam if Bayes wasn't a factor? If that's the case, then train them as spam an you should be okay. Regardless, 3.2.3 will be much less effective than 3.3.x and will only be getting critical bugfixes (if anything) via sa-update. You should plan on upgrading soon. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- USMC Rules of Gunfighting #7: In ten years nobody will remember the details of caliber, stance, or tactics. They will only remember who lived. --- Tomorrow: the 275th anniversary of John Peter Zenger's acquittal
spamd: logger: try using --syslog-socket={unix,inet} or --syslog=file
Hello,
For a couple of weeks now, spamd has been occasionally logging messages
like this:
Aug 4 02:49:58 ebox spamd[]: logger: try using --syslog-socket={unix,inet}
or --syslog=file
Aug 4 02:49:59 ebox spamd[30417]: logger: try using
--syslog-socket={unix,inet} or --syslog=file
Generally this doesn't seem to happen more than once a day and seems to
coincide with some spamd childs taking exceptionally long to process a
message:
Aug 4 02:48:44 ebox spamd[30417]: spamd: clean message (-6.6/5.0) for
nobody:107 in 181.4 seconds, 2195 bytes.
Compared to
Aug 4 03:52:12 ebox spamd[]: spamd: clean message (-19.2/5.0) for
nobody:107 in 1.4 seconds, 4242 bytes.
Also, the messages do *not* show up when spamd starts or reloads (at
least not in the next 5 minutes).
Can anyone tell me what this means?
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On 8/4/2010 4:23 AM, Happy Chap wrote: > Hi, > > We started getting (over the last 2 months say) lots of spam, which > Spamassassin isn't picking up as spam. Analysing these, they all seem to be > of the same type where many paragraphs of random text are "hidden" inside an > HTML comment (either contained in or inbetween /* and */ "tags"). > > Because of this "hidden" text, these messages are triggering BAYES_00 which, > I think, is the major influence on them not being correctly identified by > Spamassassin as spam. > > We're running a slightly old version of Spamassassin (v3.2.3) running on > SuSE 10.3 but do run sa-update's regularly to pick up new rules (which, > perhaps naively I thought was more important the upgrading Spamassassin > itself). > > Has anyone got any advice on how to correctly identify these mails as spam? > > Do I just need to upgrade to Spamassassin 3.3.0 (I'm assuming that this > probably won't make much difference because I'm already using the latest > rule sets thanks to sa-update)? > > Any ideas/help would be very gratefully received as the users are now > getting restless and, bayes training isn't really helping. Thanks. You ARE manually training bayes (sa-learn) on these missed spams, right? That is probably the most useful thing you can do if you are getting Bayes_00 on them. -- Bowie
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On Wed, Aug 04, 2010 at 06:58:52AM -0700, Happy Chap wrote: > > > > Henrik K wrote: > > > > > > Instead of speculating, try: > > > > cat msg | spamassassin -t -D bayes 2>&1 | grep bayes: > > > > It will tell you exactly what tokens are considered. > > > > > > Hi Henrik, > > Thanks for your reply. > > I'm not sure I totally understand all of the output to that, but I think > that's telling me that it isn't taking the text in the comments into account > - I can see various strings that it's picking up from the email, but the > commented text isn't obviously there. Maybe that's what you were trying to > tell me anyway :-) > > In that case (and I've been barking up the wrong tree) do you have any > suggestion as to what my next move should be to try to trap this type of > spam? I'm moderately technical, but I think I've probably reached the limit > of my current knowledge but am happy to learn if you could just point me in > the right direction. Do the tokens look such that they might be used in legimate messages? Usually you just have to sa-learn --spam enough of such spams to get atleast BAYES_50. I have no idea what kind of spams they are, but it all depends on whether they have any tokens in common. But I can tell you that it's very rare to get BAYES_00 for spam if you just learn them properly.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
Henrik K wrote: > > > Instead of speculating, try: > > cat msg | spamassassin -t -D bayes 2>&1 | grep bayes: > > It will tell you exactly what tokens are considered. > > Hi Henrik, Thanks for your reply. I'm not sure I totally understand all of the output to that, but I think that's telling me that it isn't taking the text in the comments into account - I can see various strings that it's picking up from the email, but the commented text isn't obviously there. Maybe that's what you were trying to tell me anyway :-) In that case (and I've been barking up the wrong tree) do you have any suggestion as to what my next move should be to try to trap this type of spam? I'm moderately technical, but I think I've probably reached the limit of my current knowledge but am happy to learn if you could just point me in the right direction. Thanks, David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29346570.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On Wed, Aug 04, 2010 at 01:23:32AM -0700, Happy Chap wrote: > > Hi, > > We started getting (over the last 2 months say) lots of spam, which > Spamassassin isn't picking up as spam. Analysing these, they all seem to be > of the same type where many paragraphs of random text are "hidden" inside an > HTML comment (either contained in or inbetween /* and */ "tags"). > > Because of this "hidden" text, these messages are triggering BAYES_00 which, > I think, is the major influence on them not being correctly identified by > Spamassassin as spam. Instead of speculating, try: cat msg | spamassassin -t -D bayes 2>&1 | grep bayes: It will tell you exactly what tokens are considered.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
Hi RW, thanks for your reply. >It's unlikely that that could push the BAYES RESULT down to BAYES_00 >unless there is uncorrected mistraining. Possibly, but I suspect mistraining isn't a problem because apart from this specific type of spam, Spamassassin is doing (and has done for sometime) a very good job of correctly identifying mail properly. If I do a dump of the bayes database, we've got about 30k each of spam & ham that's it's learned from and based on those numbers I don't think the %age of mistrained messages would be significant at all if the odd few were mistrained. >I don't think the 3.2.x rules get updated much. Perhaps this is leading >to false autotraining in BAYES. Ah, perhaps this is more of a problem, I didn't realise there were different rule updates based on the versions of Spamassassin (well, not between 3.2.x and 3.3.x anyway). In that case, I'll try upgrading Spamassassin and see if that helps. Incidentally, I'm not sure the autotraining is much of a problem as it only seems to be very obvious (high scoring) spam (and ham) that triggers autotraining, according to the headers at least. Certainly none of this particular type of spam is getting autotrainined according to the headers. Finally, do you know if Spamassassin has rules that *should* catch this type of spam (ie. no legitimate email would include big blocks of random paragraphs inside HTML comments). I would have thought that of itself would have perhaps been picked up by a rule to identify it as spam. Thanks again, David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29345981.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: server socket setup failed, retry 1: spamd: could not create INET socket on 127.0.0.1:783: Address already in use
Suhag P Desai wrote: No even when I try to do spamd at very first time after reboot the server, I get the same message,... huh? See below. Below are the output of [r...@spd ~]# ps -ef | grep spamd root 3519 3516 0 12:44 ?00:00:00 supervise spamd root 3544 3519 0 12:44 ?00:00:02 /usr/bin/perl -T -w /usr/bin/spamd -x -u vpopmail -s stderr qmaill3548 3520 0 12:44 ?00:00:00 /usr/bin/multilog t s100 n100 /var/log/qmail/spamd vpopmail 4035 3544 0 12:45 ?00:00:00 spamd child vpopmail 4036 3544 0 12:45 ?00:00:00 spamd child root 4586 4549 0 12:59 pts/100:00:00 grep spamd [r...@spd ~]# Am I missing something? It is running.
Re: Text contained in HTML comments causing BAYES_00 to classify as non-spam
On Wed, 4 Aug 2010 01:23:32 -0700 (PDT) Happy Chap wrote: > > Hi, > > We started getting (over the last 2 months say) lots of spam, which > Spamassassin isn't picking up as spam. Analysing these, they all seem > to be of the same type where many paragraphs of random text are > "hidden" inside an HTML comment (either contained in or > inbetween /* and */ "tags"). > > Because of this "hidden" text, these messages are triggering BAYES_00 > which, I think, is the major influence on them not being correctly > identified by Spamassassin as spam. It's unlikely that that could push the BAYES RESULT down to BAYES_00 unless there is uncorrected mistraining. > Do I just need to upgrade to Spamassassin 3.3.0 (I'm assuming that > this probably won't make much difference because I'm already using > the latest rule sets thanks to sa-update)? I don't think the 3.2.x rules get updated much. Perhaps this is leading to false autotraining in BAYES.
Text contained in HTML comments causing BAYES_00 to classify as non-spam
Hi, We started getting (over the last 2 months say) lots of spam, which Spamassassin isn't picking up as spam. Analysing these, they all seem to be of the same type where many paragraphs of random text are "hidden" inside an HTML comment (either contained in or inbetween /* and */ "tags"). Because of this "hidden" text, these messages are triggering BAYES_00 which, I think, is the major influence on them not being correctly identified by Spamassassin as spam. We're running a slightly old version of Spamassassin (v3.2.3) running on SuSE 10.3 but do run sa-update's regularly to pick up new rules (which, perhaps naively I thought was more important the upgrading Spamassassin itself). Has anyone got any advice on how to correctly identify these mails as spam? Do I just need to upgrade to Spamassassin 3.3.0 (I'm assuming that this probably won't make much difference because I'm already using the latest rule sets thanks to sa-update)? Any ideas/help would be very gratefully received as the users are now getting restless and, bayes training isn't really helping. Thanks. David. -- View this message in context: http://old.nabble.com/Text-contained-in-HTML-comments-causing-BAYES_00-to-classify-as-non-spam-tp29342874p29342874.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
RE: server socket setup failed, retry 1: spamd: could not create INET socket on 127.0.0.1:783: Address already in use
No even when I try to do spamd at very first time after reboot the server, I get the same message,... r...@spd ~]# spamd [4581] warn: server socket setup failed, retry 1: spamd: could not create INET socket on 127.0.0.1:783: Address already in use [4581] warn: server socket setup failed, retry 2: spamd: could not create INET socket on 127.0.0.1:783: Address already in use [4581] error: spamd: could not create INET socket on 127.0.0.1:783: Address already in use spamd: could not create INET socket on 127.0.0.1:783: Address already in use [r...@spd ~]# Below are the output of [r...@spd ~]# ps -ef | grep spamd root 3519 3516 0 12:44 ?00:00:00 supervise spamd root 3544 3519 0 12:44 ?00:00:02 /usr/bin/perl -T -w /usr/bin/spamd -x -u vpopmail -s stderr qmaill3548 3520 0 12:44 ?00:00:00 /usr/bin/multilog t s100 n100 /var/log/qmail/spamd vpopmail 4035 3544 0 12:45 ?00:00:00 spamd child vpopmail 4036 3544 0 12:45 ?00:00:00 spamd child root 4586 4549 0 12:59 pts/100:00:00 grep spamd [r...@spd ~]# -Original Message- From: Daniel Lemke [mailto:le...@jam-software.com] Sent: Wednesday, August 04, 2010 12:08 PM To: users@spamassassin.apache.org Subject: Re: server socket setup failed, retry 1: spamd: could not create INET socket on 127.0.0.1:783: Address already in use Suhag P Desai wrote: > > spamd: could not create INET socket on 127.0.0.1:783: Address already in > use > Spamd default port on your machine is already in use. Did you start a spamd instance before? -- View this message in context: http://old.nabble.com/server-socket-setup-failed%2C-retry-1%3A-spamd%3A-coul d-not-create-INET-socket-on-127.0.0.1%3A783%3A-Address-already-in-use-tp2934 2068p29342859.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
