Re: dropbox phish

2016-11-03 Thread RW
On Thu, 03 Nov 2016 13:38:30 -0400
Kris Deugau wrote:


> header RCVD_IN_XBL  eval:check_rbl('zen-lastexternal',
> 'zen.spamhaus.org.', '^127\.0\.0\.[45678]$')
> 
> Why are you (re)defining a near-duplicate of this?  Was the stock rule
> as above also misbehaving?
> 
> Note that the Spamhaus rules are split up somewhat as they're intended
> for different IPs:
> 
> header __RCVD_IN_ZEN   eval:check_rbl('zen', 'zen.spamhaus.org.')
> header RCVD_IN_SBL eval:check_rbl_sub('zen', '127.0.0.2')
> header RCVD_IN_SBL_CSS eval:check_rbl_sub('zen', '127.0.0.3')
> 
> These are explicitly designed to look up all Received: IPs as "places
> you probably don't want to accept mail from, period, even if it takes
> a hop through a non-listed innocent server".  They're scored to
> match, so that legitimate senders on dynamic IPs who happen to
> inherit a "dirty" IP don't get blocked just on this basis.

There are good arguments for not discarding or rejecting based on a deep
XBL test, but the only way of knowing whether it's worth scoring is to
try it.

I score a deep XBL rule at 1 point. It would stand more because the
rule FPs are on very low scoring emails. 

OTOH I would expect a rule like that to vary lot in performance. 


Re: TxRep very slow

2016-11-03 Thread Sean Greenslade
On November 3, 2016 11:41:07 AM PDT, Birta Levente  
wrote:
>I do not use spamassissin daemon. It's called by amavisd 2.10
>

You're probably better off asking on an amavis list in that case. I have no 
experience with amavis.

However, given that it seems to be a lock contention issue, you might see if 
there's any setting in amavis to prevent parallel tests.

--Sean




Re: TxRep very slow

2016-11-03 Thread Birta Levente
I do not use spamassissin daemon. It's called by amavisd 2.10

On Thu, Nov 3, 2016, 20:23 Sean Greenslade  wrote:

> On October 13, 2016 5:39:50 AM PDT, Levente Birta 
> wrote:
> >Hi
> >
> >I have postfix with amavisd as content_filter and spamassassin 3.4.2
> >When I enable the TxRep plugin the mail stay very long in the SA check:
> >
> >
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: mode is
> >384
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: created
> >/var/spool/amavisd/.spamassassin/tx-reputation.
> lock.wsrv.benvenutionline.ro.24727
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 0 retries
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: link to /var/spool/amavisd/.spamassassin/tx-reputation.lock:
> >
> >link ok
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: auto-whitelist:
> >tie-ing to DB file of type DB_File R/W in
> >/var/spool/amavisd/.spamassassin/tx-reputation
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: auto-whitelist:
> >db-based 55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated|ip=none
> >scores 0/0
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun -
> >tag TXREP_MSG_ID is now ready, value: 0.0
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun -
> >tag TXREP_MSG_ID_COUNT is now ready, value: 0.0
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun -
> >tag TXREP_MSG_ID_PRESCORE is now ready, value: -1.7
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: TxRep:
> >reputation: none, count: 0, weight: 1.0, delta: 0.000, MSG_ID:
> >55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: TxRep: active,
> >55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated pre-score: -1.72,
> >
> >autolearn score: -1.719, IP: 81.196.63.17, address: x...@gmail.com
> >signed by gmail.com
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: mode is
> >384
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: created
> >/var/spool/amavisd/.spamassassin/tx-reputation.
> lock.wsrv.benvenutionline.ro.24727
> >Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 0 retries
> >Oct 13 15:28:41 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 1 retries
> >Oct 13 15:28:42 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 2 retries
> >Oct 13 15:28:43 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 3 retries
> >Oct 13 15:28:44 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 4 retries
> >Oct 13 15:28:45 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 5 retries
> >Oct 13 15:28:46 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 6 retries
> >Oct 13 15:28:47 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 7 retries
> >Oct 13 15:28:48 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 8 retries
> >Oct 13 15:28:50 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 9 retries
> >Oct 13 15:28:51 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 10 retries
> >Oct 13 15:28:52 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 11 retries
> >Oct 13 15:28:53 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 12 retries
> >Oct 13 15:28:54 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 13 retries
> >Oct 13 15:28:55 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> >/var/spool/amavisd/.spamassassin/tx-reputation with 14 retries
> >Oct 13 15:28:56 wsrv amavis[24727]: (24727-01) SA dbg: locker:
> >safe_lock: trying to get lock on
> 

Re: TxRep very slow

