Re: razor and dcc : high cpu load
On Fri, Nov 10, 2006 at 04:12:44PM -0200, Rejaine Monteiro wrote: > > Ok, validrcptto seems to be nice for me... > I just can't forget to insert all -default aliases (qmail-default) and > use a validrcptto version with this support (to using with qmail-rocks) > > Thanks for all tips > In case you want to explore other rcpt-checking routines, as well as see some scripts for doing getting addresses from, say, an exchange server that's behind a qmail server, go to http://http.netdevice.com:9080/qmail/rcptck/ Lot's of good alternatives. Ollie > > Jim Maul escreveu: > >Rejaine Monteiro wrote: > >> > >>Like a text-file based (it's not a security hole?!) or a ldap-replica > >>on mail-server? > >>I'm searching for more examples and other ideas and find this patch > >>for qmail: > >>http://qmail.jms1.net/patches/validrcptto.cdb.shtml > >> > >>I don't no if this patch is really necessary.. but it's a sugestion > >>too... > >>Anyway... I'll search more and to do many tests... > >> > >>Thanks... > >> > > > >First, that was exactly that page/patch that i was referring to. I > >use it here on my server and know of others who are in the exact same > >setup as you who also use it. > > > >The file is a .cdb file (not text) but even if it was, i fail to see > >how this is a security hole. There are only a list of accounts or > >perhaps a wildcard ([EMAIL PROTECTED]) in this cdb file so where is the risk? > > > >ldap-replica is way too involved for this function. Use the patch you > >mentioned, find a way to get qmail-ldap to output a list of addresses, > >build the cdb file and replicate to the server(s). Thats basically it. > > > >-Jim -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: razor and dcc : high cpu load
On Thu, Nov 09, 2006 at 02:57:23PM -0500, Jason Little wrote: > > We had that problem in the past until we started using the access list in > sendmail to filter out servers that were just hitting us with spam all the > time. I still go through our logs daily and add to it as needed. The > reduction in load on the server was very dramatic. Since our server is a > forwarding server we also reject email addresses in the access list to > further drop the load because spamassassin never needs to scan it. > > Jason Little > Network Admin > Mint Inc > I would certainly endorse anything to decrease the incoming load. We use qmail and implemented the goodrctto-12.patch which rejects emails at smtp time that are not in a list of valid recipients. This hugely (>80%) decreased the volume of accepted incoming mail which, obviously, hugely decreased the traffic through spamassassin. Ollie > > -Original Message- > From: Bowie Bailey [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 09, 2006 2:50 PM > To: users@spamassassin.apache.org > Subject: RE: razor and dcc : high cpu load > > Rejaine Monteiro wrote: > > my system had a high cpu load with spamassassin with network tests , > > dcc + razor and fuzzy_ocr because off this, we are considering disable > > razor or dcc from tests... > > > > but we have doubt about which is better: disable razor or dcc? > > > > any recomendations?? > > If the decision is between DCC and Razor, I would keep Razor. > > However, neither one of them should contribute much to a high CPU load. > They can cause delays waiting for responses from the servers, but they don't > really do enough to raise the load significantly. > > Fuzzy_ocr or a bad rule is a more likely candidate for eating cpu time. > > -- > Bowie > -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: How to set up Razor
On Mon, Nov 06, 2006 at 02:57:30PM +0200, David Baron wrote: > Installed it off Debian Sid. > How do I get SA to make use of it? The SpamAssassin wiki is your friend: http://wiki.apache.org/spamassassin/ Here are just two of the many references to Razor. UsingRazor: http://wiki.apache.org/spamassassin/UsingRazor RazorSiteWide: http://wiki.apache.org/spamassassin/RazorSiteWide Ollie -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: Always add report headers
Arik - I think the problem is one of understanding what is happening with the .qmail + ifspamh processing. The first line of .qmail invokes ifspamh with a copy of the email on stdin. ifspamh then invokes spamassassin and, if spam, delivers to the designated spam destination and exits 99 so the .qmail file does nothing more. If not spam, it does not deliver (which means the spamassassin-modified email is discarded) and exits 0. With an exit 0, the .qmail file then delivers the unmodified email to the "good email" maildir. So, only spam-designated emails end up with spamassassin headers. The good emails effectively by-pass spamassassin. A alternative approach is to hand off the email delivery to a mda like procmail or mailfilter. These can then serially process 1st through spamc, then through their own filtering language. Emails delivered through this process will all have spamassassin-created headers, whether spam or not. Hope this helps. Ollie On Sun, Aug 06, 2006 at 12:41:48AM +0200, Arik Raffael Funke wrote: Nigel Frankcom wrote: > On Sat, 05 Aug 2006 18:29:04 +0200, Arik Funke <[EMAIL PROTECTED]> > wrote: > >> Nigel Frankcom wrote: >>> On Sat, 05 Aug 2006 14:08:45 +0200, Arik Raffael Funke >>> <[EMAIL PROTECTED]> wrote: >>>> use_auto_whitelist 0 >>>> use_bayes 0 >>>> add_header all Report _REPORT_ >>>> add_header all Status _YESNO_, hits=_HITS_ required=_REQD_ tests=_TESTS_ >>>> autolearn=_AUTOLEARN_ version=_VERSION_ >>>> >>>> I am using version 3.1.4. >>> On checking further that last post may not have any effect. Some >>> setups are known to have their own way with headers. What setuo are >>> you using? >> I am using a clean install of spamassassin 3.1.4 from the spamassassin >> website with rpmbuilt -tb spamassassin...tgz. > > Please respond on list with details of your mailserver, OS and any > other software you use between mail & sa. In addition to my earlier mail, the remaining info: I am using FC4 with a self-built (with standard options) qmail based on netqmail-1.05. Between the mailserver and spamassassin no other software is used besides the ifspamh script by James Grinter (http://www.gbnet.net/~jrg/qmail/ifspamh/) Regards, Arik -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: White list problem
On Tue, Jan 11, 2005 at 11:04:12PM -0500, Matt Kettler wrote: > Ollie, Something isn't adding up in a big way. Have you run spamassassin > --lint lately? Perhaps SA is getting heavily confused. Indeed you are right about things not adding up. > > Is there any chance you could re-run the message through spamassassin -d so > we could see the debug output? > I ran spamassassin --lint and got no output, implying no problems with the rules. I then ran the message through sa with -D. SA parsed all the "froms" and boiled them down (correctly) to [EMAIL PROTECTED] It even noted the forged HELO, but still it gave the Whitelist_from 100 pt. credit. OK, I thought, since SA is probably working fine, it must be my whitelist. I temporarily culled all the whitelist_from's from local.cf and ran the message through spamassassin -D. Eureka! No whitelist credit, and the message was correctly identified as spam. After a much more thorough examination of my rules, I found the culprit: whitelist_from*cnet.com insted of whitelist_from [EMAIL PROTECTED] Zapped by a missing "@". Thanks everyone for your comments, especially Matt whose suggestions got me to a fix. Ollie > > > -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: White list problem
On Tue, Jan 11, 2005 at 05:46:58PM -0800, List Mail User wrote: > Every one seem to be missing the forged HELO which (incorrectly) used > the IP address of the receiving machine. This seems to have fooled both your > MTA; The critical headers are: > > > > Received: from 61.32.186.51 by kukla (envelope-from <[EMAIL PROTECTED]>, > > > uid > 71) with qmail-scanner-1.24 > > and > > > > Received: from unknown (HELO 64.81.195.127) (61.32.186.51) > > where clearly the forged HELO (i.e. "(HELO 64.81.195.127)") caused qmail, > et. al. to believe you were receiving from a trusted machine. > OK, I had noticed that, but why is spamassassin's whitelist_from looking at the HELO? I thought it looked at From: and its relatives. > This is a common trick - to try to pretend to be either the local > machine or another of your legitimate 'MX' hosts. I don't know qmail well > enough to tell you the configuration fix, but you shouldn't be whitelisting > anything based an unverified 'HELO' - Note the real IP address is readily I'm not sure I understand how I whitelisted based on an unverified HELO. As far as I can tell, my whitelists are all of the form whitelist_from [EMAIL PROTECTED] or the like. Nothing that links to HELO that I understand. Please explain further so I can fix. > visible as 61.32.186.51. Also, if RFC821 and RFC1822 were being enforced, > the message would have been rejected anyway (IP addresses are supposed to > *require* surrounding brackets - ex. [64.81.195.127] instead of a bare IP). > > In fact, you should probably be checking for any valid looking IP > addresses and applying extra tests in those cases (I could tell you how for > either sendmail or Postfix, but qmail or others are outside my own experience, > except for the many hours spent helping friends work around qmail bugs). > Perhaps you're right that I need to fix something upstream, but my understanding of the HELO is that it will take well nigh anything. I think my immediate question is more of why is spamassassin letting this mail through? Thanks for pointing out these areas to look at. Ollie -- |---| | Ollie Acheson | | Morristown, NJ| |---|
Re: White list problem
On Tue, Jan 11, 2005 at 07:54:56PM -0500, Matt Kettler wrote: > At 07:26 PM 1/11/2005, Ollie Acheson wrote: > >The message below passed through spamassassin with a -93.1 score as a > >result > >of a -100 USER_IN_WHITELIST, but my user.prefs has nothing resembling the > >information in "From:" > > 1) you checked your user_prefs (hopefully not user.prefs) did you check the As usual, the typing got ahead of the brain. Yes the file should be user_prefs. When I switched to a "system" approach, I moved all the whitelist_from's from /home/oacheson/.spamassassin/user_prefs to /etc/mail/spamassassin/local.cf > *rest* of the configuration files on the system? > > grep whitelist_from /etc/mail/spamasssassin/*.cf > > 2) you use qmail-scanner.. did you check the right user_prefs file? ie: not > /home/oacheson/.spamassassin/user_prefs, but the one qmail uses.. usually > this is /var/qmail/.spamassassin/user_prefs The only user_prefs is the old one in my home directory, and the .cf's are in /etc/mail/spamassassin and /usr/share/spamassassin. None has whitelist_from's that should be triggered by the From: information in the email. Thanks Ollie -- |---| | Ollie Acheson | | Morristown, NJ| |---|
White list problem
ies, are > forward-looking statements that invo|ve risks and uncertainties. There can be > no assurance that such statements wi|l prove to be accurate and actua| > results and future events cou|d differ materia||y from those anticipated in > such statements. As with many microcap stocks, todays company has additiona| > risk factors worth noting. The company has a going concern opinion from its > auditor, a large accumu|ated deficit,a |arge negative net worth,a reliance on > loans from officers to pay expenses, nominal revenue in its most recent > quarter,officers have personal|y guaranteeed company debt, tax |iens for > unpaid federa| and state taxes, is a defendant in two lawsuits,has a nominal > cash position and the need to raise capital. A fai|ure to raise capita| cou|d > cause the company to go out of business. These risks and others are more > fu||y detai|ed in the Companys SEC fi|ings. We strongly urge you to review > them before you invest. The Publisher of this news|etter does not represent > that the information contained in this message states a|| material facts or > does not omit a materia| fact necessary to make the statements therein not > misleading. Read the compay's SEC filings before you invest. A|l information > provided within this pub|ication pertaining to investing, stocks, securities > must be understood as information provided and not investment advice. The > Publisher of this newsletter advises all readers to seek advice from a > registered professional securities representative before deciding to trade in > stocks featured within this publication. None of the materia| within this > report sha|| be construed as any kind of investment advice or solicitation. > Many of these companies are on the verge of bankruptcy. You can lose a|| your > money by investing in this stock. The Pub|isher of this news|etter is not a > registered investment expert. Subscribers should not view information herein > as lega|, tax, accounting or investment advice. Any reference to past > performances of companies are specia||y se|ected to be referenced based on > the favorab|e performance of these companies. You would need perfect timing > to acheive the results in the examp|es given. There can be no assurance of > that happening. Remember, as always, past performance is not indicative of > future resu|ts and a thorough due diligence effort, inc|uding a review of a > companys filings, shou|d be comp|eted prior to investing. In compliance with > the Securities Act of 1933, Section17b, the Pub|isher of this newsletter > discloses the receipt of fourteen thousand do||ars from a third party, not an > officer, director or affi|iate shareho|der of the company for the circu|ation > of this report. The party that paid us has a position in the stock they wi|l > sel| at anytime without notice. Be aware of an inherent conf|ict of interest > resulting from such compensation due to the fact that this is a paid > publication and is not without bias. A|| factua| information in this report > was gathered from public sources, inc|uding but not |imited to Company > Websites, SEC filings and Company Press Re|eases. The Publisher of this > news|etter be|ieves this information to be re|iable but can make no assurance > as to its accuracy or comp|eteness. Use of the materia| within this > pub|ication constitutes your acceptance of these terms. > - End forwarded message - -- |---| | Ollie Acheson | | Morristown, NJ| |---|
