Re: Bayes Strategies
On 8 Nov 2008, at 00:09, Matt Kettler wrote: Matt Kettler wrote: Neil wrote: So maybe this is moving slightly off on a tangent, but: Why does auto-learn sometimes learn spam with a rating of X, but not spam with a rating of X+Y? Where's it's methodology? First, there's several rules involved here. To autolearn as spam *ALL* of the following must be met: -must have at least 3 points from header type rules -must have at least 3 points from body type rules -must not already match a low-scoring bayes rule in the existing training (ie: BAYES_00) This prevents autolearning from contradicting existing training. -After recomputing the score of the message as if bayes and all userconf rules were disabled (including changing the scoreset! This makes a big difference in some cases.), that score must be over the spam learning threshold. This prevents bayes from engaging in self-feedback or feedback based on manual whitelists (which, if misconfigured would cause a "bayes hangover" of mis-learned mail). Generally speaking, the score you see in the message header has only a loose correlation with the score used for learning checks. Oh, one more rule I missed: -The write lock for the bayes DB must be free. (ie: no other learning or expiry going on at the time). It will not block and wait for it, it will simply move on, but it will report autolearn=failed instead of autolearn=no. This prevents autolearning from log jamming your mail queue. Thanks for that in-depth description; it helps me have a (less) vague idea of what I'm doing. -N.
Re: Bayes Strategies
Matt Kettler wrote: > Neil wrote: > >> So maybe this is moving slightly off on a tangent, but: >> Why does auto-learn sometimes learn spam with a rating of X, but not >> spam with a rating of X+Y? Where's it's methodology? >> > > First, there's several rules involved here. > > To autolearn as spam *ALL* of the following must be met: > > -must have at least 3 points from header type rules > -must have at least 3 points from body type rules > -must not already match a low-scoring bayes rule in the existing > training (ie: BAYES_00) This prevents autolearning from contradicting > existing training. > -After recomputing the score of the message as if bayes and all userconf > rules were disabled (including changing the scoreset! This makes a big > difference in some cases.), that score must be over the spam learning > threshold. This prevents bayes from engaging in self-feedback or > feedback based on manual whitelists (which, if misconfigured would cause > a "bayes hangover" of mis-learned mail). > > Generally speaking, the score you see in the message header has only a > loose correlation with the score used for learning checks. > > Oh, one more rule I missed: -The write lock for the bayes DB must be free. (ie: no other learning or expiry going on at the time). It will not block and wait for it, it will simply move on, but it will report autolearn=failed instead of autolearn=no. This prevents autolearning from log jamming your mail queue.
Re: Bayes Strategies
Neil wrote: > > So maybe this is moving slightly off on a tangent, but: > Why does auto-learn sometimes learn spam with a rating of X, but not > spam with a rating of X+Y? Where's it's methodology? First, there's several rules involved here. To autolearn as spam *ALL* of the following must be met: -must have at least 3 points from header type rules -must have at least 3 points from body type rules -must not already match a low-scoring bayes rule in the existing training (ie: BAYES_00) This prevents autolearning from contradicting existing training. -After recomputing the score of the message as if bayes and all userconf rules were disabled (including changing the scoreset! This makes a big difference in some cases.), that score must be over the spam learning threshold. This prevents bayes from engaging in self-feedback or feedback based on manual whitelists (which, if misconfigured would cause a "bayes hangover" of mis-learned mail). Generally speaking, the score you see in the message header has only a loose correlation with the score used for learning checks.
Re: Bayes Strategies
On 7 Nov 2008, at 23:43, Neil wrote: On 7 Nov 2008, at 23:40, Matt Kettler wrote: Neil wrote: I'm wondering about the best way to train my Bayes filter (per-user filtering). I have a Junk folder, and it contains roughly three categories of mail (to my mind, at least): A. Mail SpamAssassin marked spam and auto-learned as spam. B. Mail SpamAssassin marked spam, but did not autolearn. C. Mail SpamAssassin did not mark spam, which I moved in there. So my questions: 1. Would it be bad for me to just run sa-learn on the entire Junk folder; or should I just let auto-learn do it's thing and sa-learn the false negatives? No. It's not bad. If SA has already correctly learned the message, it will be skipped. Of course, this means it's a waste of time to feed SA messages it's already learned correctly, but it's not going to hurt anything. 2. Likewise, my Inbox contains just ham; could I run sa-learn on that entire mailbox periodically? Ditto. 3. Lastly, will it be detrimental (in terms of future accuracy) to sa-learn the same mail more than once, or will SpamAssassin remember it? (I seem to remember reading the latter, but I wasn't sure). It will remember If it does, how long/many previous mails does it remember? Currently the bayes_seen mechanism has no expiration, so it will remember forever, or until you manually delete bayes_seen. Thanks. So then I think my strategy is going to be: sort the mail as usual, and then every once in a while log into my server and run a script which will call sa-learn on both mailboxes. So maybe this is moving slightly off on a tangent, but: Why does auto-learn sometimes learn spam with a rating of X, but not spam with a rating of X+Y? Where's it's methodology?
Re: Bayes Strategies
On 7 Nov 2008, at 23:40, Matt Kettler wrote: Neil wrote: I'm wondering about the best way to train my Bayes filter (per-user filtering). I have a Junk folder, and it contains roughly three categories of mail (to my mind, at least): A. Mail SpamAssassin marked spam and auto-learned as spam. B. Mail SpamAssassin marked spam, but did not autolearn. C. Mail SpamAssassin did not mark spam, which I moved in there. So my questions: 1. Would it be bad for me to just run sa-learn on the entire Junk folder; or should I just let auto-learn do it's thing and sa-learn the false negatives? No. It's not bad. If SA has already correctly learned the message, it will be skipped. Of course, this means it's a waste of time to feed SA messages it's already learned correctly, but it's not going to hurt anything. 2. Likewise, my Inbox contains just ham; could I run sa-learn on that entire mailbox periodically? Ditto. 3. Lastly, will it be detrimental (in terms of future accuracy) to sa-learn the same mail more than once, or will SpamAssassin remember it? (I seem to remember reading the latter, but I wasn't sure). It will remember If it does, how long/many previous mails does it remember? Currently the bayes_seen mechanism has no expiration, so it will remember forever, or until you manually delete bayes_seen. Thanks. So then I think my strategy is going to be: sort the mail as usual, and then every once in a while log into my server and run a script which will call sa-learn on both mailboxes. -N.
Re: Bayes Strategies
Neil wrote: > I'm wondering about the best way to train my Bayes filter (per-user > filtering). > > I have a Junk folder, and it contains roughly three categories of mail > (to my mind, at least): > A. Mail SpamAssassin marked spam and auto-learned as spam. > B. Mail SpamAssassin marked spam, but did not autolearn. > C. Mail SpamAssassin did not mark spam, which I moved in there. > > So my questions: > 1. Would it be bad for me to just run sa-learn on the entire Junk > folder; or should I just let auto-learn do it's thing and sa-learn the > false negatives? No. It's not bad. If SA has already correctly learned the message, it will be skipped. Of course, this means it's a waste of time to feed SA messages it's already learned correctly, but it's not going to hurt anything. > > 2. Likewise, my Inbox contains just ham; could I run sa-learn on that > entire mailbox periodically? Ditto. > > 3. Lastly, will it be detrimental (in terms of future accuracy) to > sa-learn the same mail more than once, or will SpamAssassin remember > it? (I seem to remember reading the latter, but I wasn't sure). It will remember > If it does, how long/many previous mails does it remember? Currently the bayes_seen mechanism has no expiration, so it will remember forever, or until you manually delete bayes_seen.
Bayes Strategies
I'm wondering about the best way to train my Bayes filter (per-user filtering). I have a Junk folder, and it contains roughly three categories of mail (to my mind, at least): A. Mail SpamAssassin marked spam and auto-learned as spam. B. Mail SpamAssassin marked spam, but did not autolearn. C. Mail SpamAssassin did not mark spam, which I moved in there. So my questions: 1. Would it be bad for me to just run sa-learn on the entire Junk folder; or should I just let auto-learn do it's thing and sa-learn the false negatives? 2. Likewise, my Inbox contains just ham; could I run sa-learn on that entire mailbox periodically? 3. Lastly, will it be detrimental (in terms of future accuracy) to sa- learn the same mail more than once, or will SpamAssassin remember it? (I seem to remember reading the latter, but I wasn't sure). If it does, how long/many previous mails does it remember? Thanks, Neil.
Re: sa-update calling the wrong IP address
Shawn Berg wrote: > I recently had to entirely re-IP a network including the server running > Spamassassin. When I run sa-update, it just hangs at the command prompt > with a flashing cursor; same thing happens when I run sa-update –D but > only after it calls the updates.spamassassin.org channel… > > Checking my firewall logs, it appears sa-update is calling the wrong LAN > IP of our Windows DNS server (I understand SA-UPDATE runs updates > through DNS). I guess my question is where does sa-update cache or > obtain this DNS address? Was it captured during the original nmake > process? All other DNS requests from clients and or software resolve DNS > queries just fine; no other DNS issues on this network…I was unable to > find any reference to this IP in the sa-update.bat file. > > Running Spamassassin 3.2.5 on Windows Server 2003/Exchange 2003. You are running a non-standard SA, so the following might be completely wrong. Usually the DNS server(s) are defined on /etc/resolv, which in your case could be inside the perl directory (I don't know what perl you are using, ActivePerl or Strawberry or the real McCoy under Cygwin, just take that into consideration). -- René Berber
sa-update calling the wrong IP address
I recently had to entirely re-IP a network including the server running Spamassassin. When I run sa-update, it just hangs at the command prompt with a flashing cursor; same thing happens when I run sa-update -D but only after it calls the updates.spamassassin.org channel... Checking my firewall logs, it appears sa-update is calling the wrong LAN IP of our Windows DNS server (I understand SA-UPDATE runs updates through DNS). I guess my question is where does sa-update cache or obtain this DNS address? Was it captured during the original nmake process? All other DNS requests from clients and or software resolve DNS queries just fine; no other DNS issues on this network...I was unable to find any reference to this IP in the sa-update.bat file. Running Spamassassin 3.2.5 on Windows Server 2003/Exchange 2003.
Re: Getting hammered by backscatter
Benny Pedersen <[EMAIL PROTECTED]> wrote: > On Fri, November 7, 2008 19:31, mouss wrote: > > >>> postmaster@ > >> http://rfc-ignorant.org/policy-postmaster.php > > the rfci policy applies to postmaster as a recipient. nobody can force > > you to accept mail _from_ postmaster. > > how can anyone solve anything when postmasters cant talk together ? You miss the point; your link was not appropriate to the question and mouss simply indicated that. -- Sahil Tandon <[EMAIL PROTECTED]>
RE: Getting hammered by backscatter
> how can anyone solve anything when postmasters cant talk together ? > > doh > > > -- > Benny Pedersen > *snip* advertisement and link benny, do you trust emails from some postmaster at some domain and spend lots of time answering them? yeah, right. and btw benny, please stop spamming us w/ the need more webspace ads please??? DOH! - rh
Re: DNSBL timeouts - SOLVED
It sounds obvious now. BUT , before I added the UDP dns firewall rules. I could successfully do : lookups using the host command , lookups with the example snippet in the Net::DNS man page all DNS & RBL tests with my older SA installation ( 3.0.4 ) ... So I didn't think that I needed that UDP firewall rule. maybe the newert SA versions forces Net::DNS to use UDP where old versions didn't ... Oh well. Dan Kris Deugau wrote: Daniel Bourque wrote: After some playing around, turns out that Net::DNS performs certain test with via UDP port 53, therefore, I had to accept UDP packets from my nameserver's udp:53 ... u... *yes*, you have to accept UDP packets on port 53 O_o *Most* DNS traffic is UDP. If you're blocking port 53/UDP, you're blocking most of your DNS lookups - this isn't special to Net::DNS. -kgd
Re: DNSBL timeouts
Benny Pedersen wrote: On Fri, November 7, 2008 22:38, Daniel Bourque wrote: [3033] dbg: dns: Net::DNS version: 0.59 update this one *nod* Daniel, you may also want to look into upgrading SA itself; unfortunately most distribution-provided packages tend to go stale after a new patchlevel SA release is out. I've been using the RPMForge packages without issue; I also pick and choose which packages I install, however. You can get updated Net::DNS and SpamAssassin packages from them, properly built for RHEL3/4/5. -kgd
Re: DNSBL timeouts - SOLVED
Daniel Bourque wrote: After some playing around, turns out that Net::DNS performs certain test with via UDP port 53, therefore, I had to accept UDP packets from my nameserver's udp:53 ... u... *yes*, you have to accept UDP packets on port 53 O_o *Most* DNS traffic is UDP. If you're blocking port 53/UDP, you're blocking most of your DNS lookups - this isn't special to Net::DNS. -kgd
Re: DNSBL timeouts - SOLVED
Thanks for the reply. Ok, I upgraded [4918] dbg: dns: Net::DNS version: 0.63 but I still saw the same issue. I recalled that the problem started after I moved the server on my DMZ. After some playing around, turns out that Net::DNS performs certain test with via UDP port 53, therefore, I had to accept UDP packets from my nameserver's udp:53 the thing that really got me is that the old URIBNSBL plugin worked fine, must have used tcp dns lookups only. works great now. Dan Benny Pedersen wrote: On Fri, November 7, 2008 22:38, Daniel Bourque wrote: [3033] dbg: dns: Net::DNS version: 0.59 update this one
Re: DNSBL timeouts
On Fri, November 7, 2008 22:38, Daniel Bourque wrote: [3033] dbg: dns: Net::DNS version: 0.59 update this one -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
DNSBL timeouts
Hi, I'm having issues with SA spamassassin-3.2.4-1.el5 , some dnsbl tests consistantly time out. URI-DNSBL, URI-NS and DNSBL-MX I can get the URI-NS & URI-DNSBL to work if I replace the URIDNSBL.pm with the one from spamassassin-3.0.4. But the DNSBL-MX tests still time out.. I tested the example in the Net::DNS man page, works fine. I can use it find MX records... Looks like something in the SA Dns.pm is not working right for me. Thanks /tmp/junk99 is a capture of an email I sent from my gmail account [EMAIL PROTECTED] SpamAssassin]# spamassassin -tD < /tmp/junk99 [3033] dbg: logger: adding facilities: all [3033] dbg: logger: logging level is DBG [3033] dbg: generic: SpamAssassin version 3.2.4 [3033] dbg: config: score set 0 chosen. [3033] dbg: util: running in taint mode? yes [3033] dbg: util: taint mode: deleting unsafe environment variables, resetting PATH [3033] dbg: util: PATH included '/usr/kerberos/sbin', keeping [3033] dbg: util: PATH included '/usr/kerberos/bin', keeping [3033] dbg: util: PATH included '/usr/local/sbin', keeping [3033] dbg: util: PATH included '/usr/local/bin', keeping [3033] dbg: util: PATH included '/sbin', keeping [3033] dbg: util: PATH included '/bin', keeping [3033] dbg: util: PATH included '/usr/sbin', keeping [3033] dbg: util: PATH included '/usr/bin', keeping [3033] dbg: util: PATH included '/root/bin', which doesn't exist, dropping [3033] dbg: util: final PATH set to: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin [3033] dbg: dns: is Net::DNS::Resolver available? yes [3033] dbg: dns: Net::DNS version: 0.59 [3033] dbg: config: using "/etc/mail/spamassassin" for site rules pre files [3033] dbg: config: read file /etc/mail/spamassassin/init.pre [3033] dbg: config: read file /etc/mail/spamassassin/v310.pre [3033] dbg: config: read file /etc/mail/spamassassin/v312.pre [3033] dbg: config: read file /etc/mail/spamassassin/v320.pre [3033] dbg: config: using "/usr/share/spamassassin" for sys rules pre files [3033] dbg: config: using "/usr/share/spamassassin" for default rules dir [3033] dbg: config: read file /usr/share/spamassassin/10_default_prefs.cf [3033] dbg: config: read file /usr/share/spamassassin/20_advance_fee.cf [3033] dbg: config: read file /usr/share/spamassassin/20_body_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_compensate.cf [3033] dbg: config: read file /usr/share/spamassassin/20_dnsbl_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_drugs.cf [3033] dbg: config: read file /usr/share/spamassassin/20_dynrdns.cf [3033] dbg: config: read file /usr/share/spamassassin/20_fake_helo_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_head_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_html_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_imageinfo.cf [3033] dbg: config: read file /usr/share/spamassassin/20_meta_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_net_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_phrases.cf [3033] dbg: config: read file /usr/share/spamassassin/20_ratware.cf [3033] dbg: config: read file /usr/share/spamassassin/20_uri_tests.cf [3033] dbg: config: read file /usr/share/spamassassin/20_vbounce.cf [3033] dbg: config: read file /usr/share/spamassassin/23_bayes.cf [3033] dbg: config: read file /usr/share/spamassassin/25_accessdb.cf [3033] dbg: config: read file /usr/share/spamassassin/25_antivirus.cf [3033] dbg: config: read file /usr/share/spamassassin/25_asn.cf [3033] dbg: config: read file /usr/share/spamassassin/25_dcc.cf [3033] dbg: config: read file /usr/share/spamassassin/25_dkim.cf [3033] dbg: config: read file /usr/share/spamassassin/25_domainkeys.cf [3033] dbg: config: read file /usr/share/spamassassin/25_hashcash.cf [3033] dbg: config: read file /usr/share/spamassassin/25_pyzor.cf [3033] dbg: config: read file /usr/share/spamassassin/25_razor2.cf [3033] dbg: config: read file /usr/share/spamassassin/25_replace.cf [3033] dbg: config: read file /usr/share/spamassassin/25_spf.cf [3033] dbg: config: read file /usr/share/spamassassin/25_textcat.cf [3033] dbg: config: read file /usr/share/spamassassin/30_text_de.cf [3033] dbg: config: read file /usr/share/spamassassin/30_text_fr.cf [3033] dbg: config: read file /usr/share/spamassassin/30_text_it.cf [3033] dbg: config: read file /usr/share/spamassassin/30_text_nl.cf [3033] dbg: config: read file /usr/share/spamassassin/30_text_pl.cf [3033] dbg: config: read file /usr/share/spamassassin/30_text_pt_br.cf [3033] dbg: config: read file /usr/share/spamassassin/50_scores.cf [3033] dbg: config: read file /usr/share/spamassassin/60_awl.cf [3033] dbg: config: read file /usr/share/spamassassin/60_shortcircuit.cf [3033] dbg: config: read file /usr/share/spamassassin/60_whitelist.cf [3033] dbg: config: read file /usr/share/spamassassin/60_whitelist_dk.cf [3033] dbg: config: read file /usr/share/
Re: Checking for SPF & DKIM Checks
On 7 Nov 2008, at 09:22, Benny Pedersen wrote: On Fri, November 7, 2008 10:02, Neil wrote: My understanding is Mail::SPF is not needed if you have Mail::SPF::Query installed. currect, but Mail::SPF::Query does not support SPF rr in dns, Mail::SPF does Thanks. But still; how can I know that SPF and DKIM checks are working?
Re: Getting hammered by backscatter
On Fri, November 7, 2008 19:31, mouss wrote: >>> postmaster@ >> http://rfc-ignorant.org/policy-postmaster.php > the rfci policy applies to postmaster as a recipient. nobody can force > you to accept mail _from_ postmaster. how can anyone solve anything when postmasters cant talk together ? doh -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Using sender e-mail address or message content data in WHOIS search
On Fri, 7 Nov 2008, FractalBob wrote: Thanks, Mouss, for the pointers, but I still don't understand where the addresses and phone numbers in 70_sare_evilnum come from. Can SpamAssassin be configured to scan a message, pick up a domain and then do a WHOIS search, or did someone go through a few e-mails by hand, query WHOIS using the domain names found and add the phone #/address info to 70_sare_evilnum? I kind of doubt the second possibility, but had to ask ;-) Those rules have nothing to do with WHOIS or the domain registration data of the sender. From the rules page: 70_sare_evilnum*.cf Description: Addresses and phone numbers harvested from spam Somebody went through a spam corpus and pulled out addresses and phone numbers that were common. How often do you see a phone number or contact address in a spam any more? That is information that can be used to identify and prosecute the spammer. That's why they use hacked or fast-flux DNS websites these days. (Is anybody willing to do a hit analysis of the evilnum rules to see if they indeed do have any value any more?) A much better way to do that sort of thing now is to subscribe to the SOUGHT ruleset, which is dynamically generated from recent spam traffic. A SA plugin can certainly be written to perform WHOIS lookups on information derived from a message - as an experiment I wrote one that would look up the sending domain's registrar and compare it to a list of registrars known to be spam-friendly. However, this is likely to be considered abusive of the whois system and if put into production will likely not work for long - the whois providers will likely block your MTA's IP address fairly soon. So in other words, SA WHOIS lookups = bad idea. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...to announce there must be no criticism of the President or to stand by the President right or wrong is not only unpatriotic and servile, but is morally treasonous to the American public. -- Theodore Roosevelt, 1918 --- 4 days until Veterans Day
Re: Using sender e-mail address or message content data in WHOIS search
Thanks, Mouss, for the pointers, but I still don't understand where the addresses and phone numbers in 70_sare_evilnum come from. Can SpamAssassin be configured to scan a message, pick up a domain and then do a WHOIS search, or did someone go through a few e-mails by hand, query WHOIS using the domain names found and add the phone #/address info to 70_sare_evilnum? I kind of doubt the second possibility, but had to ask ;-) mouss-2 wrote: > > FractalBob wrote: >> Sure, they do spoof, but one could write a script that pokes around the >> message content, looking for a URL or signature and use that instead. >> >> I found some rulesets, 70_sare_evilnum*.cf, that seem to do what I want, >> but >> I don't know how to use them; documentation is scarce for SpamAssassin. >> Does >> anyone know what these files are and how to use them? >> > > these are SARE rules > > Visit > http://www.rulesemporium.com/rules.htm > and chose which rules you want to use. > > Then use sa-update to download them (periodically): > > http://wiki.apache.org/spamassassin/RuleUpdates > http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt > > for more docs, check > http://wiki.apache.org/spamassassin/FrontPage > and > http://spamassassin.apache.org/doc.html > > > > -- View this message in context: http://www.nabble.com/Using-sender-e-mail-address-or-message-content-data-in-WHOIS-search-tp20375286p20387122.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Getting hammered by backscatter
Benny Pedersen wrote: On Fri, November 7, 2008 03:33, Michelle Konzack wrote: I am rejecting ANY (!!!) messages coming from <*.ru> and <*.ua> domains where the "From:" header is from: MAILER-DAEMON@ ok postmaster@ http://rfc-ignorant.org/policy-postmaster.php the rfci policy applies to postmaster as a recipient. nobody can force you to accept mail _from_ postmaster. noreply@ no-reply@ ok
Re: Using sender e-mail address or message content data in WHOIS search
FractalBob wrote: Sure, they do spoof, but one could write a script that pokes around the message content, looking for a URL or signature and use that instead. I found some rulesets, 70_sare_evilnum*.cf, that seem to do what I want, but I don't know how to use them; documentation is scarce for SpamAssassin. Does anyone know what these files are and how to use them? these are SARE rules Visit http://www.rulesemporium.com/rules.htm and chose which rules you want to use. Then use sa-update to download them (periodically): http://wiki.apache.org/spamassassin/RuleUpdates http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt for more docs, check http://wiki.apache.org/spamassassin/FrontPage and http://spamassassin.apache.org/doc.html
Re: spamd -u
On Fri, 2008-11-07 at 10:51 -0500, Jean-Paul Natola wrote:
> I'm sorry all, where / how do I add the -u on spamd?
Wherever, however you invoke spamd.
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 04:45:57PM +0100, mouss wrote: > >> With hostnames there is a bigger change of failure (by just using a domain >> instead of exact hostname, letting f.e. dialup users from the domain forge >> the path). > > not sure I understand. people can't easily forge their rdns (in the What I meant was more of a configuration error from admin. ;) I.e. whitelist_from_rcvd [EMAIL PROTECTED] orange.fr domain.wl We already know this is a bad way (maybe dynamic orange users) even currently. I don't know if there is much chance of second+ level failure, it could be overlooked more easily: whitelist_from_rcvd [EMAIL PROTECTED] smtp*.orange.fr domain.wl Maybe domain.wl has dynamic users or some other bad servers? Who knows. I agree it's a bit far fetched and easily corrected when spotted. Maybe there could be even an failsafe option to detect "bad" received hosts. I probably would start using this if implemented. Hostname support also in trusted_networks would be especially handy. Good ideas, too little time to code..
spamd -u
I'm sorry all, where / how do I add the -u on spamd? Thanks,
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: On Fri, Nov 07, 2008 at 04:20:17PM +0200, Henrik K wrote: On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote: I'm not sure I like the ideas of whitelisting based on IP-addresses, it's too inflexible. Why would you not use hostnames? Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust would go from hostname to hostname, so it's ok. :) Too little time to think. IMO the right option is wildcards. You might as well ask then, why can't the sender part be regexed for convienence.. One thing I still have to add. IPs are a pretty foolproof way to whitelist. sure, IPs don't suffer dns temp failures, but when I intend to trust *.gandi.net, I really want to trust *.gandi.net, not resolve that one day, then have gandi add new relays that I don't trust, or even worst, having the IP assigned to another organization. and if you mean forged PTRs, then any software that trusts the PTR without actually resolving it back to the IP is bogus. Those of us running "real" MTAs don't have to suffer from such descrepancies. of course, it is theortically possible to forge the name and attack DNS so that it "fully" resolves, but in that case, a lot of other stuff would break anyway (for good or for bad, we rely on dns too much). With hostnames there is a bigger change of failure (by just using a domain instead of exact hostname, letting f.e. dialup users from the domain forge the path). not sure I understand. people can't easily forge their rdns (in the sense: FcrDNS. PTR alone is useless), and if they can, then they can do other dns attacks making all dns based checks useless. if you mean forging Received headers, well, that's not a problem as long as the relay path is correctly parsed (don't trust infos beyond last trusted received header).
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: why link that to trusted_networks? Obviously the whole IP path must be trusted (excluding the last one). You can use hostnames as well. But then you have to have trust path right, to trust later hostnames. maybe I misunderstood your "could even work ...". And perhaps it could support basic wildcards instead of regexps. That's probably the best option. That said, it is not very satisfactory. mixing perl regexps and "globbing" comes as a surprise to pcre users... Isn't the sender part globbed already? ;) yes it is. I was about that!
Re: enchanced whitelist_from_rcvd ?
Per Jessen wrote: > Matt Kettler wrote: > >> Per Jessen wrote: >>> Occasionally I'd like to do something like this: >>> >>> whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ >>> >> One problem.. That involves a regex, but whitelist_from is a "regular >> user" config option. >> >> In general, regular expressions are intentionally not used in >> "regular user" options due to the potential for a to possibly exploit >> the system. (this is why user_prefs can't contain rules unless you >> define allow_user_rules). >> >> So, SA actually went out of its way to prevent that from being >> allowed. > > Yes, I saw that in the code I've been reading some more and it looks like it is actually possible to use regex syntax in the domain part of whitelist_from_rcvd. The address part is sanitized, but the domain part isn't. /Per Jessen, Zürich
Re: Using sender e-mail address or message content data in WHOIS search
Sure, they do spoof, but one could write a script that pokes around the message content, looking for a URL or signature and use that instead. I found some rulesets, 70_sare_evilnum*.cf, that seem to do what I want, but I don't know how to use them; documentation is scarce for SpamAssassin. Does anyone know what these files are and how to use them? mouss-2 wrote: > > FractalBob wrote: >> Can SpamAssassin be configured to use the domain in the sender e-mail >> address >> or in the message content itself as an input parameter to, say, a WHOIS >> search, in order to locate either the sender or his ISP? I know this >> would >> be expensive, since it would require going out to the network, but it >> could >> be really useful. TIA! >> > > - there is no usable whois interface for that. most whois sites will > blacklist you if you knock them too much. > > - since spammers often forge the sender address, you don't really care > of the corresponding whois infos. > > -- View this message in context: http://www.nabble.com/Using-sender-e-mail-address-or-message-content-data-in-WHOIS-search-tp20375286p20381887.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Getting hammered by backscatter
On Fri, November 7, 2008 03:33, Michelle Konzack wrote: > I am rejecting ANY (!!!) messages coming from <*.ru> and <*.ua> domains > where the "From:" header is from: > > MAILER-DAEMON@ ok > postmaster@ http://rfc-ignorant.org/policy-postmaster.php > noreply@ > no-reply@ ok -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 04:20:17PM +0200, Henrik K wrote: > On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote: > > > > I'm not sure I like the ideas of whitelisting based on IP-addresses, > > it's too inflexible. Why would you not use hostnames? > > Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust > would go from hostname to hostname, so it's ok. :) Too little time to think. > IMO the right option is wildcards. You might as well ask then, why can't the > sender part be regexed for convienence.. One thing I still have to add. IPs are a pretty foolproof way to whitelist. With hostnames there is a bigger change of failure (by just using a domain instead of exact hostname, letting f.e. dialup users from the domain forge the path).
Re: Checking for SPF & DKIM Checks
On Fri, November 7, 2008 10:02, Neil wrote: > My understanding is Mail::SPF is not needed if you have > Mail::SPF::Query installed. currect, but Mail::SPF::Query does not support SPF rr in dns, Mail::SPF does -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Using sender e-mail address or message content data in WHOIS search
On Fri, November 7, 2008 09:43, mouss wrote: > - since spammers often forge the sender address, you don't really care > of the corresponding whois infos. whois 127.0.0.1 let them forge it :) -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote: > Henrik K wrote: > > > Then instead of asking for a lacking addition to a poor whitelisting > > method (in this case), we should enhance whitelist_from_rcvd to > > process received paths: > > > > whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 > > > > Should this be read to mean "whitelist from foobar if it came via > 1.2.3.4 AND 2.3.4.5"? That's an interesting option, but I can't see > much immediate use. Maybe when I've thought about it for a bit. Yes. > > Perhaps it could even work with hostnames as long as they stay inside > > trusted_networks. > > I'm not sure I like the ideas of whitelisting based on IP-addresses, > it's too inflexible. Why would you not use hostnames? Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust would go from hostname to hostname, so it's ok. :) Too little time to think. > > And perhaps it could support basic wildcards instead of regexps. > > I appreciate Matts explanation about whitelist_from_rcvd being a regular > user option, so maybe the right way would be > a "whitelist_from_rcvdregex" ? IMO the right option is wildcards. You might as well ask then, why can't the sender part be regexed for convienence..
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 03:07:59PM +0100, mouss wrote: >> >> Then instead of asking for a lacking addition to a poor whitelisting method >> (in this case), we should enhance whitelist_from_rcvd to process received >> paths: >> >> whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 > > why? I wouldn't put 30 IPs there... > > if user trusts his MTA, then rdns can be trusted, and there is no point > to go the IP way (note that if user doesn't trust MTA, then the IP can't > be trusted...). > >> >> Perhaps it could even work with hostnames as long as they stay inside >> trusted_networks. > > why link that to trusted_networks? Obviously the whole IP path must be trusted (excluding the last one). You can use hostnames as well. But then you have to have trust path right, to trust later hostnames. >> And perhaps it could support basic wildcards instead of regexps. > > That's probably the best option. > > That said, it is not very satisfactory. mixing perl regexps and > "globbing" comes as a surprise to pcre users... Isn't the sender part globbed already? ;)
Re: sa-learn journal location for teaching spamassassin on multiple hosts
On 07.11.08 12:45, Samy Ascha, Xel Media B.V. wrote: > I have recently setup a mailbox and a sa-learn script to start > teaching SpamAssassin. This was all no problem, but: > > We have an MX group of usually about 3 MTAs, which all run their own > content filter (amavis) and thus use their own SpamAssassin's > database. When we are gonna start teaching SpamAssassin with sa-learn, > I need to somehow sync the results in the journal to all these hosts. We have group of four MTA servers. However they don't run SA on MTA level (yet). We have users' mailboxes on shared storage cluster, so their bayes DB is on shared space. I'd solve your case by configuring MTA's w/o BAYES, or maybe by using users' configs, if possible - if the mail is sent to one user, should not be a problem. For mail sent to more users, somehow generic configuration and filtering will be used, so users may be willing to have the mail rechecked for spamminess. > Has anyone got experience with syncing sa-learn between multiple MTAs? > How did you solve this? Can SA sync with a journal in an arbitrary > location, or does it look for it in one preconfigged place? I am not sure if it's safe to use journal or bayes DB nfs-mounted... -- 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. Save the whales. Collect the whole set.
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: > Then instead of asking for a lacking addition to a poor whitelisting > method (in this case), we should enhance whitelist_from_rcvd to > process received paths: > > whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 > Should this be read to mean "whitelist from foobar if it came via 1.2.3.4 AND 2.3.4.5"? That's an interesting option, but I can't see much immediate use. Maybe when I've thought about it for a bit. > Perhaps it could even work with hostnames as long as they stay inside > trusted_networks. I'm not sure I like the ideas of whitelisting based on IP-addresses, it's too inflexible. Why would you not use hostnames? > And perhaps it could support basic wildcards instead of regexps. I appreciate Matts explanation about whitelist_from_rcvd being a regular user option, so maybe the right way would be a "whitelist_from_rcvdregex" ? /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: On Fri, Nov 07, 2008 at 02:38:22PM +0100, Per Jessen wrote: Henrik K wrote: On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. If the originator is static IP, add whole path to trusted_networks and use ALL_TRUSTED. I prefer to use that only for our own networks. That I whitelist one domain from a certain server(s) doesn't mean I want to whitelist everything. Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 why? I wouldn't put 30 IPs there... if user trusts his MTA, then rdns can be trusted, and there is no point to go the IP way (note that if user doesn't trust MTA, then the IP can't be trusted...). Perhaps it could even work with hostnames as long as they stay inside trusted_networks. why link that to trusted_networks? And perhaps it could support basic wildcards instead of regexps. That's probably the best option. That said, it is not very satisfactory. mixing perl regexps and "globbing" comes as a surprise to pcre users...
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 02:38:22PM +0100, Per Jessen wrote: > Henrik K wrote: > > > On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: > >> Yes, I saw that in the code - still, having a > >> whitelist_from_rcvdregex > >> would be very useful, people relay via their providers quite a lot. > >> I guess I'll have to write something up. > > > > If the originator is static IP, add whole path to trusted_networks and > > use ALL_TRUSTED. > > I prefer to use that only for our own networks. That I whitelist one > domain from a certain server(s) doesn't mean I want to whitelist > everything. Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 Perhaps it could even work with hostnames as long as they stay inside trusted_networks. And perhaps it could support basic wildcards instead of regexps.
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: > On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: >> Yes, I saw that in the code - still, having a >> whitelist_from_rcvdregex >> would be very useful, people relay via their providers quite a lot. >> I guess I'll have to write something up. > > If the originator is static IP, add whole path to trusted_networks and > use ALL_TRUSTED. I prefer to use that only for our own networks. That I whitelist one domain from a certain server(s) doesn't mean I want to whitelist everything. > Nothing prevents zombies sending through smarthosts anyway, Exactly. > that's much more secure in the long run. And you should be > dropping dialups at MTA anyway. That's surely up to me. /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: > Matt Kettler wrote: > > > Per Jessen wrote: > >> Occasionally I'd like to do something like this: > >> > >> whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ > >> > > One problem.. That involves a regex, but whitelist_from is a "regular > > user" config option. > > > > In general, regular expressions are intentionally not used in "regular > > user" options due to the potential for a to possibly exploit the > > system. (this is why user_prefs can't contain rules unless you define > > allow_user_rules). > > > > So, SA actually went out of its way to prevent that from being > > allowed. > > Yes, I saw that in the code - still, having a whitelist_from_rcvdregex > would be very useful, people relay via their providers quite a lot. I > guess I'll have to write something up. If the originator is static IP, add whole path to trusted_networks and use ALL_TRUSTED. Nothing prevents zombies sending through smarthosts anyway, that's much more secure in the long run. And you should be dropping dialups at MTA anyway.
Re: enchanced whitelist_from_rcvd ?
Matt Kettler wrote: > Per Jessen wrote: >> Occasionally I'd like to do something like this: >> >> whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ >> > One problem.. That involves a regex, but whitelist_from is a "regular > user" config option. > > In general, regular expressions are intentionally not used in "regular > user" options due to the potential for a to possibly exploit the > system. (this is why user_prefs can't contain rules unless you define > allow_user_rules). > > So, SA actually went out of its way to prevent that from being > allowed. Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
Per Jessen wrote: > Occasionally I'd like to do something like this: > > whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ > One problem.. That involves a regex, but whitelist_from is a "regular user" config option. In general, regular expressions are intentionally not used in "regular user" options due to the potential for a to possibly exploit the system. (this is why user_prefs can't contain rules unless you define allow_user_rules). So, SA actually went out of its way to prevent that from being allowed.
Re: Problems with the email adress of our company
Michelle Konzack writes: > Am 2008-10-30 08:53:17, schrieb Greg Troxel: > > So I wonder if domains with no > > vowels are normal in Germany (they are not normal in the US). > > In germany there are many domains ending withwhich is a > "limited liability company". Also I know Austrian and Swiss domains > with it. > > Maybe the spamassassin rules should respect this special case... Michelle, you should finish reading your mail before replying ;) we fixed that a few days ago. --j.
sa-learn journal location for teaching spamassassin on multiple hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear members, I have recently setup a mailbox and a sa-learn script to start teaching SpamAssassin. This was all no problem, but: We have an MX group of usually about 3 MTAs, which all run their own content filter (amavis) and thus use their own SpamAssassin's database. When we are gonna start teaching SpamAssassin with sa-learn, I need to somehow sync the results in the journal to all these hosts. I've checked out the --no-sync and --sync options and I think these options will give me exactly the tools I need for this job. I need to know the location of the journal though and I need to know if there are any pitfalls when syncing a SpamAssassin with a journal from another one on another server. Has anyone got experience with syncing sa-learn between multiple MTAs? How did you solve this? Can SA sync with a journal in an arbitrary location, or does it look for it in one preconfigged place? I hope u have some interresting thought about this issue. Thx much and regards, Samy Ascha Xel Media Internet Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkUKlQACgkQKIdvzp2UK/HoLgCgoLnB4PeP5Vg159g+f5YfSnCo LacAn22WXVRd8y/SSqPMKeNGi9qwEjaS =3sbv -END PGP SIGNATURE-
Re: Casino scams
Am 2008-11-01 17:00:09, schrieb Martin Gregorie: > I've started to see Casino spam in the last week and noticed, that of You mean this "Royal Casino" thing from whgich I get all 2 hours one? I like to have the rule since my current spamassassin let it through... Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Problems with the email adress of our company
Am 2008-10-31 13:31:16, schrieb Kai Schaetzl: > Easy: > Remote Sensing Solutions GmbH -> > Remote Sensing Solutions Ltd -> > rssltd.com But you know, that a GmBH is very different from a Ltd? They have different status. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Problems with the email adress of our company
Am 2008-10-30 08:53:17, schrieb Greg Troxel: > So I wonder if domains with no > vowels are normal in Germany (they are not normal in the US). In germany there are many domains ending withwhich is a "limited liability company". Also I know Austrian and Swiss domains with it. Maybe the spamassassin rules should respect this special case... Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Getting hammered by backscatter
Hi Chris. I have gotten over 200.000 of them with more then 2700 MByte... Now it is reduced to less then 200 backscatter per day. I am rejecting ANY (!!!) messages coming from <*.ru> and <*.ua> domains where the "From:" header is from: MAILER-DAEMON@ postmaster@ noreply@ no-reply@ Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Checking for SPF & DKIM Checks
On 7 Nov 2008, at 04:33, Matus UHLAR - fantomas wrote:
On 07.11.08 04:02, Neil wrote:
Is there a way to check if SPFs and DKIMs are being checked by
SpamAssassin?
Here is, I believe, the relevant spamassassin -D --lint output as far
as modules go:
[19018] dbg: dns: is Net::DNS::Resolver available? yes
[19018] dbg: dns: Net::DNS version: 0.63
[19018] dbg: diag: module not installed: Mail::SPF ('require' failed)
[19018] dbg: diag: module installed: Mail::SPF::Query, version
1.999001
[19018] dbg: diag: module installed: Mail::DomainKeys, version 1.0
[19018] dbg: diag: module installed: Mail::DKIM, version 0.31
My understanding is Mail::SPF is not needed if you have
Mail::SPF::Query installed.
Yes. It's also pointless imho to ise DomainKeys and DKIM both, DKIM is
preferred afaik.
Well, I have them both to for when other people use one or the other;
currently I'm not using either on outbound.
I've not seen any sign of SPF or DKIM (or DomainKeys) checks, neither
in any of my spam reports (and I've been checking just about every
spam recently) nor in debug output when I've run specific spams
through spamassassin manually.
Did you enable network checks?
I think so; I'm seeing DNSBLs, etc. in my scores.
-Neil.
Re: Accidentally Filtering through Spamassassin Twice
On 06.11.08 17:00, Joe Dragotta wrote: > With the forwarding to SA active in both the system and user level > procmailrc files, I was noting some odd behavior. The system level > filtering was correctly tagging about 90% of the spam as spam and > sending it to /dev/null/, and therefore was not being delivered. If the system-wide procmailrc is sourced by procmail running under users' accounts, it should use users' config files (user_prefs). However if you run procmail before delivering of mail under any account, that account's user_prefs is used for scoring. Note that dropping mail in such case is quite risky - sender sees mail was sent, recipient won't see it and you'll be unable to see what in the mail caused the problem. I would advise you to run SA at SMTP level (milter or other kind of filter), but rejects only score over 10 or so - we've had FPs when rejecting mail with score over 7. > However some email was making it through for processing by the user > level procmailrc file, being again forwarded to SA, and then SA was > rewriting the subject to ID it as spam (the user_prefs file was not set > to send spam to /dev/null). Thusly, I was receiving a small amount of > email tagged as spam. > As it turns out, the user_prefs file has higher scores assigned to some > of the tests. Therefore the system level filtering was not identifying > the email as spam (correctly so), but when the user_prefs file was > invoked, by way of the second call to SA (by the user level procmailrc) > the email was being tagged as spam, due to the higher scores in user_prefs. That's quite correct and I would advise you calling SA twice - with safe system settings from filter at SMTP level (so the mail would get rejected) and from users' procmail (or whatever) with users' settings. If you have enough of computer power, of course. Also note that system-wide filter (like milter) can pass the username to spamd, so mail received for one user will be checked with the users' settings already for the first time. However that is impossible if your system receives one mail for more users, which is still wuite common. Filter then must choose which user will it pass to spamd, whcih will mean users' configs and scoress won't be used, unless they pass the mail to SA again. > In any event, I am moving to use the spamd/c combination, in lieu of > invoking SA from procmail. hardly "in the lieu". You cannot replace procmail by spamc. You can replace spamassassin with spamc from procmail, or you can replace procmail for milter, amavis or different filter. > <100% opinion> > It may be a gray area, but perhaps as a point of future reference (and > perhaps policy), it would seem that questions regarding the invocation > of SA using procmail are well within the topic of this group. Not the way you first raised the question. -- 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. Windows 2000: 640 MB ought to be enough for anybody
Re: Using sender e-mail address or message content data in WHOIS search
> FractalBob wrote: > >Can SpamAssassin be configured to use the domain in the sender e-mail > >address > >or in the message content itself as an input parameter to, say, a WHOIS > >search, in order to locate either the sender or his ISP? I know this would > >be expensive, since it would require going out to the network, but it could > >be really useful. TIA! On 07.11.08 09:43, mouss wrote: > - there is no usable whois interface for that. most whois sites will > blacklist you if you knock them too much. > > - since spammers often forge the sender address, you don't really care > of the corresponding whois infos. However there are RelayCountry and ASN plugins that do some statistics with countries and autonomous systems th4e mail wass passing through. That is usable mostly for the BAYES filtering. -- 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. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows."
Re: Using sender e-mail address or message content data in WHOIS search
FractalBob wrote: Can SpamAssassin be configured to use the domain in the sender e-mail address or in the message content itself as an input parameter to, say, a WHOIS search, in order to locate either the sender or his ISP? I know this would be expensive, since it would require going out to the network, but it could be really useful. TIA! - there is no usable whois interface for that. most whois sites will blacklist you if you knock them too much. - since spammers often forge the sender address, you don't really care of the corresponding whois infos.
Re: enchanced whitelist_from_rcvd ?
Per Jessen wrote:
Occasionally I'd like to do something like this:
whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/
The situation is that domain.fr is relaying mail through their provider,
which has a number of smtp servers named smtpNN.orange.fr. If I were
to stick to the current whitelist_from_rcvd, I'd only be able to do:
whitelist_from_rcvd [EMAIL PROTECTED] orange.fr
But that opens to emails from domain.fr also being accepted when sent
from e.g. ADSL and dial-up lines on orange.fr. I think actually it
would be wanadoo.fr in this case,
Indeed. they use ".abo.wandoo.fr" ("abo" stands for "abonné", french for
"subscriber"). even if they switch to orange.fr, I guess they would use
".abo.orange.fr" or something like that (but this would not be a small
change, so I don't se it coming in the short/medium term).
BTW. Since few years, Orange.fr have started blocking port 25. not yet
complete though. (the few I've seen lately are listen on zen and sorbs).
but you get the idea.
yes.
Has anyone already looked at this?
enchanced whitelist_from_rcvd ?
Occasionally I'd like to do something like this: whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ The situation is that domain.fr is relaying mail through their provider, which has a number of smtp servers named smtpNN.orange.fr. If I were to stick to the current whitelist_from_rcvd, I'd only be able to do: whitelist_from_rcvd [EMAIL PROTECTED] orange.fr But that opens to emails from domain.fr also being accepted when sent from e.g. ADSL and dial-up lines on orange.fr. I think actually it would be wanadoo.fr in this case, but you get the idea. Has anyone already looked at this? /Per Jessen, Zürich