2016-11-03 Thread Sean Greenslade
On October 13, 2016 5:39:50 AM PDT, Levente Birta  wrote:
>Hi
>
>I have postfix with amavisd as content_filter and spamassassin 3.4.2
>When I enable the TxRep plugin the mail stay very long in the SA check:
>
>
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: mode is
>384
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: created 
>/var/spool/amavisd/.spamassassin/tx-reputation.lock.wsrv.benvenutionline.ro.24727
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 0 retries
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: link to /var/spool/amavisd/.spamassassin/tx-reputation.lock:
>
>link ok
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: auto-whitelist: 
>tie-ing to DB file of type DB_File R/W in 
>/var/spool/amavisd/.spamassassin/tx-reputation
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: auto-whitelist: 
>db-based 55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated|ip=none 
>scores 0/0
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun - 
>tag TXREP_MSG_ID is now ready, value: 0.0
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun - 
>tag TXREP_MSG_ID_COUNT is now ready, value: 0.0
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun - 
>tag TXREP_MSG_ID_PRESCORE is now ready, value: -1.7
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: TxRep: 
>reputation: none, count: 0, weight: 1.0, delta: 0.000, MSG_ID: 
>55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: TxRep: active, 
>55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated pre-score: -1.72,
>
>autolearn score: -1.719, IP: 81.196.63.17, address: x...@gmail.com 
>signed by gmail.com
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: mode is
>384
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: created 
>/var/spool/amavisd/.spamassassin/tx-reputation.lock.wsrv.benvenutionline.ro.24727
>Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 0 retries
>Oct 13 15:28:41 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 1 retries
>Oct 13 15:28:42 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 2 retries
>Oct 13 15:28:43 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 3 retries
>Oct 13 15:28:44 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 4 retries
>Oct 13 15:28:45 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 5 retries
>Oct 13 15:28:46 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 6 retries
>Oct 13 15:28:47 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 7 retries
>Oct 13 15:28:48 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 8 retries
>Oct 13 15:28:50 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 9 retries
>Oct 13 15:28:51 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 10 retries
>Oct 13 15:28:52 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 11 retries
>Oct 13 15:28:53 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 12 retries
>Oct 13 15:28:54 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 13 retries
>Oct 13 15:28:55 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 14 retries
>Oct 13 15:28:56 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 15 retries
>Oct 13 15:28:57 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
>safe_lock: trying to get lock on 
>/var/spool/amavisd/.spamassassin/tx-reputation with 16 retries
>Oct 13 15:28:58 wsrv amavis[24727]: (24727-01) SA dbg: locker: 

Re: dropbox phish

2016-11-03 Thread Kris Deugau
Alex wrote:
> Hi,
> 
> On Wed, Nov 2, 2016 at 10:36 AM, Kris Deugau  wrote:
>> Alex wrote:
>>> I've had to lower the score on my header XBL check because it was
>>> triggering on so many dynamic IPs that were clearly reassigned to new
>>> users, then being blacklisted. I'd appreciate it if anyone could
>>> provide additional input on how they might use something like this.
>>>
>>> header   RCVD_IN_XBL_ALLeval:check_rbl_sub('zen', '127.0.0.[45678]')
>>> describe RCVD_IN_XBL_ALLReceived via a relay in Spamhaus SBL-XBL
>>> tflags   RCVD_IN_XBL_ALLnet
>>> scoreRCVD_IN_XBL_ALL0.01
>>
>> If this is really hitting on lots of legitimate mail, you probably have
>> a trust path issue.  This should only check the IP that handed the
>> message to your mail server.  It should NOT be checking the IP that the
>> message originated from unless you really want to refuse mail from any
>> IP that has recently had an infected PC on or behind it.
>>
>> You shouldn't need to (re)define this in any case, and I'm not certain
>> without rereading the man page if or how this will behave somewhat
>> differently to the stock RCVD_IN_XBL rule - that could be the problem
>> all on its own.
> 
> Yes, as the rule currently stands, it was hitting on any Received
> header, including the origin IP from which the message was sent.
> Should there be some sort of "last-external" to signify which IP to
> check?

Yes, as per the stock rule, and the Mail::SpamAssassin::Conf man page:

header RCVD_IN_XBL  eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.0\.0\.[45678]$')

Why are you (re)defining a near-duplicate of this?  Was the stock rule
as above also misbehaving?

Note that the Spamhaus rules are split up somewhat as they're intended
for different IPs:

header __RCVD_IN_ZEN   eval:check_rbl('zen', 'zen.spamhaus.org.')
header RCVD_IN_SBL eval:check_rbl_sub('zen', '127.0.0.2')
header RCVD_IN_SBL_CSS eval:check_rbl_sub('zen', '127.0.0.3')

These are explicitly designed to look up all Received: IPs as "places
you probably don't want to accept mail from, period, even if it takes a
hop through a non-listed innocent server".  They're scored to match, so
that legitimate senders on dynamic IPs who happen to inherit a "dirty"
IP don't get blocked just on this basis.

header RCVD_IN_XBL  eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.0\.0\.[45678]$')
header RCVD_IN_PBL  eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.0\.0\.1[01]$')

The XBL and PBL sublists are ONLY checked for the relay IP, but because
of how eval:check_rbl and eval:check_rbl_sub interact, as per the man
page, these two use their own check_rbl, instead of check_rbl_sub.

If you need to redefine these because you have a local datafeed, or
key-validated DNS access, copy-paste the stock rule as-is, and only
replace the "zen.spamhaus.org" zone base name as appropriate.

-kgd


Re: uceprotect issue

2016-11-03 Thread RW
On Thu, 3 Nov 2016 17:32:00 +0100
Matus UHLAR - fantomas wrote:

> >On Thu, 3 Nov 2016 15:34:04 +0100
> >MHielder wrote:
> >  
> >> >  Zitat von Marco :
> >> >
> >> > UCE Protect has a very questionable reputation, foremost reason
> >> > is that they do charge money for delisting entries.
> >> >  
> >> A that old lie, that one has to pay to be removed again?
> >> Really?  
> 
> On 03.11.16 15:27, RW wrote:
> >No, not really. What he actually wrote was "they do charge money for
> >delisting entries" and that's clearly true:  
> 
> It's for immediate delisting, not for delisting itself.
> the delisting happens automatically, the fee is for doing it faster

