Re: tests= SIZE_LIMIT_EXCEEDED ??
Hi, Karsten Bräckelmann-2 wrote: > >> > X-SpamScore: 0 >> > tests= SIZE_LIMIT_EXCEEDED > >> Some sw components to be ruled out: >> - this isn't amavisd-new doing it, at least none of the official >> versions; > > Right, that's definitely something else adding the headers, as has been > pointed out before. Not SA. Anything, even a trivial filter foo calling > formail easily can inject such a header (though the order in the chain > may vary, which is not obvious from the OP). > > I have switched off amavis, but still the header contains X-SpamScore: 0 tests= SIZE_LIMIT_EXCEEDED Spamassassin is called in /etc/procmailrc: :0 hbfw | /usr/bin/spamc That's all and there are no user-defined files to procmail or SA. Stefan -- View this message in context: http://www.nabble.com/tests%3D-SIZE_LIMIT_EXCEEDED--tp23923284p23941272.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
tests= SIZE_LIMIT_EXCEEDED ??
Hi, I just had a closer look at the header of an email which should have been recognized by spamassassin as spam. Waht I found was this: X-SpamScore: 0 tests= SIZE_LIMIT_EXCEEDED I have checked /usr/share/spamassassin/ for a rule which might contain a size limit, but didn't finde any. A search with Google didn't help either. So, any suggestions from the list members where I can define the size that has been exceeded? Thanks, Stefan
Re: zero score rules still show up in 3.2.2
On Thu, 2007-07-26 at 13:30 -0500, McDonald, Dan wrote:
> I may have dreamed it, but I thought I remembered a discussion about
> removing rules with a zero score from spam reports. I upgraded one of
> my systems to 3.2.2 today (Mandriva Corporate Server 4.0, perl 5.8.7,
> called from amavisd-new 2.5.2) and still see zero scores from plugins
> displayed:
Bug 5519. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5519
guenther
--
char *t="[EMAIL PROTECTED]";
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: Mail not checked for spam in procmailrc
Please resist the pressing urge to top-post.
On Fri, 2007-07-13 at 12:43 -0700, Jai Rangi wrote:
> I can understand your frustration. Did I take you suggestion? yes and
> no.
> 1. Made changes in one test account and did not implement on others.
> Waiting for the problem to be resolved completely before I made this
> changes in every users procmailrc file.
Ah, nice to see you didn't completely ignore the feedback. So, you do
have at least two different rc files you are working on -- one with the
fixed rules, and this extended one...
> 2. Seriously (and truly) did not believe that this can be part of my
> problem and I am sure this is not.
It may be related. These rules potentially can have side-effects and
trigger on mail you didn't intend it to.
Also, most issues I pointed out make it harder to understand the
receipts. For you, while debugging and trying to understand what
possibly could have went wrong. And for us, having a brief look at it
trying to spot issues.
Did you investigate with the notes in mind I pointed out in my first
post? (Hint, since this seems to be a procmail receipt issue, not a SA
issue: Before asking procmail folks for help, you'd better fix all
receipts. They might jump on these, otherwise...)
guenther
--
char *t="[EMAIL PROTECTED]";
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: Mail not checked for spam in procmailrc
On Thu, 2007-07-12 at 15:18 -0700, Jai Rangi wrote:
> I did more digging in this.
> I was able to simulate the error. I changed my procmailrc something
> like this.
> #Rule number 1
> :0f
> * ^[F|f]rom:.*aleks\.com
> *
> ^[m|M]essage-[i|I][D|d]:.*aleks\.com|^Received:.*(authenticated).*\.aleks\.com
I see you didn't listen to my previous response. All these [F|f] and
similar thingies [1] are still horribly broken.
Also, the () parenthesis around "authenticated" are not literal
parenthesis, but grouping. They will *not* match any char.
Not going to read any further. It's quite frustrating to see when
replies and help offered on a mailing list is being ignored. Lots of
luck, with whatever you still are struggling with.
guenther
[1] That are char class parenthesis, no grouping with alternation. With
the pipe symbol in it and your intended usage, I'll refuse to call
these instances char class. Also, procmail is case insensitive by
default. These thingies are utterly useless.
--
char *t="[EMAIL PROTECTED]";
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: New version of iXhash plugin available
On Fri, 2007-07-06 at 20:15 +0200, Dirk Bonengel wrote:
> guenther schrieb:
> > Unfortunately, the example iXhash.cf of (current) version 1.0 is rather
> > scarce when it comes to the definitions. I'd wish for these to become as
> > informative again as they used to be. FWIW, these verbose descriptions
> > and comments have been the reason for me to pick 2 out of 3 lists in the
> > first place, long ago. (Which doesn't mean I am not re-evaluating this
> > decision. In fact, the third one seems to be highly accurate, too --
> > granted, based on some brief, non-exhaustive tests...)
> >
> >
> > Revision 23 of your plugins old home claims this:
> > http://wiki.apache.org/spamassassin/iXhash?action=diff
[...]
> > So, the most important question is: Does this still hold true?
> those comments have been changed to today's because:
> - They're not true any more for nospam.login-solutions.de; they are fed
> from 'high quality' input
> - They're to long: Older SA version have a limit of 50 chars I wasn't
> aware of at first
Please note that I am particularly missing the verbose *comments* you
offered with previous versions, and somewhat detailed info where
possible (in the worst case, "anonymous feed" would do).
I am not talking about the SA rule descriptions.
> I promised in an earlier reply to Per that I'll add some more info to
> website and archive but give me some time as $iXhash ne $dayjob
Fair enough. :) I must have missed that promise, cause it is pretty
much what I am missing...
guenther
--
char *t="[EMAIL PROTECTED]";
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: New version of iXhash plugin available
On Thu, 2007-07-05 at 23:04 +0200, Dirk Bonengel wrote:
> Maybe just a few words to close that discussion here:
Dirk, I don't think this really puts an end to this discussion, and I
believe what Per actually was wondering about are some precise
statements about each of the iXhash lists sources. At the very least,
that is what I am wondering about. ;)
Unfortunately, the example iXhash.cf of (current) version 1.0 is rather
scarce when it comes to the definitions. I'd wish for these to become as
informative again as they used to be. FWIW, these verbose descriptions
and comments have been the reason for me to pick 2 out of 3 lists in the
first place, long ago. (Which doesn't mean I am not re-evaluating this
decision. In fact, the third one seems to be highly accurate, too --
granted, based on some brief, non-exhaustive tests...)
Revision 23 of your plugins old home claims this:
http://wiki.apache.org/spamassassin/iXhash?action=diff
* ix.dnsbl.manitu.net: Uses iX Magazine's spam as datasource.
* nospam.login-solutions.de: *Manually* verified stuff, fed by
spamtraps run by LogIn & Solutions AG.
* nospam.login-solutions.ag: Lots of stuff, but *automatically*
categorized and contributed.
So, the most important question is: Does this still hold true?
Also, am I correct in understanding, that all you mentioned in your
previous post about the various sources applies to the last list only?
I do love your plugin and these lists, using them personally for a long
time -- and I find them to not only match a huge part of my spam, but to
also be highly accurate. However, Per is right in that trust is an
important piece of the puzzle whether to use a list or not.
I'd really love to see this info probably being mentioned on the (new)
project home, and definitely back in place in the example cf file...
guenther
--
char *t="[EMAIL PROTECTED]";
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: Mail not checked for spam in procmailrc
On Mon, 2007-06-25 at 16:17 -0700, Jai Rangi wrote:
> Two things here,
> 1. I have two rule, (from and message_id) they both should match before
> we add the tag "X-ALEKS-Spam: none". Right?
Yup.
> 2. Why I dont have tag in the header?
See below for more comments on this.
> jdow wrote:
> > Look at the line I underlined. Your rule decided you sent the email so
> > exempted it.
> >
> > {^_^}
> > - Original Message - From: "Jai Rangi" <[EMAIL PROTECTED]>
> >
> >
> >> I am not sure if I understand what do you mean by this,
> >> ***You wrote
> >> {^_^}
> >> **
That was just a default "signature"...
> >> Hello All,
> >> I am little confused here. I have this rule in my .procmailrc file.
> >>
> >> :0f
> >> * ^[F|f]rom:.*aleks\.com
> >> *
> >> ^[m|M]essage-[i|I][D|d]:.*aleks\.com|^Received:.*(authenticated).*\.aleks\.com
> >>
By default, procmail is case insensitive. You don't need to provide
upper and lower case. Also note, that [Ff] is a char class, no grouping
parenthesis. The | in there is a literal char, not an alternation. See
man procmailrc.
> >> | formail -A"X-ALEKS-Spam: none"
> >>
> >> #:0fwE
> >> :0fw
> >> * < 256000
> >> * !^X-ALEKS-Spam: none
> >> * !^FROM_DAEMON
> >> | /usr/bin/spamc
> >>
> >> So according to this rule every email should have tag X-ALEKS-Spam:
> >> none or it should be checked for spam. Now I get few mail that dont
> >> go through spam and do not get the No-Spam tag. For example this
This isn't quite true. There are 2 other exceptions to this rule.
Notably an upper size limit of 256 kByte, which coincidentally is the
spamc limit, too. That means, if the mail in question is larger than 256
kByte, it won't be processed by spamc. A totally valid case for a mail
that got neither header.
Anyway, this is getting pretty much off-topic for this list. I'd check
your procmail recipes first, to see why the mail has not been been
processed by SpamAssassin.
> > Can some one please give me some hint why this happened. Why this
> > email was not checked by spamc.
Yup, exactly. :) Seems, the mail has not been processed by SA. Which is
not a SA issue, if spamc never has been called by procmail to filter the
mail...
Caveat: Didn't have a sane dose of coffee, yet. ;)
guenther
--
char *t="[EMAIL PROTECTED]";
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: These are getting through SA...
On Fri, 2007-06-08 at 18:46 -0300, Luis Hernán Otegui wrote:
> OK, i?ve been googlin' around, and it seems like an issue between
> Amavis (or MailScanner, for waht I've found) and some unsupported
> versions of Net::DNS, because when I run the message through SA by
> itself, this comes out:
Whatever you manually fed SA was even more borked than the inline
copy-n-paste of a message in your OP. Looking briefly at your original
paste, I do see these:
> Date: Fri, 8 Jun 2007 20:25:53 -0100
> From: "Deana Adams" <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Can you imagine that you are healthy?
However, your manual run hit hard on...
> 0.0 MISSING_MIDMissing Message-Id: header
> 0.0 MISSING_DATE Missing Date: header
> 1.3 MISSING_HEADERSMissing To: header
> 1.8 MISSING_SUBJECTMissing Subject: header
> 2.5 FM_NO_FROM_OR_TO FM_NO_FROM_OR_TO
> 0.5 FM_NO_TO FM_NO_TO
The "-1.8 ALL_TRUSTED" seems to support the assumption that you fed a
body only. Could be due to the exact details how you did it, though.
Also, this run didn't identify a HTML part at all...
The only difference that accounts for the spamminess in the second run
is the URIBL_BLACK hit. Maybe an oops, maybe a misconfiguration, maybe
due to not running in real time, but long after.
> So I'm blaming it on Amavis... (Net::DNS 0.59 here)...
I don't see much evidence for this, yet. ;)
guenther
--
char *t="[EMAIL PROTECTED]";
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: 404 while getting RDJ updates?
On Thu, 2007-06-07 at 17:45 +0200, Anders Norrbring wrote:
> Anyone else getting 404 errors from RDJ lately?
Yes, this topic came up just a few hours ago. Probably a dDOS attack.
Please disable all RDJ till further notice.
guenther
--
char *t="[EMAIL PROTECTED]";
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: Rule debugging
Please do not hijack other threads by replying to a mail, if you
actually mean to start an unrelated thread. Removing the quoted text is
not sufficient.
On Fri, 2007-04-06 at 15:19 -0700, J. wrote:
> I got a false positive that was triggered by this:
>
> bodyMY_VIAG
> /\b(v(i|l)a.{0,4}g.{0,4}r.{0,4}a)|(v.{0,4}(i|l).{0,4}a.{0,4}gra)/i
> score MY_VIAG5
I don't think you want it like that. ;) See below.
> But when I try to see what it matched using this:
>
> grep -i '(v(i|l)a.{0,4}g.{0,4}r.{0,4}a)|(v.{0,4}(i|l).{0,4}a.{0,4}gra)'
> /home/domainmail/debug/ham.eml
>
> I get no output. Is there a better way to find what matched? Thanks.
Since the RE is rather simple and straight forward, looking at the mail
in your client, reading the text, should do.
vi ain't a grand editor.
Oops, that matches your RE. :) You probably should have another look at
it, trying to imagine what it possibly can match that you don't intend
to flag as spam. With all these .{0,4} in it, there are a *lot* of
possibilities.
Also, IMHO it is a bad idea to score 5.0 points for any rule that is not
fail proof. Generally, it should be considered a no-no. I do use it for
one handcrafted rule though, that matches a sender domain that
definitely must be faked -- because I happen to own the domain. In any
case where you can not eliminate any FP you should *not* use a score
that high. You won't find any single stock SA rule either, that alone
classifies a mail as spam. Carefully assigned scores based on the
"spammyness" and accumulating scores of multiple hit tests is a basic
concept of SA.
guenther
--
char *t="[EMAIL PROTECTED]";
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: Block a user based on content
Please resist the urge to top-post.
On Wed, 2007-04-04 at 06:17 -0700, dougp23 wrote:
> You are right. I don't want to block the mail, but I do want to assign a
> high enough value to it that it would be marked as spam. In this way, I can
> then go to management and show them how much spam this worker is sending.
So the mail gets tagged. Then what? Regardless of the mail being blocked
or not, whatever calls SA still needs to take action. In this case, it
sounds like "logging"...
> Yes, I do scan outgoing email for viruses using clamd
Unrelated. I asked, if you are scanning outgoing mail for Spam. Not
viruses. Cause if you don't process outgoing mail by SA, a SA based
solution to log these mails is not an option.
Also, since you are specifically aiming at *large* mail, keep in mind
that there usually is a max size for mail to be scanned at all. IMHO SA
is not the best candidate for this kind of "gathering logs".
guenther
--
char *t="[EMAIL PROTECTED]";
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: Block a user based on content
On Wed, 2007-04-04 at 05:30 -0700, dougp23 wrote:
> I have a user IN the company, who loves to forward these large messages,
> things like "Check out these so cute puppies", and "Photoshop Magic" and
> what not. Pure drivel.
>
> Anyway, Can I tell SA to "block sending email from jsmith" when "mutliple
> jpgs attached" or something like that?
No. Usual answer...
SA does not block mail. SA tags mail. It is the duty of whatever you are
using that calls SA to take appropriate action.
> I would appreciate any hints!
For starters... Are you actually scanning outgoing mail for Spam?
guenther
--
char *t="[EMAIL PROTECTED]";
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: what does the 'new' --allowupdates option to sa-update do?
> > I would say you should add allowplugins if and only if the following
> > three conditions hold:
>
> this is a helpful -- but very subjective -- approach.
You specifically asked the folks in here for recommendation. This of
course will be subjective...
Anyway, an attempt on being not subjective: Defaults are there for a
reason. Don't change a default, unless you fully understand the impact.
guenther
--
char *t="[EMAIL PROTECTED]";
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: SA not firing on every email
On Thu, 2006-12-07 at 03:12 -0700, Jason Marshall wrote:
> > Perhaps SA was too busy and those messages timed out and weren't scanned ?
> > Maybe those messages were greater than 250K (default max scan size) ?
>
> I have the same sort of problem, though it's on linux rather than windows.
> Several emails sneak through when the server is busy.
This most likely is not the same issue as the OP has,
> I write to spam quarantine, mail spool, and bayes databases over NFS, and
> sometimes the NFS server gets busy.
>
> I understand that spamassassin times out, but i'm running spamc with the
> -x option, which is supposed to, rather than pass the message through
> un-filtered, bounce it back to sendmail to try again. Is an appropriate
> return code not being set when spamc times out, maybe? Or does the -x
> option no longer work?
>
> >From the manpage:
>
> -x Disables the 'safe fallback' error-recovery method, which passes
> through the unaltered message if an error occurs. Instead, exit
> with an error code, and let the MTA queue up the mails for a retry
> later. See also "EXIT CODES".
>
> >From my .procmailrc:
procmail ist not an MTA, but an MDA (Mail Transport or Delivery Agent
respectively). procmail processes your mail and delivers it. According
to your receipts, correctly. ;)
> :0fw
> | /usr/local/bin/spamc -x
You're using spamc as a filter. There is no fallback receipt what to do
when the filter finishes unsuccessful (based on the exit code).
> :0:
> * ^X-Spam-Status: YES
> mail/spamfile
Filter finished unsuccessful, mail not altered, hence no such header. So
let's move on and check the next receipt...
> Am I missing something obvious? thanks anyone!
The fact that procmail is not an MTA and does not queue mails (see the
description of the spamc -x option above).
...guenther
--
char *t="[EMAIL PROTECTED]";
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: Sare URI ruleset
Please do not hijack unrelated threads. If you are posting to the list
with a new topic, do not Reply to a post but rather send a new one.
On Wed, 2005-10-05 at 10:04 -0600, Andrew Ott wrote:
> Got this report this morning from all 3 of my spamassassin servers, all
> running 3.0
>
> Is this ruleset no longer supported for 3.0?
>
> ===
> Lint output: warning: description for SARE_URI_GEOCIT_NUM is over 50 chars
> lint: 1 issues detected. please rerun with debug enabled for more
> information.
>
It's a warning only. AFAIK this is no reason to be concerned.
It just means, that the description is more than 50 chars long, and thus
a verbose report in the header may exceed an 80 chars limit.
FWIW, this is pretty common with some translations, like German.
...guenther
--
char *t="[EMAIL PROTECTED]";
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: spamassassin --lint
> looked in every user_prefs file on my system and I could find any
> reference to those lines.
If you're running 'spamassassin --lint' as root, I guess you should look
in /root/.spamassassin/user_prefs as well.
The user_prefs ONLY are evaluated of the user running spamassassin. No
need to look in any other users files...
...guenther
> On 5/26/05, Matt Kettler <[EMAIL PROTECTED]> wrote:
> > Tim Macrina wrote:
> > > THis may be a dumb question but were can I find those lines? I looked
> > > in /etc/mail/spamassassin/local.cf and I can't locate those entires.
> >
> > Try ~/.spamassassin/user_prefs
--
char *t="[EMAIL PROTECTED]";
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: Adjusting the AWL value
On Thu, 2005-05-26 at 12:55 -0500, Craig Jackson wrote:
> Hi,
> I'd like to change/reset-to-zero the autowhite list value for a sender.
> I read the man page (Mail::Spamassassin::Autowhitelist) but don't
> comprehend the syntax.
>
> Can someone give me a hint?
Rather than Mail::Spamassassin::Autowhitelist you likely want 'man
spamassassin'. :)
See --remove-from-whitelist and --remove-addr-from-whitelist options.
You can provide the email address alone or feed it the respective mail.
HTH
...guenther
--
char *t="[EMAIL PROTECTED]";
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: Setting up a rejection limit
On Sun, 2005-05-22 at 07:03 -0600, The Doctor wrote:
> How can one use user_prefs to tell spamassassin to reject spam
> tagged at level N at just send it back to them?
You can't.
SA is not designed to delete, deliver or bounce mail. It is designed to
scan and identify SPAM only. Any action taken (like delivering or
deleting) based on SA's judgment is another apps duty.
Besides, bouncing SPAM is not good practice. You'll often hit accounts
that are not in use at all or by innocent third party. Let your MTA or
MUA move them to a dedicated SPAM box or simply delete them, if you are
really sure not to get false positives.
...guenther
--
char *t="[EMAIL PROTECTED]";
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: not deleting
> I have a cpanel hosting account with spamassassin where you only have 3
> options on the SA page. I can enable SA, enable a spam box, and then
> another button to edit the user_prefs file.
>
> It works fine when I have spam box enabled but when I disabled the spam
> box the spam that used to go to the spam box is delivered into the
> inbox. It shows that the messages are over the required number of hits
> but they are being delivered instead of deleted.
>
> Any ideas on what I did wrong or to make it work?
This is not a SA issue.
SA is not designed to delete or deliver mail (to a SPAM box). It is
designed to scan and identify SPAM only. Any action taken (like
delivering or deleting) based on SA's judgement is another apps duty.
As you said, the SA headers are added even if 'moving to the SPAM box'
is disabled. That's fine as it just means you are not stuck with the
default SPAM box but you can sort (move, delete, archive, whatever) any
mails based on the SA score on your local end.
...guenther
--
char *t="[EMAIL PROTECTED]";
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; }}}
