Re: Fwd: SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On 08-Mar-10 23:51, Brian wrote:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind. Unless you know different?
You don't let messages even GET to SA until they pass sane checks (like
reject_non_fqdn_sender and reject_non_fqdn_recipient).
Natively It can happily do it after accepting the mail (hint - a bit
late then...) with an after queue filter, but this is prone to the
phenomenon that is 'Postscatter' -sending the message back to the
(often) forged sender.
You never send back a spam that you accepted. You reject it, deliver it,
or discard it. *Never* bounce backscatter.
Postfix, much that I love it, has some gaping holes in it's feature set.
No, it really doesn't.
It really is an MTA for the 1990's. The need to bolt in an Sendmail
Milter to get it to reject Spamassassin tagged mail at the SMTP stage is
a glaring example IHMO - But all this is very much OT.
If you want milters, postfix has supported them for years. They are not
necessary in this case.
--
There's a race of men that don't fit in, A race that can't stay
still So they break the hearts of kith and kin, And they roam
the world at will.
Re: Fwd: SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 02:36 -0700, LuKreme wrote:
On 08-Mar-10 23:51, Brian wrote:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind. Unless you know different?
You don't let messages even GET to SA until they pass sane checks (like
reject_non_fqdn_sender and reject_non_fqdn_recipient).
Which spam happily passes, hence the need for Spamassassin to do content
inspection - unless you are telling me Postfix can offer the same level
of content inspection as Spamassassin? (Clue: stock answer - 'Postfix
is an MTA, it does not do..)
Natively It can happily do it after accepting the mail (hint - a bit
late then...) with an after queue filter, but this is prone to the
phenomenon that is 'Postscatter' -sending the message back to the
(often) forged sender.
You never send back a spam that you accepted. You reject it, deliver it,
or discard it. *Never* bounce backscatter.
Which Postfix *CANNOT* do with Spamassassin *UNLESS* you use the milter.
Unless you know otherwise...
Postfix, much that I love it, has some gaping holes in it's feature set.
No, it really doesn't.
Yes it does, see above. Another example header and body checks that
don't support any kind of whitelisting. No native support for DKIM, no
sensible native content filters.
It really is an MTA for the 1990's. The need to bolt in an Sendmail
Milter to get it to reject Spamassassin tagged mail at the SMTP stage is
a glaring example IHMO - But all this is very much OT.
If you want milters, postfix has supported them for years. They are not
necessary in this case.
OK Lukreme. Tell me how you get Postfix to reject spam on content AT
SMTP TIME - NOT AFTER ACCEPTING IT when Spamassassin decides that it is
SPAM. Such a case where the incoming mail meets all other SMTP criteria
(has PTR, PTR rrdns matches, not listed on any RBL, is to a valid
recipient). Let's say, for the sake of simplicity, it matches a a
Spamassassin body based metarule. How do you do this natively in Postfix
without the use of a Milter or Policy Daemon of some kind? I'd really
like to know.
RE: 90_sare_freemail.cf.sare.sa-update.dostech.net
From: Yet Another Ninja [mailto:sa-l...@alexb.ch] On 3/4/2010 7:34 PM, Rosenbaum, Larry M. wrote: From: Karsten Bräckelmann [mailto:guent...@rudersport.de] On Thu, 2010-03-04 at 00:12 +0100, Yet Another Ninja wrote: On 3/3/2010 10:09 PM, Karsten Bräckelmann wrote: On Wed, 2010-03-03 at 15:38 -0500, Rosenbaum, Larry M. wrote: Is there still a reason for this update channel? 90_sare_freemail.cf.sare.sa-update.dostech.net Or is it now built in to SA v3.3.0? ^ 20_freemail.cf and 20_freemail_domains.cf ? 90_sare_freemail.cf is still supported by for ppl who haven't upgraded to SA 3.3.x Thanks for that addition and confirmation of status. :) The original question and hence my answer was specifically about 3.3.x, though, and whether it still is needed from external sources with that version. I'm doing the same additions to 20_freemail_domains.cf Later this year, 90_sare_freemail.cf, will become unsupported. Anybody using SA 3.3.x should drop 90_sare_freemail.cf usage. Thanks, but I'm confused, as there are domains in 90_sare_freemail.cf that are not currently in 20_freemail_domains.cf. Hi Larry... Never got around to do the diff... your msg triggered :-) Unless I borked it, it should now included the missing from 90_sare_freemail.cf I still don't see the domains in 20_freemail_domains.cf. Thanks, Larry
Re: [sa] Re: End of Thread [Was: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt]
On Tue, 9 Mar 2010, Ned Slider wrote: It's clear you either haven't read or haven't understood what Kai wrote, which btw was spot on. More attitude. Yeesh. Kai has an opinion. And in fairness, I give his arguments some serious weight. It's not black-n-white. But this attitude that he/you have the 'best' solution is just yeah YAWN. End of Thread. Hope so.
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote: I'm glad you like amavis-new. I found it to scale poorly and a single, common point of failure and fall into the category that is commonly called 'bloat'. It does illustrate all the missing features of Postfix in quite a handy example - so thanks for mentioning it. there's a whole bunch of ways of getting the resilience and performance you require out of amavisd-new. Their list will no doubt accept a polite enquiry.
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
* Kai Schaetzl mailli...@conactive.com: package doesn't. For good reasons. We don't want bloatware and we may want updates on that plugin much more often then we want updates on the MTA. I really do not want to update my MTA time and again because it's got a new policy feature. Postfix has two interfaces for this, milter and policy daemons. And content_filter and smtpd_proxy_filter -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On 2010-03-09 13:51, Brian wrote: On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. GROAN *** WE KNOW THAT! Look at the title and read the post Ralf. The point is you need to use a milter or proxy/policy daemon to do this with Postfix. The point being 'Why does it not natively support this functionality in the year 2010?' Answer: Because Weitse (AKA 'God') says so, so you all jump and say 'yes sir, no sir, three bags full sir'. So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? It's 2010, spam accounts for 9x% of mail so please share with me how you can do this with just a minor config change with Postfix. The caveat you can't use the milter, you can't use 'amavis-crashalot' and a 250 must not be given if Spamassassin marks it as spam. I can't find it in your book anywhere old chap.. I'm happy to stay on the Postfix 'merry-go-round' for an answer, or we can just agree Postfix can't easily do this and move on and stop flogging this dead horse :-) good idea - Here, its totally off topic. Move it to Postfix lists
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 13:00 +, Robert Brooks wrote: Brian wrote: On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? personally I use smtpd_proxy_filter to do EXACTLY this. And without an external program.. ? Clue 'YOU CAN'T'.
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote: On Tue, 2010-03-09 at 14:04 +0100, Yet Another Ninja wrote: to stay on the Postfix 'merry-go-round' for an answer, or we can just agree Postfix can't easily do this and move on and stop flogging this dead horse :-) good idea - Here, its totally off topic. Move it to Postfix lists Better idea, just drop it! Postfix lacks features and it's a fair statement. It's fair to say Postfix lacks features only you seem to want because everyone else understands how to reject mail in Postfix. There are enough arse lickers here without going to the Temple of Weiste to visit the disciples without the socks. Perhaps if people stopped kissing arse and grovelling so much Postfix would have some sensible features - but that ain't gonna happen any time soon. [Rhetorical] - why do you feel the need to bring that sort of offensive tone to a public mailing list?
Re: 90_sare_freemail.cf.sare.sa-update.dostech.net
On 2010-03-09 15:48, Rosenbaum, Larry M. wrote: From: Yet Another Ninja [mailto:sa-l...@alexb.ch] On 3/4/2010 7:34 PM, Rosenbaum, Larry M. wrote: From: Karsten Bräckelmann [mailto:guent...@rudersport.de] On Thu, 2010-03-04 at 00:12 +0100, Yet Another Ninja wrote: On 3/3/2010 10:09 PM, Karsten Bräckelmann wrote: On Wed, 2010-03-03 at 15:38 -0500, Rosenbaum, Larry M. wrote: Is there still a reason for this update channel? 90_sare_freemail.cf.sare.sa-update.dostech.net Or is it now built in to SA v3.3.0? ^ 20_freemail.cf and 20_freemail_domains.cf ? 90_sare_freemail.cf is still supported by for ppl who haven't upgraded to SA 3.3.x Thanks for that addition and confirmation of status. :) The original question and hence my answer was specifically about 3.3.x, though, and whether it still is needed from external sources with that version. I'm doing the same additions to 20_freemail_domains.cf Later this year, 90_sare_freemail.cf, will become unsupported. Anybody using SA 3.3.x should drop 90_sare_freemail.cf usage. Thanks, but I'm confused, as there are domains in 90_sare_freemail.cf that are not currently in 20_freemail_domains.cf. Hi Larry... Never got around to do the diff... your msg triggered :-) Unless I borked it, it should now included the missing from 90_sare_freemail.cf I still don't see the domains in 20_freemail_domains.cf. If you've done the diff, pls post the missing domains.
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 13:24 +, Robert Brooks wrote: Brian wrote: On Tue, 2010-03-09 at 13:00 +, Robert Brooks wrote: Brian wrote: On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? personally I use smtpd_proxy_filter to do EXACTLY this. And without an external program.. ? Clue 'YOU CAN'T'. so your objection is that there's an external program between Postfix and Spamassasin? Personally I find amavisd-new does a fine job. That Postfix doesn't directly present an email directly to spamassassin is fine with me, since I wish to do a bunch of other checks (AV for instance). Do I object to there being a program to interface Postfix to Spamassassin - not necessarily. It would be nicer to not have to do it this way and the clue as to why is in the title of the thread. Postfix remains an MTA for the 1990's as it is, but that's just a view. If 9x% of the traffic an MTA gets to see is unwanted SPAM, it's not unreasonable to expect a solid and reliable built in mechanism to reject it. It's a Postfix ethos to not accept mail for 'x' reason but the old 'it's only an MTA' arguement comes out time and time again by a small group of people who are so far up the arse of WT, you would think they were his piles! Put it this way. I were buying a cheap car 20 years ago I would have expected to add my own alarm and immobiliser to deal with threats and vulnerabilities - after all a car is just a car, not a security system. In 2010 even a cheap car has a built in immobiliser as it has adapted to the threat and expectations of customers. I'm glad you like amavis-new. I found it to scale poorly and a single, common point of failure and fall into the category that is commonly called 'bloat'. It does illustrate all the missing features of Postfix in quite a handy example - so thanks for mentioning it. This thread has run on past it's bedtime and has already degenerated beyond useful to Spamassassin users. I'm sure the asshats and asslickers will continue to populate it and argue the toss, but the facts are stark. Postfix lacks basic features for the age. Put it side by side with Exim and the 'it's only an MTA' thing falls flat on it's face. Good luck squabbling about it girls LOL.
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote on Tue, 09 Mar 2010 06:51:45 +:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind.
You have a very simplistic view on how mail transportation works and maybe
on how software works.
First: Postfix is a M Transport A and not a M Rejection A. It's common
practice in software design to have plugins do work that the core
package doesn't. For good reasons. We don't want bloatware and we may want
updates on that plugin much more often then we want updates on the MTA. I
really do not want to update my MTA time and again because it's got a new
policy feature. Postfix has two interfaces for this, milter and policy
daemons. That's more than other MTA's have and gives you just every option
you want to have. It's the only correct way to do this.
Second: you are completely misguided in your wish to reject mail after
SMTP data stage. I gather you have a biblical tooth-for-tooth approach
here. This is not good guidance. It does not make any sense to process a
complete message and then reject it. If it's not done correctly it even
violates RFCs. Doing that processing at the SMTP stage may be feasible for
home and soho use, but not for ISP use. Processing a message takes CPU
power and precious SMTP time. Doing that at SMTP stage means you cannot
take in as much mail as you could. It also means that the sending MTA
cannot send as much mail as it could. So, only disadvantages for everyone,
and still *no* advantage. There are other reasons not to do this, for
instance legal ones.
The idea is not to punish the other side because it sends spam. You do
not only not punish the other side, you punish yourself. The idea behind a
rejection at SMTP stage is twofold: avoid unnecessary processing and avoid
unncessary traffic. None of that is achieved if you take a whole message,
scan it and reject it at SMTP stage. So, what a clever mail system does is
reject as much spam as it possibly can without getting too many FPs by
technical and policy reasons and queue the remaining, say, 10% for full
message inspection. That's the only effective way to deal with this on a
larger scale.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote: On Tue, 2010-03-09 at 13:00 +, Robert Brooks wrote: Brian wrote: On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? personally I use smtpd_proxy_filter to do EXACTLY this. And without an external program.. ? Clue 'YOU CAN'T'. so your objection is that there's an external program between Postfix and Spamassasin? Personally I find amavisd-new does a fine job. That Postfix doesn't directly present an email directly to spamassassin is fine with me, since I wish to do a bunch of other checks (AV for instance).
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 14:45 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? Well, I'm using amavisd-new for that, since I'm also scanning the mails for viruses: smtpd pass - - - - - smtpd -o receive_override_options=no_address_mappings -o smtpd_proxy_filter=[127.0.0.1]:10025 -o smtpd_proxy_options=speed_adjust and in amavisd-new I'm using: $final_spam_destiny = D_REJECT; And the bit where I said 'not using amavis / policy deamon / milter' escaped you where? For someone that wrote a book you don't seem to read well ;-)
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
* Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Am 09.03.2010 13:17, schrieb Ralf Hildebrandt: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. Hi Ralf, think -x is temp safe with for small tests if using reject_non_fqdn_recipient i.e smtpd_recipient_restrictions = reject_unknown_recipient_domain, reject_non_fqdn_recipient, permit_mynetworks, --test mail from: 250 2.1.0 Ok rcpt to: root+:|touch /tmp/foo 504 5.5.2 root+:|touch /tmp/foo: Recipient address rejected: need fully-qualified address 221 2.0.0 Bye anyway the code should be fixed asap running without -x should be ok temp too as it will use the default spamassassin user config i wrote a bug to savannah -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [sa] Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 9 Mar 2010, Brian wrote: I'm happy to stay on the Postfix 'merry-go-round' for an answer, or we can just agree Postfix can't easily do this and move on and stop flogging this dead horse :-) I use Mail Avenger for a front end SMTP Says it all - Charles
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
* Brian brel.astersik100...@copperproductions.co.uk: So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? Well, I'm using amavisd-new for that, since I'm also scanning the mails for viruses: smtpd pass - - - - - smtpd -o receive_override_options=no_address_mappings -o smtpd_proxy_filter=[127.0.0.1]:10025 -o smtpd_proxy_options=speed_adjust and in amavisd-new I'm using: $final_spam_destiny = D_REJECT; -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian wrote: And the bit where I said 'not using amavis / policy deamon / milter' escaped you where? For someone that wrote a book you don't seem to read well ;-) I want you to shoot that target *pulls out gun* Without a gun *pulls out crossbow* Without a crossbow *pulls out bow* No archery *pulls out camera* No pictures What exactly *DO* you want?? Write you own MTA then. - -- David Morton morto...@dgrmm.net Morton Software Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLllmwUy30ODPkzl0RAl2YAJ90Xyb6A+1u9XBNl/OWCsUQKVxcvwCgz7lb OzHjCCJ0Fsg4uo4Mp68KrWw= =+Rsw -END PGP SIGNATURE-
Re: End of Thread [Was: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt]
Brian wrote:
On Tue, 2010-03-09 at 12:35 +0100, Kai Schaetzl wrote:
Brian wrote on Tue, 09 Mar 2010 06:51:45 +:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind.
You have a very simplistic view on how mail transportation works and maybe
on how software works.
First: Postfix is a M Transport A and not a M Rejection A. It's common
practice in software design to have plugins do work that the core
package doesn't.
YAWN - it's not about how software is constructed or what it does, but
more about what Postfix is incapable of doing and the old stock trollop
that is rolled out 'That's not the job of the MTA'. That answer was just
about good enough in the 1990's, but it's lame now.
It's clear you either haven't read or haven't understood what Kai wrote,
which btw was spot on.
End of Thread.
Re: End of Thread [Was: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt]
On Tue, 2010-03-09 at 12:16 +, Ned Slider wrote:
Brian wrote:
On Tue, 2010-03-09 at 12:35 +0100, Kai Schaetzl wrote:
Brian wrote on Tue, 09 Mar 2010 06:51:45 +:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind.
You have a very simplistic view on how mail transportation works and maybe
on how software works.
First: Postfix is a M Transport A and not a M Rejection A. It's common
practice in software design to have plugins do work that the core
package doesn't.
YAWN - it's not about how software is constructed or what it does, but
more about what Postfix is incapable of doing and the old stock trollop
that is rolled out 'That's not the job of the MTA'. That answer was just
about good enough in the 1990's, but it's lame now.
It's clear you either haven't read or haven't understood what Kai wrote,
which btw was spot on.
End of Thread.
It's clear that you arn't able to answer the question. Fact, Postfix
lacks features.
End of thread
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 12:35 +0100, Kai Schaetzl wrote:
Brian wrote on Tue, 09 Mar 2010 06:51:45 +:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind.
You have a very simplistic view on how mail transportation works and maybe
on how software works.
First: Postfix is a M Transport A and not a M Rejection A. It's common
practice in software design to have plugins do work that the core
package doesn't.
YAWN - it's not about how software is constructed or what it does, but
more about what Postfix is incapable of doing and the old stock trollop
that is rolled out 'That's not the job of the MTA'. That answer was just
about good enough in the 1990's, but it's lame now.
In the year 2010 it is not unreasonable to expect the MTA that takes
responsibility for accepting a message to make reasonable checks about
the validity or content of that message. This is very much a 1980's
programming view of telling the user what they can have, rather than
implementing the basic features the user requires.
It's interesting to note that Barracuda Networks had to write their own
MTA* to put in front of Postfix to support all the features it could not
offer.
Exim seems to offer far more than Postfix will ever bleat about
supporting but perhaps the University of Cambridge have a 'simplistic
view on how mail transportation ... and software works'
This is all very OT and pointless. Anyone who has dealt with Postfix in
terms of years knows all the flaws, such as rejecting message with
Spamassassin at SMTP needs a milter/PD - and that this milter has (on
top of a few minor bugs) now been found to have a serious vulnerability.
*I use the term 'write their own mta' in the loosest sense of the word
as I have been unable to source the origin of the BSMTP that they use.
Please feel free to carry on flogging a dead horse ;-)
EOT (was: Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt)
On Tue, 2010-03-09 at 13:20 +, Brian wrote:
Move it to Postfix lists
Better idea, just drop it! Postfix lacks features and it's a fair
statement.
Brian, you just missed your opportunity to do what you propose.
There are enough arse lickers here without going to the Temple of Weiste
to visit the disciples without the socks.
Perhaps if people stopped kissing arse and grovelling so much Postfix
would have some sensible features - but that ain't gonna happen any time
soon.
This was uncalled for. There is absolutely no reason for foul language
in this thread. Stop it. And feel free to unsubscribe, if there are too
many arse lickers around here for your delicate self.
End of Thread.
--
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; }}}
SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Tue, 9 Mar 2010, Kai Schaetzl wrote: Second: you are completely misguided in your wish to reject mail after SMTP data stage. You may certainly argue for YOUR preference (and I emphasise *preference*) for the most 'efficient' way to run an SMTP server, but there is nothing sufficiently 'wrong' with rejecting mail after DATA that you can use the term 'misguided'. All this term implies is your attitude Apart from this, you make some nice arguments, but again, you seem to have a bias that weighs them too heavily. It does not make any sense to process a complete message and then reject it. If this were true, no one would have added 'header' and 'body' checks to the postfix configuration and no one would have been jumping through hoops to find ways to integrate SA into the front end of MTA's Indeed, it makes far LESS sense to have a system accept mail but send it to a spam folder. That practice leaves the sender with the mistaken impression that their mail was sucessfully delivered. And argue as you will, there is simply no way to get a broad user base to adopt the habit of reviewing a spam folder. I mean the whole point of filtering is that the user no longer has to sift through a pile of junk, right? Processing a message takes CPU power and precious SMTP time. Doing that at SMTP stage means you cannot take in as much mail as you could. It also means that the sending MTA cannot send as much mail as it could. Think about that statement twice. It IS correct, but it is an argument FOR processing mail at SMTP time. A legitimate outbound SMTP sever is *never* as busy as an incoming mail server. So a leigitimate server will not suffer *any* penalty from my system introducing a 5-6 second delay into the SMTP transaction. But a spammer's zombie is trying to pump out mail as fast as it can. The spambot will be slowed down. That is a GOOD thing. Yes? :) There are other reasons not to do this, for instance legal ones. Again, you are quoting arguments that favor SMTP reject. It is better to reject a mail, so that legitimate senders know it, rather than have them believe it was delivered when it was sent into a spam folder, perhaps suffer consequences and then sue the recipient. Sure, OUR butts will be covered by our user agreements, but only if we have jumped through hoops so that the user cannot claim they did not know about their spam folder. But in the real world, even if we don't get sued, we get a lot of people complaining that they didn't know about the optional spam folder on our system that the user turned ON themselves! Now we use a spam folder for 'borderline' spams that score 5-10. The rest get rejected at SMTP time. But still I get these occasional complaints It's just the way users are LOL The idea is not to punish the other side because it sends spam. If they send spam, I'm happy to see them punished. If they send legitimate mail, they should not be punished for the actions of spammers by having to GUESS whether their mail made it through. The idea behind a rejection at SMTP stage is twofold: avoid unnecessary processing and avoid unncessary traffic. None of that is achieved if you take a whole message, scan it and reject it at SMTP stage. Well, firstly, ALL of that is achieved *regardless* of these arguments because the helo/rbl checks are done BEFORE the DATA stage. The only 'loss' of time is on mail that you were going to have to fully process anyway because it made it past those checks. No loss to me. A few seconds delay on the SMTP connectino that saves a legitimate sender worry without incurring the 'cost' of backscatter, and actually might slow spammers down a bit. Maybe I personally don't gain any time. But maybe by the end of the day the spammer doesn't get to send quite as many e-mails, and someone out there enjoys less traffic on their server! - Charles
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. GROAN *** WE KNOW THAT! Look at the title and read the post Ralf. The point is you need to use a milter or proxy/policy daemon to do this with Postfix. The point being 'Why does it not natively support this functionality in the year 2010?' Answer: Because Weitse (AKA 'God') says so, so you all jump and say 'yes sir, no sir, three bags full sir'. So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? It's 2010, spam accounts for 9x% of mail so please share with me how you can do this with just a minor config change with Postfix. The caveat you can't use the milter, you can't use 'amavis-crashalot' and a 250 must not be given if Spamassassin marks it as spam. I can't find it in your book anywhere old chap.. I'm happy to stay on the Postfix 'merry-go-round' for an answer, or we can just agree Postfix can't easily do this and move on and stop flogging this dead horse :-)
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 14:04 +0100, Yet Another Ninja wrote: to stay on the Postfix 'merry-go-round' for an answer, or we can just agree Postfix can't easily do this and move on and stop flogging this dead horse :-) good idea - Here, its totally off topic. Move it to Postfix lists Better idea, just drop it! Postfix lacks features and it's a fair statement. There are enough arse lickers here without going to the Temple of Weiste to visit the disciples without the socks. Perhaps if people stopped kissing arse and grovelling so much Postfix would have some sensible features - but that ain't gonna happen any time soon.
Re: End of Thread [Was: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt]
Brian wrote on Tue, 09 Mar 2010 12:53:31 +: End of thread Obvbiously not for you. Well. Thank you so much for educating us clueless people. Thank you and good night. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 13:38 +, Ned Slider wrote: Brian wrote: On Tue, 2010-03-09 at 14:04 +0100, Yet Another Ninja wrote: to stay on the Postfix 'merry-go-round' for an answer, or we can just agree Postfix can't easily do this and move on and stop flogging this dead horse :-) good idea - Here, its totally off topic. Move it to Postfix lists Better idea, just drop it! Postfix lacks features and it's a fair statement. It's fair to say Postfix lacks features only you seem to want because everyone else understands how to reject mail in Postfix. They do? Again - without using a milter or Policy Deamon remind me how postfix can reject mail c/o spamassassin before it accepts it? Be my guest. As you've already told me 'everyone else understands how to reject mail in Postfix' perhaps you Ned would just answer that for me? It's OK to say 'it can't' and that it lacks this feature. There are enough arse lickers here without going to the Temple of Weiste to visit the disciples without the socks. Perhaps if people stopped kissing arse and grovelling so much Postfix would have some sensible features - but that ain't gonna happen any time soon. [Rhetorical] - why do you feel the need to bring that sort of offensive tone to a public mailing list? And you think you have the right to declare other peoples threads as dead? WTF do you think *you* are just because you don't like what is written?
Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
Charles, just a quick answer as we are really OT. It all simply boils down to (quoting me): avoid unnecessary processing and avoid unncessary traffic. and I might add now: with the least disadvantages on both sides. Assess that and you find it doesn't make sense to spam-scan messages and reject them in/after DATA stage in a real world scenario. It makes only sense if you are die-hard spam-fighter who wants to retaliate and doesn't bother if it makes sense. And that is indeed very misguided. Most if not all of your arguments are arguments for spam-filtering mail, not in favor of rejection at DATA stage. Last, keep in mind that filtering mechanisms in whatever stage are not solely meant for rejecting or spam-fighting, they are for *filtering* and then assigning appropriate actions - which often have nothing to do with spam/malware detection at all. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote: On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. So Ralf - author of 'The Postfix Book', can you please now tell me how to get Postfix to reject mail before it accepts it and gives a 250 - When Spamassassin tags it as spam? personally I use smtpd_proxy_filter to do EXACTLY this.
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, Mar 09, 2010 at 08:22:41AM -0600, David Morton wrote: What exactly *DO* you want?? He's a well known troll here, yet for some reason people want to amuse him and fill out the list with pointless arguments. PLEASE ignore him, since noone has taken the job of unsubscribing him yet.
Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Tue, Mar 9, 2010 at 08:03, Kai Schaetzl mailli...@conactive.com wrote: Charles, just a quick answer as we are really OT. It all simply boils down to (quoting me): avoid unnecessary processing and avoid unncessary traffic. and I might add now: with the least disadvantages on both sides. Assess that and you find it doesn't make sense to spam-scan messages and reject them in/after DATA stage in a real world scenario. To you. Not to everyone who does the analysis. We all have our valid biases, our valid assumptions (that follow from both those biases, and from our locally defined goals and objectives that come from business cases, theory, etc.). They do not promote a single unified opinion about the best way to approach these problems. Anyone who says they have a single, one size fits all, solution to that analysis is a snake-oil salesman. For example, there are actually some people on the planet that intentionally silently drop email messages. It's like they WANT their email servers to be defective-by-design. Clearly, their local analysis derived a different conclusion than any intelligent person's conclusion. It makes only sense if you are die-hard spam-fighter who wants to retaliate and doesn't bother if it makes sense. Bzzt. Wrong. It's for anyone who wants to reject messages, so as to reduce the amount of crud that they are storing, backing up, handling/tracking, and/or quarantining. The other options for that goal (bouncing, silently dropping) are not acceptable. Rejecting after SMTP (bouncing): backscatter, bad idea Dropping messages silently: RFC violation, and thus defective-by-design mail service Rejecting before accepting (during SMTP): proper behavior for handling messages for which you don't wish to accept responsibility And that is indeed very misguided. Retaliation is misguided. Spam scanning during the SMTP session is not. Most if not all of your arguments are arguments for spam-filtering mail, not in favor of rejection at DATA stage. I don't need to make arguments for/about rejection vs filtering. I do what makes the most sense to my local case. And I obey RFCs and decent net behavior. I only answer to outside agencies for the latter 2 (RFC compliance and net behavior). I do not answer to outside agencies for what makes the most sense to my local case, therefore, I have no requirement to make arguments about rejection vs filtering, as long as I am RFC compliant, and do not do odious things like create backscatter. In my local case, we reject messages for which we have a very high degree of confidence about the likelihood that a message is spam/virus/phishing/etc. We do RBL rejection during the SMTP session (for RBLs that we feel are reliable, within our comfort zone of reliability). We do ClamAV scanning during the SMTP session (using a variety of ClamAV signature sources, again within our comfort zone of reliability). And we do SpamAssassin scanning during the SMTP session (rejecting messages that score above a certain threshold; merely tagging messages under that threshold -- and that threshold is, again, set by our comfort zone of reliabilty). Last, keep in mind that filtering mechanisms in whatever stage are not solely meant for rejecting or spam-fighting, they are for *filtering* and then assigning appropriate actions And one of those appropriate actions can be reject the message. As I suggested above, if you don't do the scanning during the SMTP session, then you can't reject the message. You can only bounce it (causing backscatter), drop it (making your mail server defective), or deliver it (to the inbox, or to a quarantine). Not everyone wants to store, backup, and handle lots of crud ... nor do they all want to manage (and, typically, pay for) a quarantine system ... or they want to reduce the crud that they store, backup, handle, and/or quarantine. The only acceptable (to those of us who care about RFCs and proper net behavior) mechanism for doing that: reject it during the SMTP session. If you don't care about reducing the load of crud you deal with it, fine. That's your local consideration, and is by no means a universal, nor superior, conclusion. It is not misguided, nor bad analysis, to come to a different conclusion.
Re: SMTP REJECT after DATA
Kai Schaetzl wrote: Assess that and you find it doesn't make sense to spam-scan messages and reject them in/after DATA stage in a real world scenario. I hesitate to jump onto this firing range, but Kai has always seemed reasonable. We have very real world experience doing this sort of thing and I disagree with Kai's statement for incoming email. FWIW, I DO agree for outgoing email while talking with a user's mail client (or the spammer's malware client running on a user's PC) But for incoming email, although I sincerely wish we could reject spam before/in the DATA stage all the time, SpamAssassin is not perfect. AND we offer Block and Pass lists to our users and they make mistakes too. PLUS, there is absolutely no accounting for taste and we have some users that WANT their Lotto Pick Newsletter in spite of the stratospheric scores. So even if we can decide an email is spam before the DATA stage, it makes no difference since we have to store the thing for a while anyway in case the user wants to look for something caught that shouldn't be. Cheers, -- Andy Dorman Ironic Design, Inc. AnteSpam.com, HomeFreeMail.com, ComeHome.net
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Kai Schaetzl wrote:
Brian wrote on Tue, 09 Mar 2010 06:51:45 +:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind.
You have a very simplistic view on how mail transportation works and maybe
on how software works.
First: Postfix is a M Transport A and not a M Rejection A. It's common
practice in software design to have plugins do work that the core
package doesn't. For good reasons. We don't want bloatware and we may want
updates on that plugin much more often then we want updates on the MTA.
Kai, I think it is you who has a simplistic view of how mail
transportation works.
Yes it is true that MTA's need to support plugins. But they need to do
it for a different reason - there are ideas that need to be tested out.
Take for example greylisting. The fact is that when greylisting was
first proposed, nobody wanted it in the MTA. It was too new, and people
did not know how it would work out in practice. There were stability
concerns and concerns with how large round-robin mailserver arrays would
handle it.
Thus it was the Right Thing to implement greylisting in a milter when it
was first proposed.
The same thing goes for issuing REJECTs during the data phase of the
SMTP transaction. The same issues and concerns applied.
However, once these techniques were proven out in practice, at that
point CONTINUING to keep them separated in a plugin or milter becomes
a liability. You now have the big concern that since the development
of the MTA and the milter/plugin proceeds separately, you can have
sync problems where you make a chance in the MTA and the plugin breaks.
Sure, the plugin group may correct the problem but that is not a lot
of consolation to the admin who just happens to regenerate or update
his servers during the time that the plugin is broken and a patch is
in process. And what if the plugin author is tired of working on it
and the plugin project - which is providing a valuable service - starts
to languish?
There have been many plugins and milters developed over the years that
have proven out to be, in a word, stupid. That is why it was a good
thing that they were never part of the MTA code. In that case it was
good to keep them separate. But, there's also many plugins that have
proven out to be critical and useful, and the MTA benefits when that
code is folded into the MTA.
The development and user community can get a sense of how these things
can be separated, and what a good separation is. For example it's clear
that spam content-filtering is far to complex to insert into an MTA
that's why it's good to have a separate project, like SA or dspam or
something else. But, simply dropping the SMTP transaction in the middle
of a data phase due to certain conditions being met - perhaps a keyword
in the body of the message, perhaps a slow or failed DNS lookup of the
sender's IP - that is not complex and has proven out over time to
be fine, and really should be part of the MTA for stability reasons.
I
really do not want to update my MTA time and again because it's got a new
policy feature. Postfix has two interfaces for this, milter and policy
daemons. That's more than other MTA's have and gives you just every option
you want to have. It's the only correct way to do this.
No, it's not. There's plenty of correct ways to separate new/untested
functionality from the core proven/tested functionality in an MTA. Your
trying to frame an argument of where you want this dividing line based
on the capabilities of existing code, which is stupid. You are NOT
taking an unbiased look at all of the tasks that a modern mailserver
needs to do and trying to make a logical division of those tasks, then
modifying the MTA code to suit the division, which is the right way to
do it. Instead you are taking some structural decisions made in the
design of an MTA years ago and using them to frame your world view of
how e-mail works in the modern world.
It's no wonder your frustrated. Your like the guy with the Model T
trying to argue that highway speed limits should be 35Mph because that's
as fast as a Model T ever was able to go - and the Model T was the
greatest car ever built and every car following it should be just like it.
Second: you are completely misguided in your wish to reject mail after
SMTP data stage.
No, you are completely misguided in your wish to NOT do the only logical
thing to do to handle spam.
I gather you have a biblical tooth-for-tooth approach
here. This is not good guidance. It does not make any sense to process a
complete message and then reject it. If it's not done correctly it even
violates RFCs. Doing that processing at the SMTP stage may be feasible for
home and soho use, but not for ISP use.
Also quite wrong.
Processing a message takes CPU
power and precious SMTP
Re: SMTP REJECT after DATA
Charles Gregory wrote: On Tue, 9 Mar 2010, Kai Schaetzl wrote: Second: you are completely misguided in your wish to reject mail after SMTP data stage. You may certainly argue for YOUR preference (and I emphasise *preference*) for the most 'efficient' way to run an SMTP server, but there is nothing sufficiently 'wrong' with rejecting mail after DATA that you can use the term 'misguided'. All this term implies is your attitude Apart from this, you make some nice arguments, but again, you seem to have a bias that weighs them too heavily. It does not make any sense to process a complete message and then reject it. If this were true, no one would have added 'header' and 'body' checks to the postfix configuration and no one would have been jumping through hoops to find ways to integrate SA into the front end of MTA's Indeed, it makes far LESS sense to have a system accept mail but send it to a spam folder. That practice leaves the sender with the mistaken impression that their mail was sucessfully delivered. And argue as you will, there is simply no way to get a broad user base to adopt the habit of reviewing a spam folder. I mean the whole point of filtering is that the user no longer has to sift through a pile of junk, right? Processing a message takes CPU power and precious SMTP time. Doing that at SMTP stage means you cannot take in as much mail as you could. It also means that the sending MTA cannot send as much mail as it could. Think about that statement twice. It IS correct, but it is an argument FOR processing mail at SMTP time. A legitimate outbound SMTP sever is *never* as busy as an incoming mail server. So a leigitimate server will not suffer *any* penalty from my system introducing a 5-6 second delay into the SMTP transaction. But a spammer's zombie is trying to pump out mail as fast as it can. The spambot will be slowed down. That is a GOOD thing. Yes? :) There are other reasons not to do this, for instance legal ones. Again, you are quoting arguments that favor SMTP reject. It is better to reject a mail, so that legitimate senders know it, rather than have them believe it was delivered when it was sent into a spam folder, perhaps suffer consequences and then sue the recipient. Sure, OUR butts will be covered by our user agreements, but only if we have jumped through hoops so that the user cannot claim they did not know about their spam folder. But in the real world, even if we don't get sued, we get a lot of people complaining that they didn't know about the optional spam folder on our system that the user turned ON themselves! Now we use a spam folder for 'borderline' spams that score 5-10. The rest get rejected at SMTP time. But still I get these occasional complaints It's just the way users are LOL This is one of the stupidest arguments in this thread NOBODY is legally required to accept e-mail. That is a crock of baloney. A mailserver operator MAY have a contract to accept all e-mail with a specific entity, but if the server admin rejects spam then ALL they are POSSIBLY in violation of is simple breech of contract - and they can merely argue that spam is NOT by definition e-mail since it lacks any usable information, it is an abuse of the e-mail system. Thus that would have to be a server contract that specifically defined receiving spam - quite an odd contract at that. It is NOT illegal to break a contract. It it were then the prisons would be stuffed with people who defaulted on their credit cards. It is a civil matter handled by civil proceedings. Ted
problem with the Bayesian filter
My Bayesian filter keeps getting screwed up and causing mail flow to stop. The problem seems to be expiring tokens out of the database. My expiry setting is set to 200,000. I've tried many different settings for this but they all seem to behave about the same. Auto learn is also on. When this happens the mysqld service eats up loads of CPU and stops responding to requests from Amavisd-new. Since Amavisd-new is expecting information from mysqld it stops the mail flow. I attached the output from the 'show processlist' command, one query seems to have been ran for 12hours without stopping. Is there other useful information I should get from the server? I have a script set up to fix this state, collecting other information would not be difficult. Using default MySQL settings (probably going to start playing with that today). Any suggestions would be greatly appreciated, my experience with MySQL is very limited. Thanks, Curtis ÿþI d U s e r H o s t d b C o m m a n d T i m e S t a t e I n f o 5 1 2 6 2 5 b a y e s l o c a l h o s t b a y e s Q u e r y 4 4 8 7 8 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 7 9 6 4 b a y e s l o c a l h o s t b a y e s Q u e r y 1 6 0 3 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 8 5 3 4 b a y e s l o c a l h o s t b a y e s Q u e r y 1 3 0 3 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 9 0 0 7 b a y e s l o c a l h o s t b a y e s Q u e r y 9 9 6 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 9 3 8 5 b a y e s l o c a l h o s t b a y e s Q u e r y 6 9 5 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 9 6 8 6 b a y e s l o c a l h o s t b a y e s Q u e r y 3 9 2 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 9 9 0 5 b a y e s l o c a l h o s t b a y e s Q u e r y 9 0 S e n d i n g d a t a S E L E C T c o u n t ( * ) \ n F R O M b a y e s _ t o k e n \ n W H E R E i d = ' 1 ' \ n A N D a t i 5 6 9 9 4 2 b a y e s l o c a l h o s t b a y e s Q u e r y 0 U p d a t i n g U P D A T E b a y e s _ t o k e n S E T a t i m e = ' 1 2 6 8 1 4 4 6 2 1 ' W H E R E i d = ' 1 ' A N D t o k e n I N ( ' ) L D h ' , ' S ? ? m ? ' , ' ? z ? ? ? ' , ' O 5 6 9 9 4 3 b a y e s l o c a l h o s t b a y e s Q u e r y 0 s t a t i s t i c s S E L E C T R P A D ( t o k e n , 5 , ' ' ) , s p a m _ c o u n t , h a m _ c o u n t , a t i m e \ n F R O M b a y e s _ t o k e n \ n 5 6 9 9 4 4 b a y e s l o c a l h o s t b a y e s Q u e r y 0 U p d a t i n g U P D A T E b a y e s _ t o k e n S E T a t i m e = ' 1 2 6 8 1 4 4 6 2 4 ' W H E R E i d = ' 1 ' A N D t o k e n I N ( ' ? . ? F ' , ' ? ? 1 G ' , ' H ? F g Z ' , ' ? : 5 6 9 9 4 5 b a y e s l o c a l h o s t b a y e s Q u e r y 0 S e n d i n g d a t a S E L E C T R P A D ( t o k e n , 5 , ' ' ) , s p a m _ c o u n t , h a m _ c o u n t , a t i m e \ n F R O M b a y e s _ t o k e n \ n 5 6 9 9 4 7 b a y e s
Re: problem with the Bayesian filter
On 3/9/10 1:24 PM, Curtis MacDuff wrote: My Bayesian filter keeps getting screwed up and causing mail flow to stop. The problem seems to be expiring tokens out of the database. My expiry setting is set to 200,000. I've tried many different settings for this but they all seem to behave about the same. Auto learn is also on. don't use auto expire? turn it off? then in nightly cronjob, stop amavis, manually expire it? and for sql, you are using the MySql.pm, not the generic Sql.pm for bayes, right? -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, 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: problem with the Bayesian filter
On Tue, 09 Mar 2010 10:24:19 -0800 Curtis MacDuff curtis.macd...@pspinc.com wrote: My Bayesian filter keeps getting screwed up and causing mail flow to stop. The problem seems to be expiring tokens out of the database. My expiry setting is set to 200,000. I've tried many different settings for this but they all seem to behave about the same. Auto learn is also on. When this happens the mysqld service eats up loads of CPU and stops responding to requests from Amavisd-new. Since Amavisd-new is expecting information from mysqld it stops the mail flow. I attached the output from the 'show processlist' command, one query seems to have been ran for 12hours without stopping. Try running sa-learn --force-expire from cron and turn-off auto-expiry
Re: [sa] Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Tue, 9 Mar 2010, Kai Schaetzl wrote: and you find it doesn't make sense to spam-scan messages and reject them in/after DATA stage in a real world scenario. You ignore my arguments. Hardly surprising. You reword yours, but say nothing new. It makes only sense if you are die-hard spam-fighter who wants to retaliate... I stated my objectives and they have nothing to do with this pathetic straw-man argument. Most if not all of your arguments are arguments for spam-filtering mail, not in favor of rejection at DATA stage. How is that English-as-a-second-language class coming along? I refuse to bore this group by repeating arguments that you so grossly mis-categorize in a feeble attempt to promote your point of view. Last, keep in mind that filtering mechanisms in whatever stage are not solely meant for rejecting or spam-fighting, they are for *filtering* and then assigning appropriate actions - which often have nothing to do with spam/malware detection at all. Now THAT is off-topic. We are discussing the use of SA at SMTP time. Please stay on-topic for this group, and for this thread. If you actually care to continue, I expect a reasonable response to my arguments about rejection being better than bouncing or silent diversion. Geez, you didn't even try to advocate a system of notices to the user to overcome the 'silent' portion of that argument. Do I have to argue both sides for you? :) - C
Re: [sa] Re: SMTP REJECT after DATA
On Tue, 9 Mar 2010, Andy Dorman wrote: So even if we can decide an email is spam before the DATA stage, it makes no difference since we have to store the thing for a while anyway in case the user wants to look for something caught that shouldn't be. (nod) To rely on this methodology requires that you *rely* upon your users to apply a conscientious and consistent system of reviewing their spam trap/folder on a regular basis. If you have this, then without sarcasm I would say you are very fortunate. But in a system like mine where educating ignorant users is difficult at best, it feels a bit too dangerous to allow (too much) mail to be received and held without notice to the sender. And unfortunately SMTP protocols do not contain a code to tell the sender that mail was 'accepted but held for review'. The only way to do that is with a separate mail, and that leads back to the backscatter horrorshow, which I am quite sure you would never advocate :) So for us (and we recognize not for everyone), the policy/practice we have chosen is the most workable and efficient. I think the only reason I leaped into this thread was because of the overbearing attitudes that seemed to completely ignore the fundamental notion of YMMV - C
Re: [sa] Re: SMTP REJECT after DATA
On Tue, 9 Mar 2010, David Morton wrote: Charles Gregory wrote: Indeed, it makes far LESS sense to have a system accept mail but send it to a spam folder. Maybe in your particular situation, but you can hardly apply that to everyone (nod) It was subject to the conditions I consider 'wide spread' but by no means universal: the failure of users to review spamtraps. - since we are supporting several large companies that find it more acceptable to quarantine mail than to reject it, and *have* trained their employees to look in a spam folder in the rare case that it is needed. Stop it! You're making me jealous! LOL If postfix and amavisd-new have improvements lately that allow for efficient rejecting at SMTP time, that's great! The only efficiency to be gained is to reject as much as possible after the RCPT_TO, before accepting DATA. But for systems like mine, with lousy user cooperation, rejecting some of the mail after DATA is still the best option. Again, I emphasise 'some', and only speak out because someone is describing any approach other than their own as 'misguided'. You are not misguided, and neither am I. We just have different situations. Hmm... policy. Sounds a lot like a feature of postfix, doesn't it? LOL... And not at all 'misguided' :) - C
Re: [sa] Re: SMTP REJECT after DATA
On Tue, 9 Mar 2010, Ted Mittelstaedt wrote: There are other reasons not to do this, for instance legal ones. Again, you are quoting arguments that favor SMTP reject. It is better to reject a mail, so that legitimate senders know it, rather than have them believe it was delivered when it was sent into a spam folder... This is one of the stupidest arguments in this thread Well, hey, now that we've got *that* off our chest NOBODY is legally required to accept e-mail. That is a crock of baloney. Well then it's a good thing I didn't say that, isn't it? It is NOT illegal to break a contract. It's called 'fraud'. Look it up. - C
Re: problem with the Bayesian filter
Curtis MacDuff wrote on Tue, 09 Mar 2010 10:24:19 -0800: My Bayesian filter keeps getting screwed up and causing mail flow to stop. The problem seems to be expiring tokens out of the database. My expiry setting is set to 200,000. I've tried many different settings for this but they all seem to behave about the same. Auto learn is also on. 200.000 is rather low for my taste. Stop the automatic expiration and run it manually, then you will see if there is a problem. After that, keep doing it manually overnight. Those queries are abbreviated, so it's not clear what they are doing. Is this copied from PHPMyAdmin? Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: problem with the Bayesian filter
On Tue, 9 Mar 2010, Curtis MacDuff wrote: When this happens the mysqld service eats up loads of CPU and stops responding to requests from Amavisd-new. Verify your schema, and that you're not missing any indexes. And, as others have suggested, turn off auto-expiry and expire from a cron job scheduled at a time when your imbound email volume is low. -- 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 --- Failure to plan ahead on someone else's part does not constitute an emergency on my part. -- David W. Barts in a.s.r --- 5 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: problem with the Bayesian filter
I've tried the manual idea with the --force-expire before. Had the same problem doing it this way, unless its required to stop Amavis during this process? You seemed to have hit the nail on the head though with the Sql module bit: bayes_store_module Mail::SpamAssassin::BayesStore::SQL I'll be changing that to MySQL instead ... Kai, I'd agree 200,000 is low. Now that I've found the above I'll probably change it to 500,000. On 3/9/2010 10:45 AM, Michael Scheidell wrote: On 3/9/10 1:24 PM, Curtis MacDuff wrote: My Bayesian filter keeps getting screwed up and causing mail flow to stop. The problem seems to be expiring tokens out of the database. My expiry setting is set to 200,000. I've tried many different settings for this but they all seem to behave about the same. Auto learn is also on. don't use auto expire? turn it off? then in nightly cronjob, stop amavis, manually expire it? and for sql, you are using the MySql.pm, not the generic Sql.pm for bayes, right? -- Curtis MacDuff curtis.macd...@pspinc.com PSP: Focus on your business, not your IT 1404 140th Place NE, Bellevue, WA 98007 USA http://www.pspinc.com DISCLAIMER: This information is confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, please disregard and destroy this email and its content. Thank you.
Re: [sa] Re: SMTP REJECT after DATA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Gregory wrote: You are not misguided, and neither am I. We just have different situations. Hmm... policy. Sounds a lot like a feature of postfix, doesn't it? LOL... And not at all 'misguided' :) Wait, stop the presses! An agreement has been reached! LOL - -- David Morton morto...@dgrmm.net Morton Software Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLlq6ZUy30ODPkzl0RAvL/AJoDEFFBCC6l8kKuwK2p+8ZvrTBXagCgiWBx Wa+O9oaUQiKkYtz8QpvgwI4= =V1z8 -END PGP SIGNATURE-
Re: problem with the Bayesian filter
On 9.3.2010 20:24, Curtis MacDuff wrote: My Bayesian filter keeps getting screwed up and causing mail flow to stop. The problem seems to be expiring tokens out of the database. My expiry setting is set to 200,000. I've tried many different settings for this but they all seem to behave about the same. Auto learn is also on. When this happens the mysqld service eats up loads of CPU and stops responding to requests from Amavisd-new. Since Amavisd-new is expecting information from mysqld it stops the mail flow. I attached the output from the 'show processlist' command, one query seems to have been ran for 12hours without stopping. Is there other useful information I should get from the server? I have a script set up to fix this state, collecting other information would not be difficult. Using default MySQL settings (probably going to start playing with that today). Any suggestions would be greatly appreciated, my experience with MySQL is very limited. If you are using MyISAM (the default) engine in MySQL tables, try to change it to InnoDB (much better in table locking, InnoDB has per row locks while MyISAM always locks the whole table making concurrent access a pain). SQL alter table table_name Engine = InnoDB ; Do this for all SpamAssassin tables. -- http://www.iki.fi/jarif/ I've touch'd the highest point of all my greatness; And from that full meridian of my glory I haste now to my setting. I shall fall, Like a bright exhalation in the evening And no man see me more. -- Shakespeare signature.asc Description: OpenPGP digital signature
Re: [sa] Re: SMTP REJECT after DATA
Charles Gregory wrote: On Tue, 9 Mar 2010, Ted Mittelstaedt wrote: There are other reasons not to do this, for instance legal ones. Again, you are quoting arguments that favor SMTP reject. It is better to reject a mail, so that legitimate senders know it, rather than have them believe it was delivered when it was sent into a spam folder... This is one of the stupidest arguments in this thread Well, hey, now that we've got *that* off our chest NOBODY is legally required to accept e-mail. That is a crock of baloney. Well then it's a good thing I didn't say that, isn't it? I never said YOU said it. Since clearly you didn't start tossing around the term legal and you were arguing against it, why the hell are you now deciding to defend such a stupid, idiotic, ignorant, moronic usage of the term now? It is NOT illegal to break a contract. It's called 'fraud'. Look it up. No, sorry, it's NOT fraud. Fraud requires proving an intentional misrepresentation. Breaking a contract does not imply that the contract was entered into with an intent to break it. As I said, the example would be a civil dispute, not criminal. Ted
Re: Low scores
Just wanted to add that this particular line is incorrect: meta SC_HAM (USER_IN_WHITELIST||USER_IN_DEF_WHITELIST|| USER_IN_ALL_SPAM_TO||NO_RELAYS||ALL_TRUSTED||USER_IN_BLACKLIST_TO|| USER_IN_BLACKLIST) That will have Blacklisted email filters classified as ham. - Julian On Sun, Feb 24, 2008 at 8:07 AM, Micah Anderson mi...@riseup.net wrote: On Sun, 24 Feb 2008 02:15:24 +0100, Matthias Leisi wrote: Micah Anderson schrieb: | [surprisingly low scores] | The spams can be pulled from here: http://micah.riseup.net/spams Most (all?) of the samples are forwarded through some debian.org mechanism. In order for blacklists to take full effect, you should configure your trust path (trusted_networks etc) accordingly. My trusted_networks is set to: trusted_networks 202.12.162. trusted_networks 10.0. trusted_networks 10.8.0. The first is trusting everything in that IP space, which we control, the second is a private network, and the third is a private network. Am I specifying those incorrectly perhaps? I'm also short-circuiting on trusted-relay chained messages, using the following: meta SC_HAM (USER_IN_WHITELIST||USER_IN_DEF_WHITELIST|| USER_IN_ALL_SPAM_TO||NO_RELAYS||ALL_TRUSTED||USER_IN_BLACKLIST_TO|| USER_IN_BLACKLIST) priority SC_HAM -1000 shortcircuit SC_HAM ham score SC_HAM -20 But I log in the headers all short-circuit status, with the following (and you wont see short-circuiting in the examples i posted): status add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ shortcircuit=_SCTYPE_ autolearn=_AUTOLEARN_ version=_VERSION_ Do I have something misconfigured in my trust path? I do have a forward from a debian.org email address that occasionally sends me legit email (although it does seem like a lot of spam gets through there), but I dont believe I have that domain in a whitelist anywhere. thanks micah
Re: [sa] Re: SMTP REJECT after DATA
On Tue, 9 Mar 2010, Ted Mittelstaedt wrote: It is NOT illegal to break a contract. It's called 'fraud'. Look it up. No, sorry, it's NOT fraud. Fraud requires proving an intentional misrepresentation. Well duh. Did you think I meant something else? Breaking a contract does not imply that the contract was entered into with an intent to break it. But sending back an SMTP 'delivered' response when the mail was diverted to a spam folder could be PERCEIVED as misrepresentation (and therefore fraud, because clearly the decision to divert is based in policies established long before the implicit 'contract' of accepting a mail). But again, I stress this is only true for the STUPID USER who does not understand that the spam folder is an alternate form of delivery TO THEM. My responsibility is complete (and legal) when that mail is delivered to either location. It's all about the hassle and misperceptions. The fewer times I have to explain to users how their mail 'disappeared', the easier my life :) And please remember that my entire context was only to stress that my weak definition of 'something illegal' was in CONTRAST to the utterly ridiculous notion that rejecting a mail at SMTP DATA time had anything illegal to it at all! - C
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 16:33 +0200, Henrik K wrote: On Tue, Mar 09, 2010 at 08:22:41AM -0600, David Morton wrote: What exactly *DO* you want?? He's a well known troll here, yet for some reason people want to amuse him and fill out the list with pointless arguments. PLEASE ignore him, since noone has taken the job of unsubscribing him yet. He has a point though, and why is it when people don't agree with someone the troll label comes out, FFS get over your selves. People always only half read, and then go half cocked, its called life, get used to it. FWIW I agree about the well known postfix fanbois, it is decent software, but its not the pot of gold they think it is, it lacks many features and I was told where to go when suggesting them. I also got no response or help from Wietse or any other 'in the know' people with a query recently, but because I considered it a bug, I guess thats why :) attachment: stock_smiley-1.png
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Noel Butler wrote: He has a point though, and why is it when people don't agree with someone the troll label comes out, FFS get over your selves. People always only half read, and then go half cocked, its called life, get used to it. In this case the troll label is more of an understatement, as there are some pretty clear indications that was the second (at least) psuedo-identity adopted by a person who had already been formally warned and then ejected from SA-USERS for inappropriate behavior. Bob --
Re: rules
On 3/8/2010 2:33 PM, Renata Dias wrote: Some messages receive score 0.00/0.00 and other receive the correct score like the example below. 0/0 generally indicates the message was not scanned at all. The big giveaway is the threshold is 0, instead of 6.0. I'm not really an expert on simscan, but if it calls spamc as an interface to spamd, by default spamc will skip scanning messages over 500kb (to avoid bogging SA down on emails that are more likely to be business emails with large attachments). Are the affected messages all over 500k? The other alternative are: -some kind of timeout - but I don't suspect this, as it looks like there's a short runtime in that log line. -simscan is internally whitelisting the message and never passing it to SA at all. I notice one of them forged the pr...@provale.com.br domain as the sender. Any chance you've done a simscan level whitelist of that address? (SA's whitelists show up as rules with large negative scores, not aborted scans). 2010-03-08 16:30:42.038813500 simscan:[63157]:SPAM REJECT (20.90/6.00):215.7090s:[SPAM] Catch the moment poltronieri! 85% Fire Sale:84.224.133.193:poltroni...@provale.com.br:poltroni...@provale.com.br mailto:oltroni...@provale.com.br 2010-03-08 16:30:43.816889500 simscan:[63232]:CLEAN (8.50/6.00):215.5769s:[SPAM] =?iso-8859-1?Q?Conquistando_o_padr=E3o_de_excel=EAncia_em_tratamento?=:200.234.196.130:acquasolut...@acquasolution.com:jua...@saaeg.com.br mailto:ua...@saaeg.com.br 2010-03-08 16:30:45.851526500 simscan:[63300]:CLEAN (2.40/6.00):215.5192s:Resposta Automatica:200.205.19.5:gbr...@carlsonwagonlit.com.br:kafeho...@kafehotel.com.br mailto:afeho...@kafehotel.com.br 2010-03-08 16:30:47.275884500 simscan:[67507]:CLEAN (0.00/0.00):2.9718s:Catch the moment preto! 85% Fire Sale:77.255.23.215:pr...@provale.com.br:pr...@provale.com.br mailto:r...@provale.com.br 2010-03-08 16:30:48.497625500 simscan:[67657]:CLEAN (0.00/0.00):0.1194s:Comprovante da TED:200.234.214.155:netexpre...@hm2655.locaweb.com.br:f...@provale.com.br mailto:f...@provale.com.br I'm updated SpamAssassin to p5-Mail-SpamAssassin-3.3.0_3 and rules are /var/db/spamassassin/3.003000/ . Can someone help me? -- Renata Dias
Re: rules
On 3/8/2010 4:31 PM, Kai Schaetzl wrote: Renata Dias wrote on Mon, 8 Mar 2010 16:33:15 -0300: Some messages receive score 0.00/0.00 and other receive the correct score like the example below. First: there's no evidence that these messages *should* score anything. Yes, but is there any evidence they should have a spam threshold of 0 also? (the others are at 6.0)
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 15:22 -0800, Bob O'Brien wrote: Noel Butler wrote: He has a point though, and why is it when people don't agree with someone the troll label comes out, FFS get over your selves. People always only half read, and then go half cocked, its called life, get used to it. In this case the troll label is more of an understatement, as there are some pretty clear indications that was the second (at least) psuedo-identity adopted by a person who had already been formally warned and then ejected from SA-USERS for inappropriate behavior. Said the liar from Barracuda - aka 'emailreg.org'. I may be hated in the Postfix/Spamassassin groups Bob - but you and Barracuda are hated the world over. I can't top that! Still, nice to watch you all whine about this and drag the topic on and on and on..