Yes, obviously. But do "charge money for delisting entries" which is
what was asserted


Re: Anyone else just blocking the ".top" TLD?

2016-11-03 Thread Shawn Bakhtiar
Well... I guess that depends on what your definition of legitimate is I 
suppose... in my case (for our corporate emails) that would not be considered 
legit. Cool interface, but no mater what I typed on the keyboard it displayed 
its own search text, and the results were bogus. so...

I just ran a search on .xyz domain hits on our SMTP gateway... we are still 
getting A LOT of hits from that TLD that are NOT legit (at least for us).

Here is just a small sample (from 343) barrage from one domain:
Oct 16 05:59:01 smtp sendmail[3427]: u9GCwuvm003427: 
from=>, size=0, class=0, 
nrcpts=0, proto=ESMTP, daemon=MTA, relay=[69.94.151.224]
Oct 16 06:48:27 smtp sendmail[4645]: u9GDmM58004645: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.221]
Oct 16 07:41:45 smtp sendmail[5928]: u9GEfeS1005928: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.224]
Oct 16 07:55:43 smtp sendmail[6252]: u9GEtcLs006252: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.221]
Oct 16 08:16:41 smtp sendmail[6790]: u9GFGaQV006790: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.222]
Oct 16 08:17:14 smtp sendmail[6800]: u9GFH9A4006800: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 08:18:49 smtp sendmail[6845]: u9GFIi1e006845: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.224]
Oct 16 08:25:34 smtp sendmail[6994]: u9GFPTuC006994: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.224]
Oct 16 08:29:48 smtp sendmail[7071]: u9GFThJX007071: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 08:41:11 smtp sendmail[7329]: u9GFf6ak007329: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 09:16:40 smtp sendmail[8149]: u9GGGZcd008149: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.221]
Oct 16 09:17:48 smtp sendmail[8176]: u9GGHhUc008176: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 09:25:40 smtp sendmail[8337]: u9GGPZ9C008337: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.222]
Oct 16 09:49:42 smtp sendmail[8896]: u9GGnbrQ008896: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.222]
Oct 16 09:51:51 smtp sendmail[8948]: u9GGpjow008948: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.220]
Oct 16 10:29:23 smtp sendmail[9864]: u9GHTIZ3009864: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.220]
Oct 16 10:33:19 smtp sendmail[9961]: u9GHXEJj009961: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.224]
Oct 16 10:57:42 smtp sendmail[10483]: u9GHvbIp010483: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 10:58:14 smtp sendmail[10494]: u9GHw9Ca010494: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 11:02:22 smtp sendmail[10614]: u9GI2HoX010614: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.224]
Oct 16 11:12:39 smtp sendmail[10860]: u9GICYxE010860: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.220]
Oct 16 11:28:57 smtp sendmail[11234]: u9GISq19011234: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 11:42:11 smtp sendmail[11526]: u9GIg6f3011526: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.223]
Oct 16 11:48:17 smtp sendmail[11688]: u9GImCd0011688: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.222]
Oct 16 11:51:27 smtp sendmail[11781]: u9GIpMUC011781: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.221]
Oct 16 11:58:30 smtp sendmail[11929]: u9GIwPkv011929: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.224]
Oct 16 12:00:22 smtp sendmail[11969]: u9GJ0HO8011969: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.221]
Oct 16 13:51:22 smtp sendmail[14469]: u9GKpGUY014469: 
from=, size=0, class=0, nrcpts=0, proto=ESMTP, 
daemon=MTA, relay=[69.94.151.220]
Oct 16 14:40:48 smtp 

Re: Anyone else just blocking the ".top" TLD?

2016-11-03 Thread John Hardin

On Thu, 3 Nov 2016, Vincent Fox wrote:


TOP remains at the err... top of abuse heap.

XYZ insights anyone?  They have been on my reject list for a long time


This is an interesting statistics page I had not seen before:
https://ntldstats.com/fraud


Hmm. Autoforward them all to the ICANN board members' email addresses? 
They caused the problem in the first place, after all, with their 
promiscuous creation of new TLDs.


(I kid (sorta))

--
 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
---
  "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
  does quite what I want. I wish Christopher Robin was here."
   -- Peter da Silva in a.s.r
---
 3 days until Daylight Saving Time ends in U.S. - Fall Back


Re: Anyone else just blocking the ".top" TLD?

2016-11-03 Thread Vincent Fox
Indeed, that is what is happening.  I have had requests for

overrides.  I hate maintaining overrides if I no longer need to

even list the domain.  See driver.xyz for example which is legit.


This is an interesting statistics page I had not seen before:


https://ntldstats.com/fraud


