Re: more_spam_from like more_spam_to
On Wed, 17 Sep 2014 13:43:49 +0100, RW rwmailli...@googlemail.com wrote: RW A lot of people don't put mailing lists through Spamassassin, most RW of them have already been spam filtered, and to get the best results RW you have to extend your internal network and maintain it. On 18.09.14 22:09, Ian Zimmerman wrote: Do you mean the trusted_networks setting here? no... they do not filter mail from mailing lists through SA. it is setting in outside spamassassin, usually in MTA, milter or procmail. trusted_networks is SA configuration setting so it can't be used when SA is avoided. Also, it has much different meaning than not scanning mail from those hosts. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; 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. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
Re: Simple question: load balancing spamd
18.09.2014, 22:58, Bob Proulx kirjoitti: Jari Fredriksson wrote: haproxy is just a small app capable of working as a proxy for http or plain tcp connections. HA. What are you using for the Bayes database on the distributed compute farm? (Just curious...) Bob MySQL /MariaDB 5.5
Re: more_spam_from like more_spam_to
On Fri, 19 Sep 2014 08:37:45 +0200, Matus UHLAR - fantomas uh...@fantomas.sk wrote: RW A lot of people don't put mailing lists through Spamassassin, most RW of them have already been spam filtered, and to get the best results RW you have to extend your internal network and maintain it. Ian Do you mean the trusted_networks setting here? Matus no... they do not filter mail from mailing lists through SA. it Matus is setting in outside spamassassin, usually in MTA, milter or Matus procmail. Matus trusted_networks is SA configuration setting so it can't be used Matus when SA is avoided. Also, it has much different meaning than not Matus scanning mail from those hosts. Well, that is not how I read RW's message. To me, it sounds like this: Lots of people don't put mailing lists through Spamassassin, in part because of the extra work that would be required if they did; namely, they'd have to extend their internal network and maintain it. This is required for best results. (I'm not a native English speaker either, but I've probably been speaking and reading it a bit longer than you. Just guessing, and of course no disrespect meant.) Only RW can clarify ... -- Please *no* private copies of mailing list or newsgroup messages. Local Variables: mode:claws-external End:
Re: more_spam_from like more_spam_to
On Thu, 18 Sep 2014 22:09:23 -0700 Ian Zimmerman wrote: On Wed, 17 Sep 2014 13:43:49 +0100, RW rwmailli...@googlemail.com wrote: RW A lot of people don't put mailing lists through Spamassassin, most RW of them have already been spam filtered, and to get the best RW results you have to extend your internal network and maintain it. Do you mean the trusted_networks setting here? Most DNSBL tests are done on the last relay into the internal network. I'm not say this should be done, I'm saying that it's one reason why scanning mailing list can be more trouble than it's worth.
Re: more_spam_from like more_spam_to
Am 19.09.2014 um 13:44 schrieb RW: On Thu, 18 Sep 2014 22:09:23 -0700 Ian Zimmerman wrote: On Wed, 17 Sep 2014 13:43:49 +0100, RW rwmailli...@googlemail.com wrote: RW A lot of people don't put mailing lists through Spamassassin, most RW of them have already been spam filtered, and to get the best RW results you have to extend your internal network and maintain it. Do you mean the trusted_networks setting here? Most DNSBL tests are done on the last relay into the internal network. I'm not say this should be done, I'm saying that it's one reason why scanning mailing list can be more trouble than it's worth but how is that different to any other mail? or how would you imagine to route incoming mailing-list mails somewhere else than to the MX of the RCPT domain which is the machine running SA? it's just a MX which receives a mail from X@Y and IP Z signature.asc Description: OpenPGP digital signature
Re: more_spam_from like more_spam_to
On Fri, 2014-09-19 at 13:47 +0200, Reindl Harald wrote: Am 19.09.2014 um 13:44 schrieb RW: On Thu, 18 Sep 2014 22:09:23 -0700 Ian Zimmerman wrote: On Wed, 17 Sep 2014 13:43:49 +0100, RW rwmailli...@googlemail.com wrote: RW A lot of people don't put mailing lists through Spamassassin, most RW of them have already been spam filtered, and to get the best RW results you have to extend your internal network and maintain it. Do you mean the trusted_networks setting here? Most DNSBL tests are done on the last relay into the internal network. I'm not say this should be done, I'm saying that it's one reason why scanning mailing list can be more trouble than it's worth but how is that different to any other mail? Probably because the last relay (the listserver) can be trusted (almost by definition) but its message sources cannot and some mailing lists don't check all submissions for spam. IME that applies especially to mailing lists that work alongside web forums to provide subscriber access by both web browser and e-mail. Obviously it is as easy to scan incoming e-mails before submitting them to the listserver and copying them to the web forum as it is to scan any inbound mail stream. However, it seems to be a lot harder to scan web input before accepting it into the forum and copying it to the associated mailing list. Consequently, a large proportion of the spam in these combined lists seems to be posted via the web forum. While volunteers usually monitor for and remove spam from the forum, that doesn't prevent web submitted spam from going out on the mailing list before the volunteers can recognise and deal with it. At the same time the web-sourced spam has no header-type information to show where it came from before it hit the listserver, so SA checks on it are pretty much limited to body, rawbody and URI rules: reliably scoring spam from these sources is hard. Martin
Re: more_spam_from like more_spam_to
RW A lot of people don't put mailing lists through Spamassassin, most RW of them have already been spam filtered, and to get the best results RW you have to extend your internal network and maintain it. Matus no... they do not filter mail from mailing lists through SA. it Matus is setting in outside spamassassin, usually in MTA, milter or Matus procmail. On 19.09.14 00:32, Ian Zimmerman wrote: To me, it sounds like this: Lots of people don't put mailing lists through Spamassassin, funny, and this sound to me exactly that the mail from mailing lists is not filtered by SA... I do this too, for some lists (although not all). Some lists can even unsubscribe user after receiving bounces ... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; 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. Linux is like a teepee: no Windows, no Gates and an apache inside...
Re: more_spam_from like more_spam_to
Am 19.09.2014 um 14:42 schrieb Martin Gregorie: On Fri, 2014-09-19 at 13:47 +0200, Reindl Harald wrote: Most DNSBL tests are done on the last relay into the internal network. I'm not say this should be done, I'm saying that it's one reason why scanning mailing list can be more trouble than it's worth but how is that different to any other mail? Probably because the last relay (the listserver) can be trusted (almost by definition) but its message sources cannot and some mailing lists don't check all submissions for spam. IME that applies especially to mailing lists that work alongside web forums to provide subscriber access by both web browser and e-mail. Obviously it is as easy to scan incoming e-mails before submitting them to the listserver and copying them to the web forum as it is to scan any inbound mail stream. However, it seems to be a lot harder to scan web input before accepting it into the forum and copying it to the associated mailing list. Consequently, a large proportion of the spam in these combined lists seems to be posted via the web forum. While volunteers usually monitor for and remove spam from the forum, that doesn't prevent web submitted spam from going out on the mailing list before the volunteers can recognise and deal with it. At the same time the web-sourced spam has no header-type information to show where it came from before it hit the listserver, so SA checks on it are pretty much limited to body, rawbody and URI rules: reliably scoring spam from these sources is hard. that may all be true but don't change anything how a mail is handeled nor does it bother the topic - no idea why now everybody hangs on *one example* instead the topic - and no - detect spam from the body is *not* hard, it works perfectly with the existing tags and bayes what i want is some levels for sender/sender-domains or rcpt/rcpt-domains with several negative scores and a simple name in a webinterface working similar to more_spam_from but *more different* and *self defined* levels frankly the whole question is in the subject and if i have one working example how to implement that in context of a single user sa-milter and assign domains/mailaddresses to that groups in local.cf i can make multiple ones so can we please stop that endless meta-discussions * is it possible * if yes how i can read the complete documentation and sourcecode for my own the intention of my question to a ML is has anybdody done that before and could provide a working example signature.asc Description: OpenPGP digital signature
sa-learn strip last Received: header for own MDA
Hi, still playing with sa-learn. If I feed sa-learn do I have to strip the last Received: header which is the Received header for my own MDA (imap-backend) before piping the message into sa-learn? Return-Path: spam...@whatever.com --- strip this header? -- Received: from mxrelay.mysendmail.com (mxrelay.mysendmail.com [xxx.xxx.xxx.xxx]) by imap-backend; Thu, 18 Sep 2014 22:25:35 +0200 Received: from emailstarget.com (emailstarget.com [5.196.112.99]) by mxrelay.mysendmail.com with ESMTP id s8IKPUkU005480 for t...@test123.com; Thu, 18 Sep 2014 22:25:33 +0200 To: t...@test123.com Subject: foo baar Message-ID: 2f56a1387b66e02d57493abba40bd...@emailstarget.com [...] Thanks Marcus
Re: sa-learn strip last Received: header for own MDA
On Fri, 19 Sep 2014, Marcus Schopen wrote: still playing with sa-learn. If I feed sa-learn do I have to strip the last Received: header which is the Received header for my own MDA (imap-backend) before piping the message into sa-learn? No, that shouldn't matter. The common bits will be learned as neutral because they appear in both ham and spam. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...for a nation to tax itself into prosperity is like a man standing in a bucket and trying to lift himself up by the handle. -- Winston Churchill --- Today: Talk Like a Pirate day
Spamhaus timeouts -- are they being DDoSed again?
I caught wind from a post on ddos-protection.org that Spamhaus is getting DDoS attacked again. We are getting timeouts to spamhaus servers intermittently. One test scan will work properly with no timeouts, the next will say deadline shrunk, then the calling callback/abort on key and spam will flow through. It looks like the timeouts are somewhere around 7-8 seconds that cause it fail. Can I tell spamassassin to wait until it gets a response or change that timeout to be a lot higher? Note: This happens on all of our relays that are spread across the country. All different ISPs, etc. Here is an email test [ root@server ~ ] # su defang -s /bin/bash -c 'spamassassin -x -p /etc/mail/ sa-mimedefang.cf -D' message5.eml ... ... removed content ... ... Sep 19 11:39:31.298 [32293] dbg: async: aborting after 9.038 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:75.15.168.192:sbl.spamhaus.org Sep 19 11:39:31.298 [32293] dbg: async: aborting after 8.937 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:1.194.124.98:sbl.spamhaus.org Sep 19 11:39:31.298 [32293] dbg: async: aborting after 8.951 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:2.124.80.208:sbl.spamhaus.org Sep 19 11:39:31.299 [32293] dbg: async: aborting after 8.965 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:2.127.80.208:sbl.spamhaus.org Sep 19 11:39:31.299 [32293] dbg: async: aborting after 8.933 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:1.196.124.98:sbl.spamhaus.org Sep 19 11:39:31.299 [32293] dbg: async: aborting after 9.076 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:76.25.168.192:sbl.spamhaus.org Sep 19 11:39:31.299 [32293] dbg: async: aborting after 8.921 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:1.193.124.98:sbl.spamhaus.org Sep 19 11:39:31.299 [32293] dbg: async: aborting after 8.927 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:1.197.124.98:sbl.spamhaus.org Sep 19 11:39:31.300 [32293] dbg: async: aborting after 9.081 s, deadline shrunk: URIBL_SBL_A, URI-DNSBL, DNSBL:71.13.127.74:sbl.spamhaus.org ... ... removed content ... ... Sep 19 11:39:31.329 [32293] dbg: async: calling callback/abort on key A/ 2.148.94.208.sbl.spamhaus.org, rule URIBL_SBL_A Sep 19 11:39:31.329 [32293] dbg: uridnsbl: complete_dnsbl_lookup aborted URIBL_SBL_A DNSBL:2.148.94.208:sbl.spamhaus.org Sep 19 11:39:31.329 [32293] dbg: async: calling callback/abort on key A/ 1.197.124.98.sbl.spamhaus.org, rule URIBL_SBL_A Sep 19 11:39:31.330 [32293] dbg: uridnsbl: complete_dnsbl_lookup aborted URIBL_SBL_A DNSBL:1.197.124.98:sbl.spamhaus.org Sep 19 11:39:31.330 [32293] dbg: async: calling callback/abort on key A/ 75.15.168.192.sbl.spamhaus.org, rule URIBL_SBL_A Sep 19 11:39:31.330 [32293] dbg: uridnsbl: complete_dnsbl_lookup aborted URIBL_SBL_A DNSBL:75.15.168.192:sbl.spamhaus.org Sep 19 11:39:31.330 [32293] dbg: async: calling callback/abort on key A/ 2.127.80.208.sbl.spamhaus.org, rule URIBL_SBL_A Sep 19 11:39:31.330 [32293] dbg: uridnsbl: complete_dnsbl_lookup aborted URIBL_SBL_A DNSBL:2.127.80.208:sbl.spamhaus.org Sep 19 11:39:31.330 [32293] dbg: async: calling callback/abort on key A/ 71.13.127.74.sbl.spamhaus.org, rule URIBL_SBL_A Sep 19 11:39:31.331 [32293] dbg: uridnsbl: complete_dnsbl_lookup aborted URIBL_SBL_A DNSBL:71.13.127.74:sbl.spamhaus.org ... ... removed content ... ... Sep 19 11:39:31.338 [32293] dbg: async: timing: 8.921 X DNSBL:1.193.124.98:s bl.spamhaus.org Sep 19 11:39:31.339 [32293] dbg: async: timing: 8.927 X DNSBL:1.197.124.98:s bl.spamhaus.org Sep 19 11:39:31.339 [32293] dbg: async: timing: 8.933 X DNSBL:1.196.124.98:s bl.spamhaus.org Sep 19 11:39:31.339 [32293] dbg: async: timing: 8.937 X DNSBL:1.194.124.98:s bl.spamhaus.org Sep 19 11:39:31.339 [32293] dbg: async: timing: 8.942 X DNSBL:1.192.124.98:s bl.spamhaus.org Sep 19 11:39:31.339 [32293] dbg: async: timing: 8.947 X DNSBL:2.126.80.208:s bl.spamhaus.org Sep 19 11:39:31.339 [32293] dbg: async: timing: 8.951 X DNSBL:2.124.80.208:s bl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 8.956 X DNSBL:2.125.80.208:s bl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 8.961 X DNSBL:2.148.94.208:s bl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 8.965 X DNSBL:2.127.80.208:s bl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 8.978 X DNSBL:163.68.246.50: sbl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 9.038 X DNSBL:75.15.168.192: sbl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 9.043 X DNSBL:74.91.172.66:s bl.spamhaus.org Sep 19 11:39:31.340 [32293] dbg: async: timing: 9.076 X DNSBL:76.25.168.192: sbl.spamhaus.org Sep 19 11:39:31.341 [32293] dbg: async: timing: 9.081 X DNSBL:71.13.127.74:s bl.spamhaus.org Sep 19 11:39:31.341 [32293] dbg: async: timing: 9.178 X DNSBL:syrupbeneath.com:dbl.spamhaus.org Sep 19 11:39:31.341 [32293] dbg: async: timing: 9.221 X DNSBL:sagedining.com:dbl.spamhaus.org ... ... removed content ... ...
Re: spamassassin rule to combat phishing
On Tue, Sep 16, 2014 at 5:27 PM, John Hardin jhar...@impsec.org wrote: On Tue, 16 Sep 2014, francis picabia wrote: Hello, We just received the most authentic looking phishing I've seen. It was professionally written, included a nice signature in the style used by people at my workplace, and the target link was an exact replica of an ezproxy website we run. The URL domain was only different by a few letters. I'm thinking we will see more of these. So here is a question perhaps someone can solve and many of us can benefit from... How can I make a uri rule which matches example.com.junk/ but does not match example.com/ uri URI_EXAMPLE_EXTRA m;^https?://(?:www\.)?example\.com[^/?];i That's a great one liner. I'm glad I asked. Thank you for this.
New TLDs, time to update RegistrarBoundaries
Seeing spam with URLs in new TLDs, (EG blah.link) time to update
RegistrarBoundaries.
If this silly chase continues at this rate, is it worth trying
to come up with some other method of doing that job?
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: New TLDs, time to update RegistrarBoundaries
On 9/19/2014 4:23 PM, David B Funk wrote: Seeing spam with URLs in new TLDs, (EG blah.link) time to update RegistrarBoundaries. If this silly chase continues at this rate, is it worth trying to come up with some other method of doing that job? We are working on solutions expected for the 3.4.1 release on ~9/30.
Re: New TLDs, time to update RegistrarBoundaries
On 09/19/2014 10:23 PM, David B Funk wrote: Seeing spam with URLs in new TLDs, (EG blah.link) time to update RegistrarBoundaries. If this silly chase continues at this rate, is it worth trying to come up with some other method of doing that job? http://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm includes the link TLD should be a drop in replacement for the one you have now (pls make a backup , in case)
Re: sa-learn strip last Received: header for own MDA
On 19 Sep 2014, at 09:06 , Marcus Schopen li...@localguru.de wrote: still playing with sa-learn. If I feed sa-learn do I have to strip the last Received: header which is the Received header for my own MDA (imap-backend) before piping the message into sa-learn? All you need to do is make sure that you feed both ham and spam into sa-learn. A mistake many people make is to train only spam. -- The Salvation Army Band played and the children drunk lemonade and the morning lasted all day, all day. And through an open window came like Sinatra in a younger day pushing the town away
