Re: Does anyone known the braindead anti-spam software MagicSpam ?
Matus UHLAR - fantomas wrote: On 10.11.10 08:23, Per Jessen wrote: I got the following reject this morning: book...@example.com: host mail.example.com[1.2.3.4] said: 550 Dynamic Style reverse DNS IP=[212.25.14.40].Rejected by MagicSpam 1.0.4-9.1 (http://www.magicspam.com/). 40.14.25.212.in-addr.arpa. 3600 IN CNAME 40.32-63.14.25.212.in-addr.arpa. well, the 40.32-63.14.25.212.in-addr.arpa is surely dynamic-looking ;-) I know :-) /Per Jessen, Zürich
Re: pattern problem
On Tue, 9 Nov 2010 12:48:52 +0100 Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 05.11.10 12:28, RW wrote: It's not all that safe to deep-parse XBL because it's mostly dynamically assigned IP addresses. On Fri, 5 Nov 2010 14:38:45 +0100 Matus UHLAR - fantomas uh...@fantomas.sk wrote: the PBL from ZEN is mostly dynamically assigned. the XBL means exploits block list, and doing deep-parsing on it should be really safe. On 05.11.10 14:47, RW wrote: Most XBL entries are compromised PCs, most of which have dynamic addresses which can be reassigned. On last-external that doesn't matter. The FP rate for deep XBL is, in general, much higher. can IP addresses in PBL get onto XBL? Yes, some servers reject on XBL, but not on PBL. I've seen DCC_CHECK hit on some kind of funny story being massivelly sent over the net. They were bulk and they would apparently hit PBL if anyone sent them from such IP. Haven't you encountered these? Not recently and it's only adding 1 point to the 1.1 from DCC.
Re: Does anyone known the braindead anti-spam software MagicSpam ?
On 11/10/2010 6:32 AM, Michael Scheidell wrote: On 11/10/10 2:45 AM, Matus UHLAR - fantomas wrote: On 10.11.10 08:23, Per Jessen wrote: I got the following reject this morning: book...@example.com: host mail.example.com[1.2.3.4] said: 550 Dynamic Style reverse DNS IP=[212.25.14.40].Rejected by MagicSpam 1.0.4-9.1 (http://www.magicspam.com/). 40.14.25.212.in-addr.arpa. 3600 IN CNAME 40.32-63.14.25.212.in-addr.arpa. well, the 40.32-63.14.25.212.in-addr.arpa is surely dynamic-looking ;-) as expected for classless DNS CIDR subdelegation, and valid according to rfrc's. magicspam didn't resolve the cname (either of them I suspect). not sure if I would use a cnam for quarantine.spamcheck.net. .. just put a second record in the zone file. This looks like RDNS delegation to me, allowing a statically assigned block of addresses from an ISP to control their own RDNS lookups.The owner of the address block wouldn't be able to modify the upstream's RDNS zone files so that's why the upstream has put in CNAME records, to force the resolver to the owners zone file. and if it is... most certainly not a dynamic ip. -lee host -t ptr 212.25.14.40 40.14.25.212.in-addr.arpa is an alias for 40.32-63.14.25.212.in-addr.arpa. 40.32-63.14.25.212.in-addr.arpa domain name pointer quarantine.spamchek.net. # host -t a quarantine.spamchek.net quarantine.spamchek.net is an alias for thorium.enidan.ch. thorium.enidan.ch has address 212.25.14.40 # host -t a thorium.enidan.ch thorium.enidan.ch has address 212.25.14.40
Re: pattern problem
On Tue, 9 Nov 2010 12:48:52 +0100 Matus UHLAR - fantomas uh...@fantomas.sk wrote: can IP addresses in PBL get onto XBL? On 10.11.10 08:46, RW wrote: Yes, some servers reject on XBL, but not on PBL. I was more interested iun spamhaus practice. And not rejecting mail from PBL at SMTP level is imho strange... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 99 percent of lawyers give the rest a bad name.
Re: sa-learn problems and comprehension question
On Tue, 2010-11-09 at 22:57 -0800, Karl Meyer wrote:
This is dangerous. With lots of mail in the (Maildir?) folder, shell
expansion *quickly* will exceed the command line length limit.
The trailing dot also looks bad.
This is a good argument. I' ll think about that. The folder is a cyrus Imap
folder. I used the [0-9]*. expression, because each cyrus folder contains
messages with numbered filename with a trailing dot and four cyrus.* files
(cache, index,...).
On 10.11.10 11:12, Martin Gregorie wrote:
Use find:
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -exec sa_learn {} \;
which is a bit slower but avoids the command line overflow by running
sa_learn on every matching file.
you can use xargs then to calling sa-learn too often. xargs can push only as
much parameters as fits.
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -print |xargs sa-learn
(well, add --spam or --ham to sa-learn of course)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I wonder how much deeper the ocean would be without sponges.
Re: sa-learn problems and comprehension question
On Tue, 2010-11-09 at 22:57 -0800, Karl Meyer wrote:
This is dangerous. With lots of mail in the (Maildir?) folder, shell
expansion *quickly* will exceed the command line length limit.
The trailing dot also looks bad.
This is a good argument. I' ll think about that. The folder is a cyrus Imap
folder. I used the [0-9]*. expression, because each cyrus folder contains
messages with numbered filename with a trailing dot and four cyrus.* files
(cache, index,...).
Use find:
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -exec sa_learn {} \;
which is a bit slower but avoids the command line overflow by running
sa_learn on every matching file.
Martin
Re: Does anyone known the braindead anti-spam software MagicSpam ?
Lee Dilkie wrote: On 11/10/2010 6:32 AM, Michael Scheidell wrote: On 11/10/10 2:45 AM, Matus UHLAR - fantomas wrote: On 10.11.10 08:23, Per Jessen wrote: I got the following reject this morning: book...@example.com: host mail.example.com[1.2.3.4] said: 550 Dynamic Style reverse DNS IP=[212.25.14.40].Rejected by MagicSpam 1.0.4-9.1 (http://www.magicspam.com/). 40.14.25.212.in-addr.arpa. 3600 IN CNAME 40.32-63.14.25.212.in-addr.arpa. well, the 40.32-63.14.25.212.in-addr.arpa is surely dynamic-looking ;-) as expected for classless DNS CIDR subdelegation, and valid according to rfrc's. magicspam didn't resolve the cname (either of them I suspect). not sure if I would use a cnam for quarantine.spamcheck.net. .. just put a second record in the zone file. This looks like RDNS delegation to me, allowing a statically assigned block of addresses from an ISP to control their own RDNS lookups. Yep, that is precisely what it is. /Per Jessen, Zürich
Re: Does anyone known the braindead anti-spam software MagicSpam ?
On 11/10/10 2:45 AM, Matus UHLAR - fantomas wrote: On 10.11.10 08:23, Per Jessen wrote: I got the following reject this morning: book...@example.com: host mail.example.com[1.2.3.4] said: 550 Dynamic Style reverse DNS IP=[212.25.14.40].Rejected by MagicSpam 1.0.4-9.1 (http://www.magicspam.com/). 40.14.25.212.in-addr.arpa. 3600 IN CNAME 40.32-63.14.25.212.in-addr.arpa. well, the 40.32-63.14.25.212.in-addr.arpa is surely dynamic-looking ;-) as expected for classless DNS CIDR subdelegation, and valid according to rfrc's. magicspam didn't resolve the cname (either of them I suspect). not sure if I would use a cnam for quarantine.spamcheck.net. .. just put a second record in the zone file. host -t ptr 212.25.14.40 40.14.25.212.in-addr.arpa is an alias for 40.32-63.14.25.212.in-addr.arpa. 40.32-63.14.25.212.in-addr.arpa domain name pointer quarantine.spamchek.net. # host -t a quarantine.spamchek.net quarantine.spamchek.net is an alias for thorium.enidan.ch. thorium.enidan.ch has address 212.25.14.40 # host -t a thorium.enidan.ch thorium.enidan.ch has address 212.25.14.40 -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: sa-learn problems and comprehension question
On Tue, 2010-11-09 at 22:57 -0800, Karl Meyer wrote:
--showdots /var/spool/imap/user/kmeyer/[0-9]*. amavis
^^^
This is dangerous. With lots of mail in the (Maildir?) folder, shell
expansion *quickly* will exceed the command line length limit.
The trailing dot also looks bad.
This is a good argument. I' ll think about that. The folder is a cyrus Imap
folder. I used the [0-9]*. expression, because each cyrus folder contains
messages with numbered filename with a trailing dot and four cyrus.* files
(cache, index,...).
Not Maildir, and passing the dir itself doesn't seem like an option
either in the Cyrus case. Man pages to the rescue.
The Description section of the sa-learn man page holds this.
Note that csh-style globbing in the mail folder names is supported; in
other words, listing a folder name as * will scan every folder that
matches. See Mail::SpamAssassin::ArchiveIterator for more details.
So, something similar to the above is possible. However, you will need
to escape or quote the globbing, to prevent the su-spawned shell from
expanding it (as the above does), but pass the glob to sa-learn.
A word of caution. There is no move command with IMAP. Instead, it is
copy and delete. Or rather mark-for-deletion, since there is no delete
command either. That's expunge.
That's right. But is this a problem?
First, I learn ham from the inbox folder, then spam from the junk folder. If
a mail is moved to the junk folder meanwhile and no expunge was done, then
it's not relearned as ham again and learned from the junk folder as spam
newly.
That is a lot of unnecessary work, constantly re-learning messages.
Also, there's a race condition. So your user knows, spam will be learned
periodically. And that month worth of spam backlog in that folder is
ugly. Time to clean it up, and expunge. The Inbox though is precious.
Lots of important stuff and cute kitten attachments. Unless the Inbox is
expunged, too, deleted spam from the Inbox will be re-trained next
time. The copy in the spam folder is no more, to correct that false
training by design.
(Caveat: I don't know how Cyrus handles deletion or flagging mail as
such. It is not Maildir.)
Using the Inbox rather than a dedicated ham folder therefore is NOT a
good idea.
The problem is, that I can't persuade about 120 users to store all their ham
below a defined folder. They want to sort their mails into several folders
they created by their own.
You should be fine with some initial training of hand-sorted ham in a
dedicated folder. Then let auto-learn kick in.
Some script magic, using 'find' to collect the last n hours worth of ham
and spam might be an option, too. Used with the sa-learn -f option. Once
again, please do read the... man page.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: sa-learn problems and comprehension question
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -exec sa_learn {} \;
which is a bit slower but avoids the command line overflow by running
sa_learn on every matching file.
A bit slower. Periodically re-learning the entire Inbox of 100+ users,
spawning a full Perl process for every single mail...
you can use xargs then to calling sa-learn too often. xargs can push only as
much parameters as fits.
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -print |xargs sa-learn
Definitely! Without it, the box will be burning in hell, doomed to
constantly spawn Perl processes until the end of time.
Using the find result to populate a list in a temporary file, and use
that with sa-learn -f is even better. A single Perl process per learning
iteration.
Also, since this is not Maildir and the above path looks suspiciously to
contain directories (mail sub-folders), the find -maxdepth option will
be required to prevent learning *all* the user's mail.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: sa-learn problems and comprehension question
On Wed, 2010-11-10 at 08:56 +0100, Marcin Mirosław wrote:
W dniu 2010-11-10 07:37, Karl Meyer pisze:
But the 15 new messages weren't learnd yet.
I had 10 messages in my inbox and run sa-learn on that folder. Then I got 15
different new messages and re-run sa-learn again. But it said that it
learned from 0 messages.
How many messages did sa-learn claim to have examined?
Do you run SA from smtp server? Porbably yes, bayes autolearned
this/those(15) emails earlier, while was called from MTA.
To verify this assumption, and test your sa-learn command, try --forget
and then --ham again.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: sa-learn problems and comprehension question
On Wed, 2010-11-10 at 18:16 +0100, Karsten Bräckelmann wrote:
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -exec sa_learn {} \;
which is a bit slower but avoids the command line overflow by running
sa_learn on every matching file.
A bit slower. Periodically re-learning the entire Inbox of 100+ users,
spawning a full Perl process for every single mail...
Indeed, but when I wrote that I had no idea that the directory had
permanent content. I was under the impression that its content would be
deleted or archived after it had been learned and the next run would be
dealing with new messages.
Martin
Re: sa-learn problems and comprehension question
On Wed, 2010-11-10 at 17:48 +, Martin Gregorie wrote:
On Wed, 2010-11-10 at 18:16 +0100, Karsten Bräckelmann wrote:
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -exec sa_learn {} \;
which is a bit slower but avoids the command line overflow by running
sa_learn on every matching file.
A bit slower. Periodically re-learning the entire Inbox of 100+ users,
spawning a full Perl process for every single mail...
Indeed, but when I wrote that I had no idea that the directory had
permanent content. I was under the impression that its content would be
deleted or archived after it had been learned and the next run would be
dealing with new messages.
Oh, I didn't mean to bitch at you personally. :)
I just thought the issues should be pointed out and clearly documented,
rather than keeping it in the archives without a warning.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: sa-learn problems and comprehension question
On Wed, 2010-11-10 at 19:01 +0100, Karsten Bräckelmann wrote:
On Wed, 2010-11-10 at 17:48 +, Martin Gregorie wrote:
On Wed, 2010-11-10 at 18:16 +0100, Karsten Bräckelmann wrote:
find /var/spool/imap/user/kmeyer/ -name '[0-9]*.' -exec sa_learn {} \;
which is a bit slower but avoids the command line overflow by running
sa_learn on every matching file.
A bit slower. Periodically re-learning the entire Inbox of 100+ users,
spawning a full Perl process for every single mail...
Indeed, but when I wrote that I had no idea that the directory had
permanent content. I was under the impression that its content would be
deleted or archived after it had been learned and the next run would be
dealing with new messages.
Oh, I didn't mean to bitch at you personally. :)
I just thought the issues should be pointed out and clearly documented,
rather than keeping it in the archives without a warning.
Good point, and one well worth making clear.
Martin
The Inbox problem (was: sa-learn problems and comprehension question)
On Wed, 2010-11-10 at 18:04 +0100, Karsten Bräckelmann wrote:
On Tue, 2010-11-09 at 22:57 -0800, Karl Meyer wrote:
Using the Inbox rather than a dedicated ham folder therefore is NOT a
good idea.
The problem is, that I can't persuade about 120 users to store all their ham
below a defined folder. They want to sort their mails into several folders
they created by their own.
You should be fine with some initial training of hand-sorted ham in a
dedicated folder. Then let auto-learn kick in.
Other than the already established issues of delete and expunge, and
re-learning the same messages over and over again, there is another
problem with the learn from Inbox approach.
You would, effectively, implement a rather poor auto-learning mechanism.
The auto-learning available in SA does have quite some constraints, to
prevent bad training. Automatic, non-supervised training of the Inbox
does not have *any* such precaution, and instead blindly trusts the
initial classification.
You cannot tell your users to collect hand-classified ham? Do you really
believe you can tell your users, not *ever* to just delete the
occasional spam in their Inbox, rather than moving it for training? So
the user is in a hurry, he's late for the meeting, the project deadline
is close, the day's been a disaster anyway and the headache... No, don't
want that junk. Delete. Off there goes the spam into the great bin-
bucket, after it has been learned as ham.
And then there's the college next cubicle, on vacation for three weeks.
Meanwhile, all the FNs piling up in his Inbox are being trained as ham.
Despite the fact that all that would have been needed to properly
classify them are a bit of Bayes training to cross the threshold. As
spam, though, not ham -- bootstrapping as a dis-service for everyone
else in the office.
No, automatically training the Inbox is not a safe approach.
I recommend reading the sections Getting Started and Effective Training
in the sa-learn man page.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
SA and SELinux
I've enabled SA on my RE 5 ES server by putting the following line in /etc/procmailrc INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc and I start the SA daemon. No on my server I have a hard requirement to run SELinux. I cannot turn that off. I find that when i enable SA with SELinux turned on, my CPU rate sky rockets eventually forcing my system to stop responding. I've seen this thread several times through Google searches however I did not find a solution. Please help, thanks is advance J.
Re: Bad pattern in HELO_DYNAMIC_IPADDR check?
On Thu, 2010-10-28 at 11:25 +0200, Angel L. Mateo wrote:
We are having a problema with one of our users that all his email was
marked as spam. The problem is that all his emails has the
HELO_DYNAMIC_IPADDR (or HELO_DYNAMIC_IPADDR2) check, because
spamassassin thinks that the connection used the IP address in the helo
commando, but not.
On Thu, 2010-10-28 at 06:03 -0700, John Hardin wrote:
You should look at your trusted_networks settings if this is a local
network client, and should consider using authenticated SMTP if it's a
remote trusted client.
This is the problem.
With an authenticated submission, the mail should hit ALL_TRUSTED
instead. Since it's an MUA sending the mail, untrusted and external
relays should be empty.
Scanning outbound mail? Which other rules hit?
Posting full headers from a sample message would help.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA and SELinux
Do not reply, if you want to start a new thread. Changing the Subject
and removing the quote does not make it a new mail. It still is a
reply, indicated by the In-Reply-To and References headers. You just
hijacked a thread.
On Wed, 2010-11-10 at 11:39 -0800, John Williams wrote:
I've enabled SA on my RE 5 ES server by putting the following line in
/etc/procmailrc
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
and I start the SA daemon.
No on my server I have a hard requirement to run SELinux. I cannot turn that
off. I find that when i enable SA with SELinux turned on, my CPU rate sky
rockets eventually forcing my system to stop responding. I've seen this
thread
several times through Google searches however I did not find a solution.
Since you cannot disable SELinux, how do you know it is related to
SELinux? You did not test it without, did you?
If this issue is related to SELinux, and occurs only with it enabled,
wouldn't that make it an SELinux problem? Did you report it to RH, ask
their Enterprise support, or check RH bugzilla?
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