[https://ntldstats.com/img/meta/fraud.jpg]

Statistic of suspicious/fraudulent Domains in new gTLDs 
...
ntldstats.com
Suspicious Domains in new gTLDs namespace ... TLDs with suspicious Domains: 209 
(17.59%)


Per that, TOP accounts for 64% of the problem.

SCIENCE is next at a mere 8%.


While XYZ comes in at #15 on the SURBL abused domains list

at present in raw numbers, as a percentage of it's email volume

it seems it's abuse is quite low.


From: Shawn Bakhtiar 
Sent: Thursday, November 3, 2016 9:33:59 AM
To: users@spamassassin.apache.org
Subject: Re: Anyone else just blocking the ".top" TLD?

Unless you have customers/employees/vendors complaining that they are not 
receiving legitimate email from that TLD why would you un block it??


On Nov 3, 2016, at 9:27 AM, Vincent Fox 
> wrote:

Resurrecting thread

TOP remains at the err... top of abuse heap.

XYZ insights anyone?  They have been on my reject list
for a long time, but claim to be cleaning it up.  Thinking to
drop my shields on this one.

https://gen.xyz/blog/antiabuse

.

My current total-block list:
From:link   REJECT
From:websiteREJECT
From:berlin REJECT
From:club   REJECT
From:email  REJECT
From:csr24.emailOK
From:guru   REJECT
From:wang   REJECT
From:xyzREJECT
From:driver.xyz ACCEPT
From:photographyREJECT
From:rocks  REJECT
From:click  REJECT
From:xn--czrs0t REJECT
From:xn--hxt814eREJECT
From:xn--flw351eREJECT
From:xn--qcka1pmc   REJECT
From:xn--45q11c REJECT
From:xn--vermgensberatung-pwb   REJECT
From:xn--vermgensberater-ctbREJECT
From:xn--p1acf  REJECT
From:xn--vhquv  REJECT
From:xn--xhq521bREJECT
From:xn--1qqw23aREJECT
From:xn--kput3i REJECT
From:xn--4gbrim REJECT
From:xn--czr694bREJECT
From:xn--80adxhks   REJECT
From:xn--ses554gREJECT
From:xn--czru2d REJECT
From:xn--rhqv96gREJECT
From:xn--nqv7f  REJECT
From:xn--i1b6b1a6a2eREJECT
From:xn--nqv7fs00emaREJECT
From:xn--c1avg  REJECT
From:xn--d1acj3bREJECT
From:xn--mgbab2bd   REJECT
From:xn--6frz82gREJECT
From:xn--io0a7i REJECT
From:xn--55qx5d REJECT
From:xn--fiq64b REJECT
From:xn--3bst00mREJECT
From:xn--6qq986b3xl REJECT
From:xn--fiq228c5hs REJECT
From:xn--3ds443gREJECT
From:xn--55qw42gREJECT
From:xn--zfr164bREJECT
From:xn--q9jyb4cREJECT
From:xn--ngbc5azd   REJECT
From:xn--80asehdb   REJECT
From:xn--80aswg REJECT
From:xn--unup4y REJECT
From:ninja  REJECT
From:gripe  REJECT
From:loans  REJECT
From:luxury REJECT
From:market REJECT
From:marketing  REJECT
From:pink   REJECT
From:whoswhoREJECT
From:work   REJECT
From:cricketREJECT
From:xn--plai   REJECT
From:review REJECT
From:countryREJECT
From:kimREJECT
From:scienceREJECT
From:party  REJECT
From:gq REJECT
From:topREJECT
From:unoREJECT
From:winREJECT
From:download   REJECT
From:tk REJECT
From:pw REJECT
From:international  REJECT
From:slice.internationalOK
From:date   REJECT
From:gdnREJECT
From:proREJECT
From:mm.law.pro OK
From:npocpa.pro OK
From:bidREJECT
From:trade  REJECT
From:press  REJECT
From:faith  REJECT
From:racing REJECT
From:stream REJECT
From:diet   REJECT
From:tokyo  REJECT
From:accountant REJECT
From:webcam REJECT
From:help   REJECT
From:space  REJECT
From:menREJECT



Re: Anyone else just blocking the ".top" TLD?

2016-11-03 Thread Vincent Fox
Resurrecting thread

TOP remains at the err... top of abuse heap.

XYZ insights anyone?  They have been on my reject list
for a long time, but claim to be cleaning it up.  Thinking to
drop my shields on this one.

https://gen.xyz/blog/antiabuse
[http://gen.xyz/wp-content/themes/xyz/images/facebook-square-logo.png]

XYZ says NO to abuse | .xyz Domain Names | Join Generation 
XYZ
gen.xyz
It's safe to say that almost everyone likes a good party. You invite your 
friends, enjoy the food & festivities, and make sure there's fun to be had for 
everyone ...


My current total-block list:
From:link   REJECT
From:websiteREJECT
From:berlin REJECT
From:club   REJECT
From:email  REJECT
From:csr24.emailOK
From:guru   REJECT
From:wang   REJECT
From:xyzREJECT
From:driver.xyz ACCEPT
From:photographyREJECT
From:rocks  REJECT
From:click  REJECT
From:xn--czrs0t REJECT
From:xn--hxt814eREJECT
From:xn--flw351eREJECT
From:xn--qcka1pmc   REJECT
From:xn--45q11c REJECT
From:xn--vermgensberatung-pwb   REJECT
From:xn--vermgensberater-ctbREJECT
From:xn--p1acf  REJECT
From:xn--vhquv  REJECT
From:xn--xhq521bREJECT
From:xn--1qqw23aREJECT
From:xn--kput3i REJECT
From:xn--4gbrim REJECT
From:xn--czr694bREJECT
From:xn--80adxhks   REJECT
From:xn--ses554gREJECT
From:xn--czru2d REJECT
From:xn--rhqv96gREJECT
From:xn--nqv7f  REJECT
From:xn--i1b6b1a6a2eREJECT
From:xn--nqv7fs00emaREJECT
From:xn--c1avg  REJECT
From:xn--d1acj3bREJECT
From:xn--mgbab2bd   REJECT
From:xn--6frz82gREJECT
From:xn--io0a7i REJECT
From:xn--55qx5d REJECT
From:xn--fiq64b REJECT
From:xn--3bst00mREJECT
From:xn--6qq986b3xl REJECT
From:xn--fiq228c5hs REJECT
From:xn--3ds443gREJECT
From:xn--55qw42gREJECT
From:xn--zfr164bREJECT
From:xn--q9jyb4cREJECT
From:xn--ngbc5azd   REJECT
From:xn--80asehdb   REJECT
From:xn--80aswg REJECT
From:xn--unup4y REJECT
From:ninja  REJECT
From:gripe  REJECT
From:loans  REJECT
From:luxury REJECT
From:market REJECT
From:marketing  REJECT
From:pink   REJECT
From:whoswhoREJECT
From:work   REJECT
From:cricketREJECT
From:xn--plai   REJECT
From:review REJECT
From:countryREJECT
From:kimREJECT
From:scienceREJECT
From:party  REJECT
From:gq REJECT
From:topREJECT
From:unoREJECT
From:winREJECT
From:download   REJECT
From:tk REJECT
From:pw REJECT
From:international  REJECT
From:slice.internationalOK
From:date   REJECT
From:gdnREJECT
From:proREJECT
From:mm.law.pro OK
From:npocpa.pro OK
From:bidREJECT
From:trade  REJECT
From:press  REJECT
From:faith  REJECT
From:racing REJECT
From:stream REJECT
From:diet   REJECT
From:tokyo  REJECT
From:accountant REJECT
From:webcam REJECT
From:help   REJECT
From:space  REJECT
From:menREJECT






Re: Anyone else just blocking the ".top" TLD?

2016-11-03 Thread Shawn Bakhtiar
Unless you have customers/employees/vendors complaining that they are not 
receiving legitimate email from that TLD why would you un block it??


On Nov 3, 2016, at 9:27 AM, Vincent Fox 
> wrote:

Resurrecting thread

TOP remains at the err... top of abuse heap.

XYZ insights anyone?  They have been on my reject list
for a long time, but claim to be cleaning it up.  Thinking to
drop my shields on this one.

https://gen.xyz/blog/antiabuse

.

My current total-block list:
From:link   REJECT
From:websiteREJECT
From:berlin REJECT
From:club   REJECT
From:email  REJECT
From:csr24.emailOK
From:guru   REJECT
From:wang   REJECT
From:xyzREJECT
From:driver.xyz ACCEPT
From:photographyREJECT
From:rocks  REJECT
From:click  REJECT
From:xn--czrs0t REJECT
From:xn--hxt814eREJECT
From:xn--flw351eREJECT
From:xn--qcka1pmc   REJECT
From:xn--45q11c REJECT
From:xn--vermgensberatung-pwb   REJECT
From:xn--vermgensberater-ctbREJECT
From:xn--p1acf  REJECT
From:xn--vhquv  REJECT
From:xn--xhq521bREJECT
From:xn--1qqw23aREJECT
From:xn--kput3i REJECT
From:xn--4gbrim REJECT
From:xn--czr694bREJECT
From:xn--80adxhks   REJECT
From:xn--ses554gREJECT
From:xn--czru2d REJECT
From:xn--rhqv96gREJECT
From:xn--nqv7f  REJECT
From:xn--i1b6b1a6a2eREJECT
From:xn--nqv7fs00emaREJECT
From:xn--c1avg  REJECT
From:xn--d1acj3bREJECT
From:xn--mgbab2bd   REJECT
From:xn--6frz82gREJECT
From:xn--io0a7i REJECT
From:xn--55qx5d REJECT
From:xn--fiq64b REJECT
From:xn--3bst00mREJECT
From:xn--6qq986b3xl REJECT
From:xn--fiq228c5hs REJECT
From:xn--3ds443gREJECT
From:xn--55qw42gREJECT
From:xn--zfr164bREJECT
From:xn--q9jyb4cREJECT
From:xn--ngbc5azd   REJECT
From:xn--80asehdb   REJECT
From:xn--80aswg REJECT
From:xn--unup4y REJECT
From:ninja  REJECT
From:gripe  REJECT
From:loans  REJECT
From:luxury REJECT
From:market REJECT
From:marketing  REJECT
From:pink   REJECT
From:whoswhoREJECT
From:work   REJECT
From:cricketREJECT
From:xn--plai   REJECT
From:review REJECT
From:countryREJECT
From:kimREJECT
From:scienceREJECT
From:party  REJECT
From:gq REJECT
From:topREJECT
From:unoREJECT
From:winREJECT
From:download   REJECT
From:tk REJECT
From:pw REJECT
From:international  REJECT
From:slice.internationalOK
From:date   REJECT
From:gdnREJECT
From:proREJECT
From:mm.law.pro OK
From:npocpa.pro OK
From:bidREJECT
From:trade  REJECT
From:press  REJECT
From:faith  REJECT
From:racing REJECT
From:stream REJECT
From:diet   REJECT
From:tokyo  REJECT
From:accountant REJECT
From:webcam REJECT
From:help   REJECT
From:space  REJECT
From:menREJECT



RE: Anyone else just blocking the ".top" TLD?

2016-11-03 Thread Motty Cruz
Getting tons of this: 

 

top.professional.wo...@ub6eual.cpatter.top

 

 

I am Just blocking  "*.top" 

 

 

From: Vincent Fox [mailto:vb...@ucdavis.edu] 
Sent: Thursday, November 03, 2016 9:27 AM
To: users@spamassassin.apache.org
Subject: Re: Anyone else just blocking the ".top" TLD?

 

Resurrecting thread 

 

TOP remains at the err... top of abuse heap.

 

XYZ insights anyone?  They have been on my reject list

for a long time, but claim to be cleaning it up.  Thinking to

drop my shields on this one.

 

https://gen.xyz/blog/antiabuse 


  

  XYZ says NO to abuse | .xyz Domain Names |
Join Generation XYZ

gen.xyz

It's safe to say that almost everyone likes a good party. You invite your
friends, enjoy the food & festivities, and make sure there's fun to be had
for everyone ...

 

My current total-block list:

From:link   REJECT

From:websiteREJECT

From:berlin REJECT

From:club   REJECT

From:email  REJECT

From:csr24.emailOK

From:guru   REJECT

From:wang   REJECT

From:xyzREJECT

From:driver.xyz ACCEPT

From:photographyREJECT

From:rocks  REJECT

From:click  REJECT

From:xn--czrs0t REJECT

From:xn--hxt814eREJECT

From:xn--flw351eREJECT

From:xn--qcka1pmc   REJECT

From:xn--45q11c REJECT

From:xn--vermgensberatung-pwb   REJECT

From:xn--vermgensberater-ctbREJECT

From:xn--p1acf  REJECT

From:xn--vhquv  REJECT

From:xn--xhq521bREJECT

From:xn--1qqw23aREJECT

From:xn--kput3i REJECT

From:xn--4gbrim REJECT

From:xn--czr694bREJECT

From:xn--80adxhks   REJECT

From:xn--ses554gREJECT

From:xn--czru2d REJECT

From:xn--rhqv96gREJECT

From:xn--nqv7f  REJECT

From:xn--i1b6b1a6a2eREJECT

From:xn--nqv7fs00emaREJECT

From:xn--c1avg  REJECT

From:xn--d1acj3bREJECT

From:xn--mgbab2bd   REJECT

From:xn--6frz82gREJECT

From:xn--io0a7i REJECT

From:xn--55qx5d REJECT

From:xn--fiq64b REJECT

From:xn--3bst00mREJECT

From:xn--6qq986b3xl REJECT

From:xn--fiq228c5hs REJECT

From:xn--3ds443gREJECT

From:xn--55qw42gREJECT

From:xn--zfr164bREJECT

From:xn--q9jyb4cREJECT

From:xn--ngbc5azd   REJECT

From:xn--80asehdb   REJECT

From:xn--80aswg REJECT

From:xn--unup4y REJECT

From:ninja  REJECT

From:gripe  REJECT

From:loans  REJECT

From:luxury REJECT

From:market REJECT

From:marketing  REJECT

From:pink   REJECT

From:whoswhoREJECT

From:work   REJECT

From:cricketREJECT

From:xn--plai   REJECT

From:review REJECT

From:countryREJECT

From:kimREJECT

From:scienceREJECT

From:party  REJECT

From:gq REJECT

From:topREJECT

From:unoREJECT

From:winREJECT

From:download   REJECT

From:tk REJECT

From:pw REJECT

From:international  REJECT

From:slice.internationalOK

From:date   REJECT

From:gdnREJECT

From:proREJECT

From:mm.law.pro OK

From:npocpa.pro OK

From:bidREJECT

From:trade  REJECT

From:press  REJECT

From:faith  REJECT

From:racing REJECT

From:stream REJECT

From:diet   REJECT

From:tokyo  REJECT

From:accountant REJECT

From:webcam REJECT

From:help   REJECT

From:space  REJECT

From:menREJECT

 

 

 



Re: uceprotect issue

2016-11-03 Thread Matus UHLAR - fantomas

On Thu, 3 Nov 2016 15:34:04 +0100
MHielder wrote:


>  Zitat von Marco :
>
> UCE Protect has a very questionable reputation, foremost reason is
> that they do charge money for delisting entries.
>
A that old lie, that one has to pay to be removed again? Really?


On 03.11.16 15:27, RW wrote:

No, not really. What he actually wrote was "they do charge money for
delisting entries" and that's clearly true:


It's for immediate delisting, not for delisting itself.
the delisting happens automatically, the fee is for doing it faster

(the fee could/should be charged to customer that caused the listing btw)


"PAY FOR IMMEDIATE REMOVAL:
 If you do not want to wait 7 days, or it is more cost effective for
 you, request for a paid “immediate removal” service can be made. The
 fee for this is per IP address. Payments are only accepted by Paypal
 or Moneybookers. Removal will be done manually as soon as your payment
 is confirmed. Click here if you want to request a paid removal.

 PLEASE NOTE THAT THIS IS AN OPTIONAL OFFER ONLY.
 YOU ARE LOSING YOUR RIGHT TO EXPRESSDELIST YOUR IP IF YOU ARE STUPID
 AND CLAIMING THIS WOULD BE BLACKMAIL, EXTORTION, SCAM OR SIMILAR
 BULLSHIT."


--
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.
We are but packets in the Internet of life (userfriendly.org)


Re: uceprotect issue

2016-11-03 Thread RW
On Thu, 3 Nov 2016 15:34:04 +0100
MHielder wrote:

> >  Zitat von Marco :
> >
> > UCE Protect has a very questionable reputation, foremost reason is
> > that they do charge money for delisting entries.
> >
> A that old lie, that one has to pay to be removed again? Really?

No, not really. What he actually wrote was "they do charge money for
delisting entries" and that's clearly true:

 "PAY FOR IMMEDIATE REMOVAL:
  If you do not want to wait 7 days, or it is more cost effective for
  you, request for a paid “immediate removal” service can be made. The
  fee for this is per IP address. Payments are only accepted by Paypal
  or Moneybookers. Removal will be done manually as soon as your payment
  is confirmed. Click here if you want to request a paid removal.

  PLEASE NOTE THAT THIS IS AN OPTIONAL OFFER ONLY.
  YOU ARE LOSING YOUR RIGHT TO EXPRESSDELIST YOUR IP IF YOU ARE STUPID
  AND CLAIMING THIS WOULD BE BLACKMAIL, EXTORTION, SCAM OR SIMILAR
  BULLSHIT."







Re: uceprotect issue

2016-11-03 Thread kruk

W dniu 2016-11-03 15:34, MHielder napisał(a):

UCE Protect has a very questionable reputation, foremost reason is
that they do charge money for delisting entries.

And no one knows who's behind them, since they do not publish this
kind of information. They want to stay anonymous, that's why there is
no easy way to concat them on their home page.

So you should really ask yourself: why do you trust them?
.

A that old lie, that one has to pay to be removed again? Really?


Yes. If you are listed, which can happen if your user - for example - 
makes a typo in an address and hits their honeypot, you can be forced to 
either pay or get complaints from your own users as well as people they 
usually mail for the next week.



Did it prevent people using UCEPROTECT within the last 15 years?


Hope so. Somehow I have never seen any respectable mail solution using 
UCEPROTECT lists. (I mean confirmed by a vendor, not just UCEPROTECT 
claims).



No, it didn't. The guys telling lies in the public just made fools out
of themselves.
The fact that every person interested in UCEPROTECT can go to the
website and read the removal policies should point out that delisting
will happen automatically for free after 7 days without spam.


Unless of course the super-pro crew of UCEPROTECT decides it wants to 
manualy mingle with the database.

https://groups.google.com/d/msg/news.admin.net-abuse.email/oB2ZxM3Yuw0/4vfbk-pyQ90J
Otherwise it's the very pro setup with low-wage students racing to 
delist so they get money.

https://groups.google.com/d/msg/news.admin.net-abuse.email/RSzPFUPYvDI/KQwlQboCM3oJ

But don't worry. I'm not going to get into another quarrel about your 
money-making scheme. Don't have the time for it.


Have a nice life.
MK


Fwd: TxRep very slow

2016-11-03 Thread Levente Birta


I repost this ... someone can help me out?

In the mean time TxRep worked well with sql backend but I prefer the file

Thanks
Levi


 Forwarded Message 
Subject: TxRep very slow
Date: Thu, 13 Oct 2016 15:39:50 +0300
From: Levente Birta 
To: users@spamassassin.apache.org

Hi

I have postfix with amavisd as content_filter and spamassassin 3.4.2
When I enable the TxRep plugin the mail stay very long in the SA check:


Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: mode is 384
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: created 
/var/spool/amavisd/.spamassassin/tx-reputation.lock.wsrv.benvenutionline.ro.24727
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 0 retries
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: link to /var/spool/amavisd/.spamassassin/tx-reputation.lock: 
link ok
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: auto-whitelist: 
tie-ing to DB file of type DB_File R/W in 
/var/spool/amavisd/.spamassassin/tx-reputation
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: auto-whitelist: 
db-based 55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated|ip=none 
scores 0/0
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun - 
tag TXREP_MSG_ID is now ready, value: 0.0
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun - 
tag TXREP_MSG_ID_COUNT is now ready, value: 0.0
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: check: tagrun - 
tag TXREP_MSG_ID_PRESCORE is now ready, value: -1.7
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: TxRep: 
reputation: none, count: 0, weight: 1.0, delta: 0.000, MSG_ID: 
55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: TxRep: active, 
55ff016ac8b77d76f3c2bd742dd31c10becb6023@sa_generated pre-score: -1.72, 
autolearn score: -1.719, IP: 81.196.63.17, address: x...@gmail.com 
signed by gmail.com

Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: mode is 384
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: created 
/var/spool/amavisd/.spamassassin/tx-reputation.lock.wsrv.benvenutionline.ro.24727
Oct 13 15:28:40 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 0 retries
Oct 13 15:28:41 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 1 retries
Oct 13 15:28:42 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 2 retries
Oct 13 15:28:43 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 3 retries
Oct 13 15:28:44 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 4 retries
Oct 13 15:28:45 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 5 retries
Oct 13 15:28:46 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 6 retries
Oct 13 15:28:47 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 7 retries
Oct 13 15:28:48 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 8 retries
Oct 13 15:28:50 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 9 retries
Oct 13 15:28:51 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 10 retries
Oct 13 15:28:52 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 11 retries
Oct 13 15:28:53 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 12 retries
Oct 13 15:28:54 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 13 retries
Oct 13 15:28:55 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 14 retries
Oct 13 15:28:56 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get lock on 
/var/spool/amavisd/.spamassassin/tx-reputation with 15 retries
Oct 13 15:28:57 wsrv amavis[24727]: (24727-01) SA dbg: locker: 
safe_lock: trying to get 

Re: uceprotect issue

2016-11-03 Thread MHielder
>  Zitat von Marco :
>
> UCE Protect has a very questionable reputation, foremost reason is
> that they do charge money for delisting entries.
>
> And no one knows who's behind them, since they do not publish this
> kind of information. They want to stay anonymous, that's why there is
> no easy way to concat them on their home page.
>
> So you should really ask yourself: why do you trust them?
> .
A that old lie, that one has to pay to be removed again? Really?
Did it prevent people using UCEPROTECT within the last 15 years?
No, it didn't. The guys telling lies in the public just made fools out
of themselves.
The fact that every person interested in UCEPROTECT can go to the
website and read the removal policies should point out that delisting
will happen automatically for free after 7 days without spam.



Re: Spamassassin giving obvious spammail a heavily negative score

2016-11-03 Thread Benny Pedersen

gladst...@posteo.de skrev den 2016-11-03 08:56:


X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=- required=4.65
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HTML_IMAGE_ONLY_12=1.629, HTML_MESSAGE=0.001, RCVD_IN_IADB_DK=-0.223,
RCVD_IN_IADB_LISTED=-0.38, RCVD_IN_IADB_OPTIN=-2.057,
RCVD_IN_IADB_RDNS=-0.167, RCVD_IN_IADB_SENDERID=-0.001,
RCVD_IN_IADB_SPF=-0.001, RCVD_IN_IADB_VOUCHED=-2.2,
RCVD_IN_MSPIKE_H2=-0.211, URIBL_BLACK=1.7]
autolearn=ham autolearn_force=no

As I mentioned before this was a very clear spammail. Unfortunately I
did not find too much information about "RCVD_IN_IADB_DK=-0.223" or
"RCVD_IN_IADB_VOUCHED=-2.2".

Any help or tips would be much appreciated. Thank you very much in 
advance

-gladston3


blacklist dkim signed domain (-d)
report to iadb
adjust iadb scores

i dont know what works best here


Spamassassin giving obvious spammail a heavily negative score

2016-11-03 Thread gladston3
Hello, I am using SpamAssassin version 3.4.1 with amavisd-new-2.10.1 and 
I did not change any of the scoring options of SpamAssassin.
Now I have the problem that some very obvious spammails are not only not 
getting detected but also are getting negative spamscores. Is this due 
to a configuration error on my side or is this a general problem. How 
can it be fixed?


Here is a sample header of one of those mails:

X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=- required=4.65
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HTML_IMAGE_ONLY_12=1.629, HTML_MESSAGE=0.001, RCVD_IN_IADB_DK=-0.223,
RCVD_IN_IADB_LISTED=-0.38, RCVD_IN_IADB_OPTIN=-2.057,
RCVD_IN_IADB_RDNS=-0.167, RCVD_IN_IADB_SENDERID=-0.001,
RCVD_IN_IADB_SPF=-0.001, RCVD_IN_IADB_VOUCHED=-2.2,
RCVD_IN_MSPIKE_H2=-0.211, URIBL_BLACK=1.7]
autolearn=ham autolearn_force=no

