Re: MSBL Email Blocklist (EBL) SA usage query
> Upgrade SA and that should fix it. My servers run Debian 8 with SA 3.4.0 + perl 5.20. I still get Nov 24 06:47:41.209 [12603] warn: Use of uninitialized value in regexp compilation at /etc/spamassassin/HashBL.pm line 52. Is 3.4.1 the minimum? -- -- Andreas :-)
Re: spamcop spamassassin reporting
Giles Coochey wrote: > Is there a current issue with reporting to spamcop? I had problems, too. Though, in my case I just got a warning message on the Spamcop web interface saying that messages sent to me were bouncing with "5.1.0 - Unknown address error" which was very probably due to problems on Spamcop's side. I don't know more, though. -- -- Andreas -- View this message in context: http://spamassassin.1065346.n5.nabble.com/spamcop-spamassassin-reporting-tp105878p105885.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Spam via whitelists
Matthias Leisi wrote > On Tue, Jul 2, 2013 at 7:09 PM, Andreas Schamanek > < > schamane@.ac > > wrote: > >> 2) ... mail servers (tu-graz.ac.at and ethz.ch are 2 examples) who >> forward their former users' mail to external addresses without prior >> filtering. ... They are whitelisted (in this case by JMF-WHITE and >> DNSWL_MED) >> which (would) lead to false negatives. Moreover, it renders our >> statistical analyses useless for their IPs. > > Put such sources in SA's trusted_networks. This also ensures that > blacklists (and whitelists) are applied to the IPs delivering to these > forwarding systems. Thanks, I didn't think about adding these sources to trusted_networks. It works (mostly), however it fixes only the SA part of the problem. I still think that spam must not be sent, ever. And that whitelists shouldn't list relaying IPs :/ Anyway, using trusted_networks I found that it doesn't work fully unless I manage to list their complete mail infrastructure. I didn't know that IPs from trusted_networks can actually be subject to evals. For instance: trusted_networks 82.130.75.186 82.130.99.26 129.132.202.4 129.132.183.133 still checks (and whitelists) 82.130.75.186 in case of Received: from tuvok.kom.tuwien.ac.at (tuvok.kom.tuwien.ac.at [192.35.241.66]) by mail.fam.tuwien.ac.at (8.14.3/8.14.3/Debian-9.4) with ... Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by tuvok.kom.tuwien.ac.at (8.14.5/8.14.5) with ... Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server ... Received: from edge10.ethz.ch (82.130.75.186) by CAS10.d.ethz.ch (172.31.38.210) with Microsoft SMTP Server ... Received: from phil4.ethz.ch (129.132.183.133) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server ... Received: from [65.59.210.13] (helo=mail2.soforum.com) by phil4.ethz.ch with esmtp (Exim 4.69) ... Only if I also add 172.31.38.210 (private address from a reserved block) it works as I expected it. Looks like I will use trusted_networks to save some CPU cycles but I'll also keep my meta rules. -- -- Andreas -- View this message in context: http://spamassassin.1065346.n5.nabble.com/Spam-via-whitelists-tp105635p105643.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Spam via whitelists
Hi SA fellows, I sometimes disagree with whitelists such as DNSWL_MED, chaosreigns.com/iprep/ or JMF-WHITE. There are 2 main issues: 1) Less often recently, but I did see freemail MTA IPs from Google, Yahoo! and other big players showing up on whitelists. Considering the amount of spam coming in from the networks of Google and Yahoo! I definitely do not want their IPs on whitelists, ever. 2) What's currently more annoying are colleagues of mine operating large mail servers (tu-graz.ac.at and ethz.ch are 2 examples) who forward their former users' mail to external addresses without prior filtering. Thus, we see spam coming from their (otherwise) trustworthy network. They are whitelisted (in this case by JMF-WHITE and DNSWL_MED) which (would) lead to false negatives. Moreover, it renders our statistical analyses useless for their IPs. There might be legal requirements explaining why they do forward spam. However, I still don't agree with the whitelists, then. For now, there are not that many cases, so I can work around them manually. Basically, I am using header __AS_FROM_2BIG Received =~ /\.(obsmtp|google|mac|yahoo)\.com/ header __AS_FROM_WHITE Received =~ /\.(tu-graz\.ac\.at|ethz\.ch)/ meta AS_DNSWL_NEUTRAL (RCVD_IN_DNSWL_MED && (__AS_FROM_2BIG || __AS_FROM_WHITE)) meta AS_IPREP_NEUTRAL (RCVD_IN_IPREPDNS_100 && (__AS_FROM_2BIG || __AS_FROM_WHITE)) meta AS_JMFW_NEUTRAL (RCVD_IN_JMF_W && (__AS_FROM_2BIG || __AS_FROM_WHITE)) Any better ideas? Should I file complaints? Simply report my colleagues MTAs? -- -- Andreas :-)
