I uploaded a patch for postgresql on
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7218 a while ago - but I
haven't had time to clean it up into something that should be included into a
release.
It might serve as inspiration for someone else before I end up having time to
get to it, thoug
On Mon, 2019-12-09 at 11:41 -0800, John Hardin wrote:
> This sounds more like the "does that tuple already exist?" logic is
> failing, causing it to think it needs to create a new entry, which
> the unique key is (correctly) preventing.
>
> You don't lightly bypass unique keys. They are there for
On Mon, 9 Dec 2019, RW wrote:
On Mon, 09 Dec 2019 13:14:45 +
Martin Gregorie wrote:
The primary key for the public.txrep table must be unique, and
evidently you already had a row with the same primary key. It seems
likely that the combination [username, email, signedby and ip] will
very of
On Mon, 09 Dec 2019 13:14:45 +
Martin Gregorie wrote:
> The primary key for the public.txrep table must be unique, and
> evidently you already had a row with the same primary key. It seems
> likely that the combination [username, email, signedby and ip] will
> very often be duplicated, like ev
On Mon, 9 Dec 2019 10:05:47 +0100
hg user wrote:
> Yes, I'm still at 3.4.1... can't update now.
>
I wouldn't bother, an unparseable relay only really matters if it's on
the edge of the trusted or internal network - mainly the internal. If
SA can't parse your own MTA's header all kinds of things
Spin up a vagrant instance and test.
I recommend using the scan size to 1024. For I found anything less was
getting missed.
# Increase scanning size of FuzzyOCR to 1024
sed -i 's/#focr_max_height 800/focr_max_height 1024/'
/etc/spamassassin/FuzzyOcr.cf
sed -i 's/#focr_max_width 800/focr_max
The primary key for the public.txrep table must be unique, and evidently
you already had a row with the same primary key. It seems likely that
the combination [username, email, signedby and ip] will very often be
duplicated, like every time you get another email from that person.
Try this:
- redef
2019-12-09 12:07:53.477 UTC [16458] DETAIL: Key (username, email,
signedby, ip)=(u...@example.org, u...@example.com, example.com, none)
already exists.
2019-12-09 12:07:53.477 UTC [16458] STATEMENT: INSERT INTO txrep
(username,email,ip,count,totscore,signedby) VALUES ($1,$2,$3,$4,$5,$6)
20
On 09.12.19 15:56, KADAM, SIDDHESH wrote:
Is there any possibilities of blocking a specific word from an image
using SpamAssassin ?
I think FuzzyOCR plugin can do something similar - OCR scan the image and
blacklist on words.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.s
Hi Folks,
Is there any possibilities of blocking a specific word from an image
using SpamAssassin ?
Regards,
Siddhesh
On Mon, Dec 09, 2019 at 10:54:00AM +0100, Matus UHLAR - fantomas wrote:
>
> I'm afraid I can't provide clients' file.
>
> I can only repeat:
> - the mail is 20424329 bytes
> - the mail contains single uuencoded .rar file inline.
>
> -rw-rw-rw- 1 root root 14818832 Dec 9 10:50 'redacted.rar'
>
>On Thu, 5 Dec 2019 17:07:05 +0100
>Matus UHLAR - fantomas wrote:
>>seems some big mails were too long to scan, and SA even got killed.
>>
>>[2146809.213586] Out of memory: Kill process 3660 (spamassassin)
>>score 365 or sacrifice child [2146809.213613] Killed process 3660
>>(spamassassin) total-v
If it starts bothers you, simply patch the small change..
https://svn.apache.org/viewvc/spamassassin/branches/3.4/lib/Mail/SpamAssassin/Message/Metadata/Received.pm?r1=1686458&r2=1686457&pathrev=1686458&view=patch
On Mon, Dec 09, 2019 at 10:05:47AM +0100, hg user wrote:
> Yes, I'm still at 3.4
Yes, I'm still at 3.4.1... can't update now.
Thank you
Francesco
On Mon, Dec 9, 2019 at 9:55 AM Henrik K wrote:
>
> I guess you are using old SA version, it was fixed in 3.4.2
>
> # Received: from mail-backend..com (LHLO mail-backend..com)
> (10.2.2.20) by mail-backend..com wi
I guess you are using old SA version, it was fixed in 3.4.2
# Received: from mail-backend..com (LHLO mail-backend..com)
(10.2.2.20) by mail-backend..com with LMTP; Thu, 18 Jun 2015 16:50:56 -0700
(PDT)
if (/^(\S+) \(LHLO (\S*)\) \((${IP_ADDRESS})\) by (\S+) with LMTP/) {
Here the line, redacted:
Dec 9 09:30:36.700 [10600] dbg: received-header: unparseable: from
host4.domain.it (LHLO host4.domain.it) (1.1.1.1) by host3.domain.it with
LMTP; Tue, 3 Dec 2019 11:55:44 +0100 (CET)
Thank you
Francesco
On Mon, Dec 9, 2019 at 9:22 AM Henrik K wrote:
> On Mon, Dec 09, 2
On Mon, Dec 09, 2019 at 09:10:25AM +0100, hg user wrote:
> Investigating why a message scored X when arrived and Y now (recovered from
> user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on all
> messages
> recovered from user inbox.
> In almost all cases this is not a problem, excep
Investigating why a message scored X when arrived and Y now (recovered from
user inbox), I realized that UNPARSEABLE_RELAY_COUNT rule fires on all
messages recovered from user inbox.
In almost all cases this is not a problem, except for XPRIO_SHORT_SUBJ: it
fired on X and didn't fire on Y due to UN
18 matches
Mail list logo