As I mentioned before this was a very clear spammail. Unfortunately I 
did not find too much information about "RCVD_IN_IADB_DK=-0.223" or 
"RCVD_IN_IADB_VOUCHED=-2.2".


Any help or tips would be much appreciated. Thank you very much in 
advance

-gladston3


Re: uceprotect issue

2016-11-03 Thread Boris Behrens
Even the CSA guys told us not to use UCEProtect. 

Mit freundlichen Grüßen
 - Boris Behrens

> Am 03.11.2016 um 00:12 schrieb Kevin Miller :
> 
> Isn’t it obvious?  It’s the NSA.  J
>  
> ...Kevin
> --
> Kevin Miller
> Network/email Administrator, CBJ MIS Dept.
> 155 South Seward Street
> Juneau, Alaska 99801
> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357
>  
> From: Joe Quinn [mailto:jqu...@pccc.com] 
> Sent: Wednesday, November 02, 2016 2:56 PM
> To: users@spamassassin.apache.org
> Subject: Re: uceprotect issue
>  
> On 11/2/2016 2:46 PM, Marc Stürmer wrote:
>  Zitat von Marco : 
> 
> 
> Sorry, I know this is not uceprotect list, but I don't know how to contact 
> uceprotect, their contact form is unavailable. 
> 
> It seems the problem starts on 30 october. Did you have noticed too something 
> about?
> 
> UCE Protect has a very questionable reputation, foremost reason is that they 
> do charge money for delisting entries. 
> 
> And no one knows who's behind them, since they do not publish this kind of 
> information. They want to stay anonymous, that's why there is no easy way to 
> concat them on their home page. 
> 
> So you should really ask yourself: why do you trust them?
> 
> I have to agree. Their inscrutability extends deep into the public-facing 
> parts of their infrastructure. Their MX doesn't have any registrant 
> information in their whois, and their DNS provider doesn't even have a 
> website. Their own domain uses a whois privacy service, and that service's 
> website is a single page for submitting email non-delivery reports to UCE 
> Protect. It's ridiculous.


smime.p7s
Description: S/MIME cryptographic signature