Re: MIPSpace
Matt Kettler wrote: Rick Macdougall wrote: Hi, Anyone ever hear of or use them? www.mipspace.org Looks like they block commercial senders. Aye, looks like their goal is to list all commercial senders, legit, semi-legit, or otherwise. Which I could see being useful in some environments. (ie: certain commercial environments where email use is tightly restricted anyway) That seems like it would be REALLY bad to use at the MTA level, but might serve a slightly useful addition to SA scoring. Maybe .1-.5? I'd like to see how it ends up scoring in the general rules stats.
Re: MIPSpace
Rick Macdougall wrote: > Hi, > > Anyone ever hear of or use them? > > www.mipspace.org > > Looks like they block commercial senders. Aye, looks like their goal is to list all commercial senders, legit, semi-legit, or otherwise. Which I could see being useful in some environments. (ie: certain commercial environments where email use is tightly restricted anyway) I find it interesting that on their statistics page, they reference the percentage of emails blocked (60%), but have no criteria for examining the number of false positives... If high block rate is good, well, shutting down your mailserver is even better, 100% block rate! :) Not to say the list doesn't serve a purpose, but I do find the quoted statistics on the website a little lacking in useful value. I also find it disappointing they've got with a bunch of custom (patent pending) software called BMS to essentially be the functional equivalent of rsyncing DNS zones once a day and locally hosting them on your DNS resolver. (or at least it appears so) At least some of the comparison below is only valid for a off-site, non-rsynced RBL: http://www.mipspace.org/rblvsbms.php BMS might be more efficient than rsync/local dns, but it is hard to tell how much better it really is without any basis of comparison that's not based on remote lookups. As a result of the customization they only support 3 MTAs (notably no sendmail or exim support) http://www.mipspace.org/mailservers.php
Re: DOS_OE_TO_MX
Paolo De Marco wrote: > Hi, > I can't understand the test DOS_OE_TO_MX. > Can anyone tell me what this test does? > Thanks > >From reading the rule "code", it appears to detect if a message claiming to be generated by Outlook Express was delivered directly to your network by an outside host. ie: there's only one host that doesn't match internal_networks (__DOS_SINGLE_EXT_RELAY) and the X-Mailer header says "Outlook Express" (__OE_MUA). There's some logic in there to avoid matching mailing lists.. but that's the general gist..
Re: Are all cf files used in spamassassin
[EMAIL PROTECTED] wrote: > > I am a novice with spamassassin. I am having a problem getting my > arms around several concepts. Here are several questions. > > In looking at the local.cf, I see that the threshhold for marking a > piece of mail as spam is 5. Can I have this mail deleted instead of > being sent to the user? SpamAssassin cannot do this directly, as it has no control over the message envelope. If SA were to try, most mail tools would assume it errored and recover the original, unscanned, message. However, lots of mail tools that do have control of the envelope can be configured to delete the message, properly, if they see SA's marked it as spam.. Thus, the answer here depends on what other tools you're using in your mail processing. Generally folks use procmail rules to do this, but there are lots of other ways depending on what you've got in your setup.. > > > In the /usr/share/spamassassin directory there are a number of cf > files. Does spamassassin use all these files as tests as a default > setting? Yes, unless there's a newer directory created by sa-update. (ie: /var/lib/spamassassin/3.002003/updates_spamassassin_org/) > If not, how do I make sure they are used? spamassassin --lint -D will, among other things, list every file SA reads, assuming you've got a reasonably recent version of SA.
SARE rule defects - and two others - one a 3.1.4 system rule (at the least)
(I am tired of seeing these in the logs. They are MOSTLY SARE rules. They don't affect scores. But they do rather fill up the maillog files.) Under SA 3.2.3 SARE_HEAD_SUBJ_RAND in 70_sare_header.cf depends on SARE_XMAIL_SUSP2 in 70_sare_header4.cf (which is not listed on the rules page.) SARE_HEAD_SUBJ_RAND in 70_sare_header.cf depends on X_AUTH_WARN_FAKED no longer defined anywhere SARE_HEAD_XORIP_NOTIP in 70_sare_header_x30.cf depends on X_ORIG_IPNOT_IPV4 which is not defined anywhere SARE_RD_SAFE in 72_sare_redirect_post3.0.0.cf depends on SARE_RD_SAFE_MKSHRT which is commented out. SARE_RD_SAFE in 72_sare_redirect_post3.0.0.cf depends on SARE_RD_SAFE_GT which is commented out. SARE_RD_SAFE in 72_sare_redirect_post3.0.0.cf depends on SARE_RD_SAFE_TINY which is commented out. (SARE_RD_SAFE is just plain broken.) version 3.1.4 SARE_SPEC_PROLEO_M2a in 70_sare_specific.cf depends on MIME_QP_LONG_LINE which has a zero score but is defined. SARE_HEAD_SUBJ_RAND in 70_sare_header.cf depends on SARE_XMAIL_SUSP2 in 70_sare_header4.cf (which is not listed on the rules page.) SARE_HEAD_SUBJ_RAND in 70_sare_header.cf depends on X_AUTH_WARN_FAKED no longer defined anywhere SARE_HEAD_8BIT_NOSPM in 70_sare_header.cf depends on __SARE_HEAD_8BIT_DATE which is undefined SARE_HEAD_8BIT_NOSPM in 70_sare_header.cf depends on __SARE_HEAD_8BIT_RECV which is undefined SARE_MULT_RATW_03 in 70_sare_header.cf - twice depends on __SARE_MULT_RATW_03E which is undefined SARE_RD_SAFE in 72_sare_redirect_post3.0.0.cf depends on SARE_RD_SAFE_MKSHRT which is commented out. SARE_RD_SAFE in 72_sare_redirect_post3.0.0.cf depends on SARE_RD_SAFE_GT which is commented out. SARE_RD_SAFE in 72_sare_redirect_post3.0.0.cf depends on SARE_RD_SAFE_TINY which is commented out. (SARE_RD_SAFE is just plain broken.) SARE_MSGID_LONG40 in 70_sare_header.cf depends on __SARE_MSGID_LONG50 which is not defined. SARE_MSGID_LONG40 in 70_sare_header.cf depends on __SARE_MSGID_LONG55 which is not defined. SARE_MSGID_LONG40 in 70_sare_header.cf depends on __SARE_MSGID_LONG60 which is not defined. SARE_MSGID_LONG40 in 70_sare_header.cf depends on __SARE_MSGID_LONG65 which is not defined. SARE_MSGID_LONG40 in 70_sare_header.cf depends on __SARE_MSGID_LONG75 which is not defined. Non SARE rule that is available at SARE which is broken VIRUS_WARNING_DOOM_BNC in bogus-virus-warnings.cf depends on VIRUS_WARNING_MYDOOM4 which is not defined For that matter this default rule has a problem. I don't run DCC. DIGEST_MULTIPLE in 20_net_tests.cf depends on DCC_CHECK which is in 25_dcc.cf For this I'd suggest an "else" to allow defining score DCC_CHECK 0. {^_^}
Re: where does include include from?
When scanning, it'll pick up 'user_prefs' from , but when I have an 'include ' in user_prefs, where will it look for ? I suspect most people aren't using include. I'm not quite sure why you would, unless you are doing some sort of user grouping. If every user includes the same file you can just make it one of the common cf files. If users are simply building user_prefs from separate files with includes, they could just make one large file, I suppose. Loren
Re: Deleting Spam (Linux & Procmail)
Matus UHLAR - fantomas wrote: >> On Thursday 11 October 2007, Mark wrote: >> >>> I'm new to the list, so I hope this is the right place. >>> >>> I am running my mail through procmail and separating my spamassassin >>> into 3 groups depending on score: >>> >>>X-Spam-Status: Yes, score=[2-9][0-9] >>>X-Spam-Status: Yes, score=[0-9][0-9] >>>X-Spam-Status: Yes >>> >>> I reason that this must be in order of confidence. I have found that the >>> first group (score>=20) contains more than half of my spam. The last >>> group (score<10) contains about 1/10 of the spam. >>> >>> Would others agree that I can safely get procmail to trash the scores >>> higher than 10? >>> > > On 11.10.07 05:23, Gene Heskett wrote: > >> I've been sending that stuff to /dev/null at >7, no false hits so far >> according to the procmail.log. My bayes is fairly well trained. >> > > We (ISP I work for) had complaints when the messages scored over 7 were > refused. I have even seen some messages that could be taken as false > positives scoring a 11. > > However I take refusal with score over 10 as safe. Some people just have to > fix their submission agents (usually PHP scripts who don't care about proper > encoding and splitting lines) > > refusal (at smtp time) is ok. but OP is about discarding. This is generally less acceptable. If it's one's mail, then one is free to do whatever he wants. but if it's other people's mail, he should ask them (after explaining the risks).
Re: 8bit encoding in mail header by SpamAssassin
Mark Martinec wrote: > This is not a default behaviour, normally such errors in header are only > flagged/logged as a warning, but a message is delivered nevertheless. > There is no particularly good reason to block such messages, > but you can if you want to. > In countries like here, that would block "some" mail (subject not encoded), mostly from broken webmail implementations (Roundcube used to have this bug). I guess similar problems are seen in other countries with accented letters...
Re: Advice on MTA blacklist
David B Funk wrote: > Jo you didn't read Chris's statement closely. A conscientious mail server > administrator will configure the SERVER to -ONLY- accept encrypted > connections for SMTP-AUTH transactions; the server should enforce > the encryption requirements. > This is a religious war declaration or what? ok, let me see what I can say ;-p A conscien-something admin knows that as is always the case with encryption, security depends on the implementation (code, environment, random number generation, ...) and not on the specification. For example, a conscien-something admin knows about thing like this: http://www.henlich.de/moz-smtp/ A conscien-something knows that linking a large library like openssl in an otherwise quite safe MTA adds more opportunities for system compromise. A conscien-somthing admin prefers to be an open relay than a zombie. A conscien-somthing admin knows that it is possible to protect logins without TLS (if data protection is needed, PGP and S/MIME provide this end-to-end, something that no server $thing can provide). sure, not all clients support (secure) authentication methods. but same goes for STARTTLS (and don't tell me about the obsolete smtps, because conscien-seomthing admins don't implement obsolete things). A conscien-something admin knows that unless client certificates are used, starttls doesn't help against dictionary attacks performed from botnets (so you can't just block one IP). the same admin knows that deploying client certificates and/or assisting their users does not come from free, unless they work in a givernment organization financed by public taxes (but even then, a conscien-* admin won't spend people's money so frivoulously). A conscien-something admin knows that the private key is somewhere on the system, and that protecting it does not come for free. And of course, a conscien-something admin can setup an IPSec/ssh/* tunnel and not care about STARTTLS at all, ... and still feel consciencious. but maybe not. maybe he should still enforce STARTTLS? Come on... TLS is nice, but... > Thus it does not matter what the client wants to do, the server should > not let the client continue the SMTP-AUTH transaction until it has > completed the STARTTLS operation (or in the case of SMTPS, it's > already encrypted). > Back to Skip's question, possibly the easiest way to solve his > problem would be to run two SMTP servers, one on port 25 with full > spam/AV scanning for regular mail traffic, one on ports 587 & 645 with > SMTP-AUTH/TLS for his users' clients to submit messages, on that one > have AV scanning and possibly limited spam scanning. > Fully agreed.
Re: MIPSpace
Rick Macdougall wrote: Hi, Anyone ever hear of or use them? www.mipspace.org Looks like they block commercial senders. Regards, Rick Where is their comparison to spamhau's ZEN ? "MIPSpace uses innovative technology to detect and block such junk" Sounds like a great catch phrase, but leaves much to be desired. and at $200/month ? EEK. I wouldn't go near it. James
Re: Creating own DNS block list
On 10/11/07, kc99 <[EMAIL PROTECTED]> wrote: > > Hi > > I am trying to block a number of IP addresses (from URI's) that are not > listed in the default URI blocklists. > > I have created a rule in local.cf as follows: > > uridnsblURIBL_LOCAL mydomain.lanA > bodyURIBL_LOCAL eval:check_uridnsbl('URIBL_LOCAL') > describeURIBL_LOCAL Contains a URL listed in the local blacklist > tflags URIBL_LOCAL net > score URIBL_LOCAL 5.0 > > I have added an IP address to the mydomain.lan zone file with the A record > below: > > x.x.x.x IN A 127.0.0.2 > > However tests don't pickup a URI which the IP address resolves to. Would > appreciate if anyone could tell me where I'm going wrong or point me in the > right direction. > > Thanks in advance. > Hi, RBL queries are usually done like: ip: 192.168.1.1 query: 1.1.168.192.rbl.domain.tld so you should have a zone file like: 1.1.168.192 IN A 127.0.0.2 cheers -- Daniele Santi.o. [EMAIL PROTECTED]..o|,,,/_ Linux User #415108 ooo - () ascii ribbon campaign - against html mail /\- against microsoft attachments -
MIPSpace
Hi, Anyone ever hear of or use them? www.mipspace.org Looks like they block commercial senders. Regards, Rick
Re: DOS_OE_TO_MX
Paolo De Marco wrote: Hi, I can't understand the test DOS_OE_TO_MX. Can anyone tell me what this test does? My rule: Outlook Express Sent mail directly to Your MX DOS_ OE_ TO_MX Daryl
Re: Auto-RBL was: Why did this not hit more? (SPF, DKIM, Ironport, X-originating-ip)
From: "Dan Mahoney, System Admin" <[EMAIL PROTECTED]> Sent: Monday, 2007, October 08 10:33 On Mon, 8 Oct 2007, Matus UHLAR - fantomas wrote: On Sat, 6 Oct 2007, Rob McEwen wrote: FWIW... that IP, 220.226.197.15, is currently listed on four spam blacklists ("RBLs"): 1) uceprotect 2) no-more-funn 3) psbl 4) ivmSIP.com (mine) On 07.10.07 05:55, Dan Mahoney, System Admin wrote: My problem is: blocklists come and go, and some blocklists, when they "go", do things like "hang up because they're being flooded, thus slowing my mail processes" or "flag all mail as spam" or "hand out stale data that hasn't changed at all in months/years". That's what sa-update is for. Personally, I'd like it if SA came with a blocklist-feeder tool, where upon, say, two auto-learns, a blocklist (or SQL database) could be fed. Why do you think people would use them, when they don't already use sa-update which does the same? sa-update does NOT feed a local blocklist generated by *my* particular corpus of spam emails. Think of it as the RBL equivalent of sitewide-bayes. Or think of it as a way of SA saying "when I get twelve spams of score 10+ from ip 208.23.118.172...I will feed the auto-expiring RBL, which *SENDMAIL* works off of, thus keeping my *SPAMASSASSIN* load lower. Thus a spam deluge via a dictionary attack that may take hours is mitigated in the course of X number of mails. Which is what I was (off-topicly) asking for, With procmail you can run any program you want based on features of messages received. (Now, I'd not run say "startx" from procmail. But I do use it to detect email from certain people and play a specific tune for them using "play".) You could develop a little script for performing that job. {^_^}
Re: Are all cf files used in spamassassin
From: <[EMAIL PROTECTED]> Sent: Thursday, 2007, October 11 10:06 I am a novice with spamassassin. I am having a problem getting my arms around several concepts. Here are several questions. In looking at the local.cf, I see that the threshhold for marking a piece of mail as spam is 5. Can I have this mail deleted instead of being sent to the user? SpanAssassin creates scores. Tools like procmail, mailscanner, and others can take that score and handle the spam. For a hospital I'd include the score in the email markup header and let the users redirect the spam as they see fit. I always review it. The markup I use can sort the spam mail by score. I examine at least the low scoring spam to see if any ham got through. I can tell very reliably from the score, subject, and source whether it is spam or not. ===8<--- # How many hits before a mail is considered spam. required_hits 5.0 rewrite_header Subject *SPAM* _SCORE(00)_ ** ===8<--- That gives a three digit spam score with leading zeros. Spam sorts very nicely that way. This habit has saved me a couple real financial transaction emails due to the sender changing its email configuration. In the /usr/share/spamassassin directory there are a number of cf files. Does spamassassin use all these files as tests as a default setting? If not, how do I make sure they are used? If it has .cf after the file it uses it. The files are used in alphabetical order. I've never tried to confirm that every one is used. I've never seen any indication that one is being skipped. You could run "spamassassin --lint -D" and parse the output for the name of each of the cf files. {^_^}Joanne
Re: LashBack URL / BL?
Kris Deugau wrote: > Mikael Syska wrote: >> I'm not sure about all the diff black list options ... but I guess it >> would be rather easy to test it . >> >> header RCVD_IN_LASHBACK eval:check_rbl('LASHBACK','ubl.unsubscore.com') >> describe RCVD_IN_LASHBACK lashback >> tflags RCVD_IN_LASHBACK net >> score RCVD_IN_LASHBACK 0.0 >> >> Would this be the right text to add to local.cf ... then in a few days >> I can give some feedback > > You'd want a small, non-zero score (0.001 is usually good for this type > of testing) otherwise the test is disabled. > > -kgd Also, I don't know if it's required or not, but all examples I've seen of "eval:check_rbl" tests, the query host name is terminated with a ".": header RCVD_IN_LASHBACK eval:check_rbl('LASHBACK','ubl.unsubscore.com.') Bill
Are all cf files used in spamassassin
I am a novice with spamassassin. I am having a problem getting my arms around several concepts. Here are several questions. In looking at the local.cf, I see that the threshhold for marking a piece of mail as spam is 5. Can I have this mail deleted instead of being sent to the user? In the /usr/share/spamassassin directory there are a number of cf files. Does spamassassin use all these files as tests as a default setting? If not, how do I make sure they are used? Richmond H. Dyes Monroe Community Hospital IS Department Head 760-6213
Re: LashBack URL / BL?
Mikael Syska wrote: I'm not sure about all the diff black list options ... but I guess it would be rather easy to test it . header RCVD_IN_LASHBACK eval:check_rbl('LASHBACK','ubl.unsubscore.com') describe RCVD_IN_LASHBACK lashback tflags RCVD_IN_LASHBACK net score RCVD_IN_LASHBACK 0.0 Would this be the right text to add to local.cf ... then in a few days I can give some feedback You'd want a small, non-zero score (0.001 is usually good for this type of testing) otherwise the test is disabled. -kgd
Creating own DNS block list
Hi I am trying to block a number of IP addresses (from URI's) that are not listed in the default URI blocklists. I have created a rule in local.cf as follows: uridnsblURIBL_LOCAL mydomain.lanA bodyURIBL_LOCAL eval:check_uridnsbl('URIBL_LOCAL') describeURIBL_LOCAL Contains a URL listed in the local blacklist tflags URIBL_LOCAL net score URIBL_LOCAL 5.0 I have added an IP address to the mydomain.lan zone file with the A record below: x.x.x.x IN A 127.0.0.2 However tests don't pickup a URI which the IP address resolves to. Would appreciate if anyone could tell me where I'm going wrong or point me in the right direction. Thanks in advance. -- View this message in context: http://www.nabble.com/Creating-own-DNS-block-list-tf4608480.html#a13159618 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
DOS_OE_TO_MX
Hi, I can't understand the test DOS_OE_TO_MX. Can anyone tell me what this test does? Thanks -- Paolo De Marco Real Comm srl Tel. +39 0434 923134
Re: LashBack URL / BL?
Hi, I'm not sure about all the diff black list options ... but I guess it would be rather easy to test it . header RCVD_IN_LASHBACK eval:check_rbl('LASHBACK','ubl.unsubscore.com') describe RCVD_IN_LASHBACK lashback tflags RCVD_IN_LASHBACK net score RCVD_IN_LASHBACK 0.0 Would this be the right text to add to local.cf ... then in a few days I can give some feedback Dave Koontz wrote: Does anyone use the LashBack URL as an MTA BL block or SA rule? I just discovered them and they sound intriguing. Any feedback on their reliability and FP rate would be appreciated. I am a little concerned that I’ve never heard of them before…. http://www.lashback.com/support/UnsubscribeBlacklistSupport.aspx // ouT
Re: 8bit encoding in mail header by SpamAssassin
Lars, > >>> Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from > >>> <[EMAIL PROTECTED]>: Non-encoded 8-bit data (char FC hex) in message > >>> header > >>> 'X-Spam-Report'\n X-Spam-Report: ... Nachricht wurde nur > >>> \\374bervertrauensw...\n > The administrator claims to be using version 3.2.3 and that is as well > what it says in all mails I am getting from this host. Most likely these header fields were inserted by some remote mailer running SpamAssassin, over which you may not have any control. Amavisd would not see or check X-Spam-* header fields added by itself (or from SpamAssassin invoked from it). > Amavisd, which I am running on my server, rejects these messages > because they are not obeying RFC 2822, which forbids 8bit encoding... This is not a default behaviour, normally such errors in header are only flagged/logged as a warning, but a message is delivered nevertheless. There is no particularly good reason to block such messages, but you can if you want to. Mark
Re: 8bit encoding in mail header by SpamAssassin
Justin Mason wrote: > Per Jessen writes: >> Lars Ippich wrote: >> >>> I actually have problems with mails coming from a server where they >>> already have been checked by SpamAssassin and have been added headers. >>> Amavisd, which I am running on my server, rejects these messages >>> because they are not obeying RFC 2822, which forbids 8bit encoding in >>> mails: >>> >>> Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from >>> <[EMAIL PROTECTED]>: Non-encoded 8-bit data (char FC hex) in message header >>> 'X-Spam-Report'\n X-Spam-Report: ... Nachricht wurde nur >>> \\374ber >>> vertrauensw...\n ^ >>> >>> So what can the sender's mailserver's administrator do to make >>> SpamAssassin adding reports 7bit encoded? >> Interesting problem. My first thought was RFC2046, but that won't work >> as nobody decodes the spamassassin headers, so they need to readable >> without decoding. >> >> I think the answer is for spamassassin to avoid using 8bit chars when >> adding email headers. Otherwise you could perhaps adjust your amavis >> settings and allow 8-bit chars in the header? > > Upgrade SpamAssassin -- we fixed that bug a good while ago. > > --j. The administrator claims to be using version 3.2.3 and that is as well what it says in all mails I am getting from this host. Lars Ippich
Re: Deleting Spam (Linux & Procmail)
> On Thursday 11 October 2007, Mark wrote: > >I'm new to the list, so I hope this is the right place. > > > >I am running my mail through procmail and separating my spamassassin > >into 3 groups depending on score: > > > >X-Spam-Status: Yes, score=[2-9][0-9] > >X-Spam-Status: Yes, score=[0-9][0-9] > >X-Spam-Status: Yes > > > >I reason that this must be in order of confidence. I have found that the > >first group (score>=20) contains more than half of my spam. The last > >group (score<10) contains about 1/10 of the spam. > > > >Would others agree that I can safely get procmail to trash the scores > >higher than 10? On 11.10.07 05:23, Gene Heskett wrote: > I've been sending that stuff to /dev/null at >7, no false hits so far > according to the procmail.log. My bayes is fairly well trained. We (ISP I work for) had complaints when the messages scored over 7 were refused. I have even seen some messages that could be taken as false positives scoring a 11. However I take refusal with score over 10 as safe. Some people just have to fix their submission agents (usually PHP scripts who don't care about proper encoding and splitting lines) -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N)
Re: 8bit encoding in mail header by SpamAssassin
Per Jessen writes: > Lars Ippich wrote: > > > I actually have problems with mails coming from a server where they > > already have been checked by SpamAssassin and have been added headers. > > Amavisd, which I am running on my server, rejects these messages > > because they are not obeying RFC 2822, which forbids 8bit encoding in > > mails: > > > > Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from > > <[EMAIL PROTECTED]>: Non-encoded 8-bit data (char FC hex) in message header > > 'X-Spam-Report'\n X-Spam-Report: ... Nachricht wurde nur > > \\374ber > > vertrauensw...\n ^ > > > > So what can the sender's mailserver's administrator do to make > > SpamAssassin adding reports 7bit encoded? > > Interesting problem. My first thought was RFC2046, but that won't work > as nobody decodes the spamassassin headers, so they need to readable > without decoding. > > I think the answer is for spamassassin to avoid using 8bit chars when > adding email headers. Otherwise you could perhaps adjust your amavis > settings and allow 8-bit chars in the header? Upgrade SpamAssassin -- we fixed that bug a good while ago. --j.
Re: where does include include from?
Per Jessen writes: > Per Jessen wrote: > > > I have spamd running with > > > > --nouser-config --virtual-config-dir= > > > > When scanning, it'll pick up 'user_prefs' from , but when I > > have an 'include ' in user_prefs, where will it look for ? > > > > I guess an strace will tell me, but I'm amazed that nobody knows > where 'include' includes from ... not even an RTFM for me? Given that you seem relatively knowledgeable, I assumed "RTFM" was superfluous. Seriously -- RTFM, it's right there ;) --j.
Re: Deleting Spam (Linux & Procmail)
On Thursday 11 October 2007, Mark wrote: >Hi All > >I'm new to the list, so I hope this is the right place. > >I am running my mail through procmail and separating my spamassassin >into 3 groups depending on score: > >X-Spam-Status: Yes, score=[2-9][0-9] >X-Spam-Status: Yes, score=[0-9][0-9] >X-Spam-Status: Yes > >I reason that this must be in order of confidence. I have found that the >first group (score>=20) contains more than half of my spam. The last >group (score<10) contains about 1/10 of the spam. > >Would others agree that I can safely get procmail to trash the scores >higher than 10? > >Thanks, > >Mark I've been sending that stuff to /dev/null at >7, no false hits so far according to the procmail.log. My bayes is fairly well trained. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: Why is it that Mexico isn't sending anyone to the '84 summer games? A: Anyone in Mexico who can run, swim or jump is already in LA.
Deleting Spam (Linux & Procmail)
Hi All I'm new to the list, so I hope this is the right place. I am running my mail through procmail and separating my spamassassin into 3 groups depending on score: X-Spam-Status: Yes, score=[2-9][0-9] X-Spam-Status: Yes, score=[0-9][0-9] X-Spam-Status: Yes I reason that this must be in order of confidence. I have found that the first group (score>=20) contains more than half of my spam. The last group (score<10) contains about 1/10 of the spam. Would others agree that I can safely get procmail to trash the scores higher than 10? Thanks, Mark
Re: 8bit encoding in mail header by SpamAssassin
Lars Ippich wrote: > I actually have problems with mails coming from a server where they > already have been checked by SpamAssassin and have been added headers. > Amavisd, which I am running on my server, rejects these messages > because they are not obeying RFC 2822, which forbids 8bit encoding in > mails: > > Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from > <[EMAIL PROTECTED]>: Non-encoded 8-bit data (char FC hex) in message header > 'X-Spam-Report'\n X-Spam-Report: ... Nachricht wurde nur > \\374ber > vertrauensw...\n ^ > > So what can the sender's mailserver's administrator do to make > SpamAssassin adding reports 7bit encoded? Interesting problem. My first thought was RFC2046, but that won't work as nobody decodes the spamassassin headers, so they need to readable without decoding. I think the answer is for spamassassin to avoid using 8bit chars when adding email headers. Otherwise you could perhaps adjust your amavis settings and allow 8-bit chars in the header? /Per Jessen, Zürich