spamd: pyzor: check failed: internal error
I'm getting the errormessage below; Who can help ? Wolfgang Jan 2 09:25:58 saxophon spamd[13330]: spamd: connection from localhost [127.0.0.1] at port 40156 Jan 2 09:25:58 saxophon spamd[13330]: spamd: checking message [EMAIL PROTECTED] for exim:502 Jan 2 09:26:00 saxophon spamd[13330]: internal error Jan 2 09:26:00 saxophon spamd[13330]: pyzor: check failed: internal error -- Wolfgang Fuertbauer (e-Mail: [EMAIL PROTECTED]) EBEWE Pharma Mondseestrasse 11 4866 Unterach, Austria Tel +43 7665 8123 315 Mobile: +43 664 8397987 Fax +43 7665 8123 1487 http://www.ebewe.com
A self-declared Bulk message
Just reviewed the spam that passed through our amavisd-new + SA3.1.0 barrier and noticed something funny at the bottom of a message: This email has been sent with an unregistered version of MaxBulk Mailer. MaxBulk Mailer is a new easy-to-use mail merge software for Macintosh. This message came to a non-existing address we started to trap for free spam, so nobody ever opted-in. Here's the message, I removed our internal SMTP headers and cut the actual recipient domain: http://spazioinwind.libero.it/ik1zyw/temp/selfDeclaredBulk.eml That website is now probably into most SURBLs, but it is funny anyway. Happy New Year to those who are in A.D. 2006! :-) Paolo
sa-learn
Hi, I have installed spamassassin with amavis and postfix. I also created a dir where I put all the spam mails that spamassassin dont mark as spam in order to run the sa-learn script hourly. Our corporate email client is Outlook 2000/2003 and since Outlook add some kind of header I am not sure if spamassassin is learning properly or just ignoring the messages. Thanks.
Re: Real-Time Stats Plugin Released - UPDATE RELEASED
I am running MySQL 5.0 and WAS receiving an error for the SQL statement that had the 'ON DUPLICATE KEY UPDATE'. After doing a little investigation and looking into the MySQL docs I have fixed the issue. I dropped the entire WHERE from the statement. According to MySQL docs, there is no WHERE in the statement. If a record key exists, that record is used in the 'ON DUPLICATE KEY UPDATE' part of the statement. Or, maybe I downloaded the wrong version of the plugin. On Saturday, December 31, 2005 at 5:55:31 AM, [EMAIL PROTECTED] confabulated: I have updated the INSERT code to use the ON DUPLICATE KEY feature of MySQL. This feature insures that if the insert statement is executed and another insert has already occurred for the changing day, an update will take place instead. Hopefully, this will alleviate the largest possibility of a race condition. However, this is a feature of MySQL that is only available inside of MySQL 4.1 and greater. If you are NOT running at least MySQL 4.1 you can get the old code from my website listed below. Where to get the changes - http://wiki.apache.org/spamassassin/StatsPlugin or http://www.okeating.net/blosxom.cgi/2005/12/31#statsplugin-update Let me know if you see any other issues or problems. Thanks for everyone's input, more is always appreciated. Thanks, James Jim C. Nasby wrote: On Wed, Dec 28, 2005 at 02:19:51AM -0600, Chris Thielen wrote: James Keating wrote: Well the simplest fix is the one that I did not implement in the first place, using ON DUPLICATE KEY. However, I did not implement that because of its only being in version 4.1 of MySQL and I still use Debian stable for most production machines, which runs 4.0.x. Anyway, I will poke at it some more. Read on for a portable fix called optimistic locking. Pseudocode follows. I assume you are doing something like this: You assume wrong. :) The code is doing UPDATE ... SET field = field + 1 ... which is almost always a much better idea than doing the increment in code. The race condition is in checking to see if the row already exists, and then using that information to decide if you should do an insert or an update. The example at the very bottom of http://lnk.nu/postgresql.org/5sl.html is how you would do this in a function in PostgreSQL, though there's no reason I can think of why you couldn't do that in perl instead (though it would perform much slower). -- This message is made of 100% recycled electrons.
Re: question on RBLs
At 01:33 PM 1/2/2006, Leonardo Rodrigues Magalhães wrote: Hello Guys, I'm using SA 3.1.0 and i'd like to make some questions about using RBLs with spamassassin. SA is configured and running just fine. It's being called from amavisd. That's not the problem, it's working fine. My question is related to RBL using. I have disabled the 'local_only' tests on amavisd.conf and SA is doing RBL lookups. I have configured some 'score RBL_RULE_NAME 0' in my local.cf, which is being used, because i have several options there and I know they are being called. Altough I have specified 0 to some RBL rules, i can see using tcpdump that lookups are being done for the disabled RBLs. Score seems to be always 0 and rules disabled, because i couldnt find them on my mail logs. But seems that DNS lookups are still being done, thus creating some unnecessary network traffic. Is the correct way to disable a rule setting 0 to its score ??? If yes, how can I disable RBL rules and make them stop generating network traffic ? Are the offending tests combined queries like SBL/XBL, NJABL or the like? If so, instert a score 0 statement for the unscored parent rule (the one with a double underscore at the start of it's name in the dnsbl config file) and it should disable the query. Disabling the sub rules, that depend on a parent, will merely disable analysis of the results. The unscored parent still runs and that's what causes the query.
Re: question on RBLs
Matt Kettler escreveu: Are the offending tests combined queries like SBL/XBL, NJABL or the like? If so, instert a score 0 statement for the unscored parent rule (the one with a double underscore at the start of it's name in the dnsbl config file) and it should disable the query. Disabling the sub rules, that depend on a parent, will merely disable analysis of the results. The unscored parent still runs and that's what causes the query. Matt, setting score 0 ONLY to the parent rule, the one with __ on the beginning, didnt disable the rule. I had to set score 0 to the parent rule and all it's child rules. After doing this, lookup for the disabled RBLs really dissapear from tcpdump :) Thanks for your attention, -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email [EMAIL PROTECTED] My SPAMTRAP, do not email it
Re: Real-Time Stats Plugin Released - UPDATE RELEASED
You did have the latest version Duane. I guess MySQL 4.1 doesn't care if you have the WHERE clause after it; as I have been using the updated version for sometime and have not received any errors. But MySQL 5.0, apparently, doesn't like that syntax. I removed the WHERE clause and tested it with MySQL 4.1 and it still appears to function properly. I have updated the SpamAssassin Wiki and the code on my site. Thanks for catching that Duane. - James Duane Hill wrote: I am running MySQL 5.0 and WAS receiving an error for the SQL statement that had the 'ON DUPLICATE KEY UPDATE'. After doing a little investigation and looking into the MySQL docs I have fixed the issue. I dropped the entire WHERE from the statement. According to MySQL docs, there is no WHERE in the statement. If a record key exists, that record is used in the 'ON DUPLICATE KEY UPDATE' part of the statement. Or, maybe I downloaded the wrong version of the plugin. On Saturday, December 31, 2005 at 5:55:31 AM, [EMAIL PROTECTED] confabulated: I have updated the INSERT code to use the ON DUPLICATE KEY feature of MySQL. This feature insures that if the insert statement is executed and another insert has already occurred for the changing day, an update will take place instead. Hopefully, this will alleviate the largest possibility of a race condition. However, this is a feature of MySQL that is only available inside of MySQL 4.1 and greater. If you are NOT running at least MySQL 4.1 you can get the old code from my website listed below. Where to get the changes - http://wiki.apache.org/spamassassin/StatsPlugin or http://www.okeating.net/blosxom.cgi/2005/12/31#statsplugin-update Let me know if you see any other issues or problems. Thanks for everyone's input, more is always appreciated. Thanks, James Jim C. Nasby wrote: On Wed, Dec 28, 2005 at 02:19:51AM -0600, Chris Thielen wrote: James Keating wrote: Well the simplest fix is the one that I did not implement in the first place, using ON DUPLICATE KEY. However, I did not implement that because of its only being in version 4.1 of MySQL and I still use Debian stable for most production machines, which runs 4.0.x. Anyway, I will poke at it some more. Read on for a portable fix called optimistic locking. Pseudocode follows. I assume you are doing something like this: You assume wrong. :) The code is doing UPDATE ... SET field = field + 1 ... which is almost always a much better idea than doing the increment in code. The race condition is in checking to see if the row already exists, and then using that information to decide if you should do an insert or an update. The example at the very bottom of http://lnk.nu/postgresql.org/5sl.html is how you would do this in a function in PostgreSQL, though there's no reason I can think of why you couldn't do that in perl instead (though it would perform much slower). -- This message is made of 100% recycled electrons.
Re: Real-Time Stats Plugin Released - UPDATE RELEASED
On Monday, January 2, 2006 at 6:50:15 PM, [EMAIL PROTECTED] confabulated: You did have the latest version Duane. I guess MySQL 4.1 doesn't care if you have the WHERE clause after it; as I have been using the updated version for sometime and have not received any errors. But MySQL 5.0, apparently, doesn't like that syntax. I removed the WHERE clause and tested it with MySQL 4.1 and it still appears to function properly. I have updated the SpamAssassin Wiki and the code on my site. Thanks for catching that Duane. Not a problem. Glad I can be of some assistance on this list finally. SA was completely new to me when I joined the list and usually I sit back in the woodwork and let things kind of soak in for a bit before attempting to aid in something. I usually like to make sure I have most, if not all, the ground work done in a solution to something rather than having to go back and forth a few times. That was hard at first on this one because MySQL is still relatively new to me. Anyhow, the plugin is working like a charm at this time. Thanks! Duane Hill wrote: I am running MySQL 5.0 and WAS receiving an error for the SQL statement that had the 'ON DUPLICATE KEY UPDATE'. After doing a little investigation and looking into the MySQL docs I have fixed the issue. I dropped the entire WHERE from the statement. According to MySQL docs, there is no WHERE in the statement. If a record key exists, that record is used in the 'ON DUPLICATE KEY UPDATE' part of the statement. Or, maybe I downloaded the wrong version of the plugin. On Saturday, December 31, 2005 at 5:55:31 AM, [EMAIL PROTECTED] confabulated: I have updated the INSERT code to use the ON DUPLICATE KEY feature of MySQL. This feature insures that if the insert statement is executed and another insert has already occurred for the changing day, an update will take place instead. Hopefully, this will alleviate the largest possibility of a race condition. However, this is a feature of MySQL that is only available inside of MySQL 4.1 and greater. If you are NOT running at least MySQL 4.1 you can get the old code from my website listed below. Where to get the changes - http://wiki.apache.org/spamassassin/StatsPlugin or http://www.okeating.net/blosxom.cgi/2005/12/31#statsplugin-update Let me know if you see any other issues or problems. Thanks for everyone's input, more is always appreciated. Thanks, James Jim C. Nasby wrote: On Wed, Dec 28, 2005 at 02:19:51AM -0600, Chris Thielen wrote: James Keating wrote: Well the simplest fix is the one that I did not implement in the first place, using ON DUPLICATE KEY. However, I did not implement that because of its only being in version 4.1 of MySQL and I still use Debian stable for most production machines, which runs 4.0.x. Anyway, I will poke at it some more. Read on for a portable fix called optimistic locking. Pseudocode follows. I assume you are doing something like this: You assume wrong. :) The code is doing UPDATE ... SET field = field + 1 ... which is almost always a much better idea than doing the increment in code. The race condition is in checking to see if the row already exists, and then using that information to decide if you should do an insert or an update. The example at the very bottom of http://lnk.nu/postgresql.org/5sl.html is how you would do this in a function in PostgreSQL, though there's no reason I can think of why you couldn't do that in perl instead (though it would perform much slower). -- This message is made of 100% recycled electrons.
uninitialized value in numeric gt ???
Happy New Year! I just installed spamassassin 3.1.0 (2005-09-13) on a debian box. Everything appears to be running OK, except these incessant errors: Use of uninitialized value in numeric gt() at /usr/lib/perl/5.8/DB_File.pm line 271. I have googled to no avail. Probably, there is something simple to be done; but, I have not found it, yet. So, I place myself at your mercy. ALL pointers are welcome. What do you think? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: Parse and check URIs
On Sunday, January 1, 2006, 1:46:40 PM, Markus Mayer wrote: Now it seems to be sites hosted somewhere in China, with arbitrary domain-names. I have been getting more and more of those lately. They slip right through Spamassassin with very low spam-scores. Do you have SURBLs enabled? Most of the bad guy domains should be on SURBLs. http://www.surbl.org/ Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: SA suddenly giving lots of FP's?
On Sunday 01 January 2006 22:51, jdow wrote:
[...]
Anyway, the rule thats applying the 3.8 score is
HELO_DYNAMIC_IPADDR2.
ATM, I have a grep -R HELO_DYNAMIC_IPADDR2 * running from /
because that rule isn't present in any of the
.spamassassin(/rulesdujour) or /etc/mail/spamassassin directories.
If I can reduce that by about 1.2, that would fix the majority of
the FP's here. That rule even grabbed a message from a close
friend just 10 miles away last nite cause he'd also stuck a bunch
of !!! on the end of a happy new year subject line.
/usr/share/spamassassin/*.cf
The score you got seems higher than the 3.04 score. But that could
have been adjusted with 3.10 so I didn't comment.
{^_^}
Well, I've now defined it to be 2.8 in local.cf, and thats working
better but I feel I may have to reduce it another few tenths.
One of the problems I think I've detected is that fetchmail isn't doing
a 100% verbatum suck from vz, but seems to be deleting some of the
history near the top of the header, but how much is unk. I could copy
the mailfile off before kmail grabs it and zeros out the mailfile and
then compare messages to see exactly whats missing. That would define
where the loss is better than my SWAG's. I'll do that tomorrow.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: SA suddenly giving lots of FP's?
On Mon, 2006-01-02 at 22:19 -0500, Gene Heskett wrote:
On Sunday 01 January 2006 22:51, jdow wrote:
[...]
Anyway, the rule thats applying the 3.8 score is
HELO_DYNAMIC_IPADDR2.
ATM, I have a grep -R HELO_DYNAMIC_IPADDR2 * running from /
because that rule isn't present in any of the
.spamassassin(/rulesdujour) or /etc/mail/spamassassin directories.
If I can reduce that by about 1.2, that would fix the majority of
the FP's here. That rule even grabbed a message from a close
friend just 10 miles away last nite cause he'd also stuck a bunch
of !!! on the end of a happy new year subject line.
/usr/share/spamassassin/*.cf
The score you got seems higher than the 3.04 score. But that could
have been adjusted with 3.10 so I didn't comment.
{^_^}
Well, I've now defined it to be 2.8 in local.cf, and thats working
better but I feel I may have to reduce it another few tenths.
One of the problems I think I've detected is that fetchmail isn't doing
a 100% verbatum suck from vz, but seems to be deleting some of the
history near the top of the header, but how much is unk. I could copy
the mailfile off before kmail grabs it and zeros out the mailfile and
then compare messages to see exactly whats missing. That would define
where the loss is better than my SWAG's. I'll do that tomorrow.
to my knowledge, fetchmail doesn't remove any headers at all. Procmail
may be doing it or your MTA, depending upon how you are handling it.
after a few years of using fetchmail with 'proto imap' or 'proto
auto' (which used imap protocol), I ended up switching to 'proto pop3'
because the email 'accepted' by my isp included things like NUL
characters in the headers which caused fetchmail to gag on the mail.
When I switched to 'proto pop3' - the fetchmail politely handed the
email off to my MTA (postfix) and expunged it from my ISP and thus, it
ended up being a bit tidier. YMMV
Craig
Re: SA suddenly giving lots of FP's?
On Monday 02 January 2006 22:34, Craig White wrote:
On Mon, 2006-01-02 at 22:19 -0500, Gene Heskett wrote:
On Sunday 01 January 2006 22:51, jdow wrote:
[...]
Anyway, the rule thats applying the 3.8 score is
HELO_DYNAMIC_IPADDR2.
ATM, I have a grep -R HELO_DYNAMIC_IPADDR2 * running from /
because that rule isn't present in any of the
.spamassassin(/rulesdujour) or /etc/mail/spamassassin
directories. If I can reduce that by about 1.2, that would fix
the majority of the FP's here. That rule even grabbed a message
from a close friend just 10 miles away last nite cause he'd also
stuck a bunch of !!! on the end of a happy new year subject
line.
/usr/share/spamassassin/*.cf
The score you got seems higher than the 3.04 score. But that could
have been adjusted with 3.10 so I didn't comment.
{^_^}
Well, I've now defined it to be 2.8 in local.cf, and thats working
better but I feel I may have to reduce it another few tenths.
One of the problems I think I've detected is that fetchmail isn't
doing a 100% verbatum suck from vz, but seems to be deleting some
of the history near the top of the header, but how much is unk. I
could copy the mailfile off before kmail grabs it and zeros out the
mailfile and then compare messages to see exactly whats missing.
That would define where the loss is better than my SWAG's. I'll do
that tomorrow.
to my knowledge, fetchmail doesn't remove any headers at all.
Procmail may be doing it or your MTA, depending upon how you are
handling it.
Humm, AFAIK, fetchmail gets it from vz, writing it
to /var/spool/mail/gene
and kmail takes it from there. And I'm just using what the servers
support, which for vz is 99.9% of zip, plain text for everything.
Gmail's pop3 server at least uses ssl encryption for everything. OTOH,
I have my gmail prefs set to fwd it to vz, which is probably not the
'schmardtest' thing to do. I should cancel that, and let fetchmail
get it direct.
after a few years of using fetchmail with 'proto imap' or 'proto
auto' (which used imap protocol), I ended up switching to 'proto
pop3' because the email 'accepted' by my isp included things like
NUL characters in the headers which caused fetchmail to gag on the
mail. When I switched to 'proto pop3' - the fetchmail politely
handed the email off to my MTA (postfix) and expunged it from my ISP
and thus, it ended up being a bit tidier. YMMV
Well, my reasons for using fetchmail is that its configuration is
pretty brain dead simple. And kmail has this habit of forgetting to
hit the network fetch the mail itself if its config isn't refreshed
about 2x a week. Your basic old dogs (me at 71) and new tricks
story...
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: SA suddenly giving lots of FP's?
From: Gene Heskett [EMAIL PROTECTED]
On Monday 02 January 2006 00:50, Chris Purves wrote:
On Sunday 01 January 2006 12:24, Gene Heskett wrote:
On Saturday 31 December 2005 20:21, Chris Purves wrote:
On Sun, January 1, 2006 3:28 am, Gene Heskett said:
On Saturday 31 December 2005 13:38, Rick Macdougall wrote:
Gene Heskett wrote:
On Saturday 31 December 2005 12:42, Gene Heskett wrote:
This morning I'm going thru my JunqueMail folder and find
that about a dozen msgs to the OpenOffice list, 5 or 6 to the
fedeora list, and one to the gimp-print-devel list were
flaged and sorted as *SPAN*. With one exception, all
were in english.
Would help if you let us know what rules got hit.
Content analysis details: (5.7 points, 5.0 required)
pts rule name description
--
--
3.8 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious
hostname (IP addr
2)
1.8 FORGED_YAHOO_RCVD 'From' yahoo.com does not match
'Received' headers
-0.2 BAYES_40 BODY: Bayesian spam probability is
20 to 40%
[score: 0.3369]
0.2 DNS_FROM_RFC_ABUSE RBL: Envelope sender in
abuse.rfc-ignorant.org
Is that the entire header? You're missing a bunch of Received
lines.
FWIW, fetchmail sucks it and dumps it to /var/spool/mail/gene,
kmail sucks it from there. This is due to a bug in the kmail suck
from servers code of quite long duration, 3 or 4 years now. Humm,
headers do seem to be getting lost!
If some of the header is being removed, then that might be a problem.
That could definitely trigger the FORGED_YAHOO_RCVD rule if the
received header listing the Yahoo! server was removed.
In that event, how do I go about telling fetchmail that the mailfile it
generates in /var/spool/mail/gene is to be a verbatum copy of what was
sucked in the vz's server. My fetchmailrc is comparatively clean,
with no options that I know about set that would encourage the
shrunken headers. There are no OPTIONS currently defined.
Fetchmail is verbatim in the sense needed. Does fetchmail go through
the tool that fires off SpamAssassin or is this done up in KMail as
it reads? If so KMail may have sanitized off headers in much the same
way as Outlook or Exchange. This makes KMail pretty useless IMAO if
this is what they do.
{^_^}
Re: SA suddenly giving lots of FP's?
On Mon, 2006-01-02 at 22:57 -0500, Gene Heskett wrote: to my knowledge, fetchmail doesn't remove any headers at all. Procmail may be doing it or your MTA, depending upon how you are handling it. Humm, AFAIK, fetchmail gets it from vz, writing it to /var/spool/mail/gene perhaps you are using a customized configuration or perhaps you don't know what you are talking about...I don't know. man fetchmail...the first sentence... fetchmail is a mail-retrieval and forwarding utility; it fetches mail from remote mailservers and forwards it to your local (client) machine’s delivery system. your local machine's delivery system is AFAIK, your MTA. I am guessing that you have kmail retrive it either directly from /var/spool/mail/gene or using a pop3 or IMAP (I hope) connection. and kmail takes it from there. And I'm just using what the servers support, which for vz is 99.9% of zip, plain text for everything. Gmail's pop3 server at least uses ssl encryption for everything. OTOH, I have my gmail prefs set to fwd it to vz, which is probably not the 'schmardtest' thing to do. I should cancel that, and let fetchmail get it direct. after a few years of using fetchmail with 'proto imap' or 'proto auto' (which used imap protocol), I ended up switching to 'proto pop3' because the email 'accepted' by my isp included things like NUL characters in the headers which caused fetchmail to gag on the mail. When I switched to 'proto pop3' - the fetchmail politely handed the email off to my MTA (postfix) and expunged it from my ISP and thus, it ended up being a bit tidier. YMMV Well, my reasons for using fetchmail is that its configuration is pretty brain dead simple. And kmail has this habit of forgetting to hit the network fetch the mail itself if its config isn't refreshed about 2x a week. Your basic old dogs (me at 71) and new tricks story... I don't use kmail very often and when I do, it's via IMAP from my local server and it seems to work without fail. In fact, if Kmail wasn't reliable in retrieving email via POP3 or IMAP day in / day out, it would be fixed as those protocols are old enough, stable enough that I would expect any end user mail program to be sufficient to retrieve mail without resetting configurations at all. Now - if I recall correctly, you use stuff as root which is definitely not the recommended methodology and can be problematic with things like KDE. I don't do root logins. Craig
Re: SA suddenly giving lots of FP's?
From: Gene Heskett [EMAIL PROTECTED]
On Monday 02 January 2006 22:34, Craig White wrote:
On Mon, 2006-01-02 at 22:19 -0500, Gene Heskett wrote:
On Sunday 01 January 2006 22:51, jdow wrote:
[...]
Anyway, the rule thats applying the 3.8 score is
HELO_DYNAMIC_IPADDR2.
ATM, I have a grep -R HELO_DYNAMIC_IPADDR2 * running from /
because that rule isn't present in any of the
.spamassassin(/rulesdujour) or /etc/mail/spamassassin
directories. If I can reduce that by about 1.2, that would fix
the majority of the FP's here. That rule even grabbed a message
from a close friend just 10 miles away last nite cause he'd also
stuck a bunch of !!! on the end of a happy new year subject
line.
/usr/share/spamassassin/*.cf
The score you got seems higher than the 3.04 score. But that could
have been adjusted with 3.10 so I didn't comment.
{^_^}
Well, I've now defined it to be 2.8 in local.cf, and thats working
better but I feel I may have to reduce it another few tenths.
One of the problems I think I've detected is that fetchmail isn't
doing a 100% verbatum suck from vz, but seems to be deleting some
of the history near the top of the header, but how much is unk. I
could copy the mailfile off before kmail grabs it and zeros out the
mailfile and then compare messages to see exactly whats missing.
That would define where the loss is better than my SWAG's. I'll do
that tomorrow.
to my knowledge, fetchmail doesn't remove any headers at all.
Procmail may be doing it or your MTA, depending upon how you are
handling it.
Humm, AFAIK, fetchmail gets it from vz, writing it
to /var/spool/mail/gene
and kmail takes it from there. And I'm just using what the servers
support, which for vz is 99.9% of zip, plain text for everything.
With the fragment you posted fetchmail hands it off to whatever is
your sendmail tool on your system. That runs and places the mail in
your inbox. I didn't see a stanza like the following in your fetchmailrc
piece you posted: defaults mda /usr/bin/procmail -d gene
So precisely what runs spamassassin there?
{^_^}
Re: SA suddenly giving lots of FP's?
Gene Heskett wrote: In that event, how do I go about telling fetchmail that the mailfile it generates in /var/spool/mail/gene is to be a verbatum copy of what was sucked in the vz's server. My fetchmailrc is comparatively clean, with no options that I know about set that would encourage the shrunken headers. There are no OPTIONS currently defined. -sanitized of course--- poll incoming.verizon.net with proto pop3 user XXX with password is gene #options OPTIONS poll pop.gmail.com with proto pop3 user ZZ with password is gene options ssl # end of file - Or is there some option I need to set to make it do verbatum sucks? I think you should confirm that it is fetchmail that is removing headers. I use fetchmail myself and haven't had any problems. In the manual page there is an --invisible option that keeps fetchmail from inserting its own received header. You could try that. -- Good day, eh. Chris
Re: SA suddenly giving lots of FP's?
On Mon, 2006-01-02 at 20:16 -0800, jdow wrote: From: Gene Heskett [EMAIL PROTECTED] Fetchmail is verbatim in the sense needed. Does fetchmail go through the tool that fires off SpamAssassin or is this done up in KMail as it reads? If so KMail may have sanitized off headers in much the same way as Outlook or Exchange. This makes KMail pretty useless IMAO if this is what they do. I can find a lot to criticize about Outlook but I've not ever seen Outlook remove header information - but I don't have any Exchange Server installations which might be why. In Gene's case, he's probably got Kmail fetching directly from /var/spool/mail/gene without any pop3/imap server and thus not getting any additional header information and then the Kmail filtering is invoking spamassassin. I can't think of any reason not to do it that way, unless of course, he is doing all this as root. Craig
Re: SA suddenly giving lots of FP's?
On Monday 02 January 2006 23:16, jdow wrote:
From: Gene Heskett [EMAIL PROTECTED]
On Monday 02 January 2006 00:50, Chris Purves wrote:
On Sunday 01 January 2006 12:24, Gene Heskett wrote:
On Saturday 31 December 2005 20:21, Chris Purves wrote:
On Sun, January 1, 2006 3:28 am, Gene Heskett said:
On Saturday 31 December 2005 13:38, Rick Macdougall wrote:
Gene Heskett wrote:
On Saturday 31 December 2005 12:42, Gene Heskett wrote:
This morning I'm going thru my JunqueMail folder and find
that about a dozen msgs to the OpenOffice list, 5 or 6 to
the fedeora list, and one to the gimp-print-devel list were
flaged and sorted as *SPAN*. With one exception,
all were in english.
Would help if you let us know what rules got hit.
Content analysis details: (5.7 points, 5.0 required)
pts rule name description
--
--
3.8 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious
hostname (IP addr
2)
1.8 FORGED_YAHOO_RCVD 'From' yahoo.com does not match
'Received' headers
-0.2 BAYES_40 BODY: Bayesian spam probability is
20 to 40%
[score: 0.3369]
0.2 DNS_FROM_RFC_ABUSE RBL: Envelope sender in
abuse.rfc-ignorant.org
Is that the entire header? You're missing a bunch of Received
lines.
FWIW, fetchmail sucks it and dumps it to /var/spool/mail/gene,
kmail sucks it from there. This is due to a bug in the kmail
suck from servers code of quite long duration, 3 or 4 years now.
Humm, headers do seem to be getting lost!
If some of the header is being removed, then that might be a
problem. That could definitely trigger the FORGED_YAHOO_RCVD rule
if the received header listing the Yahoo! server was removed.
In that event, how do I go about telling fetchmail that the
mailfile it generates in /var/spool/mail/gene is to be a verbatum
copy of what was sucked in the vz's server. My fetchmailrc is
comparatively clean, with no options that I know about set that
would encourage the shrunken headers. There are no OPTIONS
currently defined.
Fetchmail is verbatim in the sense needed. Does fetchmail go through
the tool that fires off SpamAssassin or is this done up in KMail as
it reads? If so KMail may have sanitized off headers in much the same
way as Outlook or Exchange. This makes KMail pretty useless IMAO if
this is what they do.
{^_^}
Nope, its two seperate processes, Joanne. Fetchmail is run from
rc.local, and is totally independant of kmail. Where I made that
statement was that I was compareing an old message that kmail had
sucked directly, to the contents of the /var/spool/mail/gene file.
Kmail in turn, and completely asynchronously, grabs and processes
the /var/spool/mail/gene file and sorts it a bit, then calls
spamassasin on what I haven't sorted out, then looks at the output of
the spamassassin pipe when its done and finishes the sorting.
But it was obviously two seperate messages, hence the ambiguity from
that alone. Over the next few days I will stop the auto fwd to vz
from gmail so that I can set the fetchmail output to other than as
gene then send myself a message at the gmail address. As soon as
it comes back, copy it to a tmp file, wait for kmail to pick it up,
and then compare the contents of the tmp file with the message shown
me by kmail. Then stop the fetchmail scan of gmail, send another
message and look at it with the web interface before I tell kmail to
suck it directly. Somewhere in there, I hope to be able to red dot
the perp, if indeed there is one. I could very well be barking at the
moon and chaseing rabbits, but hopefully I'll also be a little smarter
too.
Right now I'm watching GA show the home team how its done. WV31-GA27,
but GA has closed the door on us after the first 15 minutes.
Seriously slammed it, and our guys are fumbling the ball away 4 times
now. Later, it looks like maybe we might pull one off, WV38-GA35,
1:45 to go with WV in possession. 1:10 left, new 1st down by WV. Rich
called for a fake punt and pulled it off very well. And with about 25
secs to go, GA walked out on the field to make it official, WV has won
the Sugar Bowl!
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: SA suddenly giving lots of FP's?
On Monday 02 January 2006 23:22, jdow wrote:
From: Gene Heskett [EMAIL PROTECTED]
On Monday 02 January 2006 22:34, Craig White wrote:
On Mon, 2006-01-02 at 22:19 -0500, Gene Heskett wrote:
On Sunday 01 January 2006 22:51, jdow wrote:
[...]
Anyway, the rule thats applying the 3.8 score is
HELO_DYNAMIC_IPADDR2.
ATM, I have a grep -R HELO_DYNAMIC_IPADDR2 * running from /
because that rule isn't present in any of the
.spamassassin(/rulesdujour) or /etc/mail/spamassassin
directories. If I can reduce that by about 1.2, that would fix
the majority of the FP's here. That rule even grabbed a
message from a close friend just 10 miles away last nite cause
he'd also stuck a bunch of !!! on the end of a happy new year
subject line.
/usr/share/spamassassin/*.cf
The score you got seems higher than the 3.04 score. But that
could have been adjusted with 3.10 so I didn't comment.
{^_^}
Well, I've now defined it to be 2.8 in local.cf, and thats
working better but I feel I may have to reduce it another few
tenths.
One of the problems I think I've detected is that fetchmail isn't
doing a 100% verbatum suck from vz, but seems to be deleting some
of the history near the top of the header, but how much is unk.
I could copy the mailfile off before kmail grabs it and zeros out
the mailfile and then compare messages to see exactly whats
missing. That would define where the loss is better than my
SWAG's. I'll do that tomorrow.
to my knowledge, fetchmail doesn't remove any headers at all.
Procmail may be doing it or your MTA, depending upon how you are
handling it.
Humm, AFAIK, fetchmail gets it from vz, writing it
to /var/spool/mail/gene
and kmail takes it from there. And I'm just using what the servers
support, which for vz is 99.9% of zip, plain text for everything.
With the fragment you posted fetchmail hands it off to whatever is
your sendmail tool on your system. That runs and places the mail in
your inbox. I didn't see a stanza like the following in your
fetchmailrc piece you posted: defaults mda /usr/bin/procmail -d
gene
So precisely what runs spamassassin there?
{^_^}
kmail, by pipeing it thru via a filter setting of Pipe Through, using
spamc -u gene
spamd of course is from rc3.d linkage.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
