> - http://www.postfix.org/POSTSCREEN_README.html
>
> with that config and postscreen properly configured you block far more
> than 90% of junk without risk false positives
>
> postscreen_dnsbl_threshold = 8
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> postscreen_dnsbl
> first: before you call me again a fascist just because i don't agree
> with your opinions backed by 10 years professional mailadmin better
> don't give half thought advises!
>
> Am 09.12.2017 um 03:50 schrieb Colony.three:
>
>> Also in /etc/postfix/main.cf a
> I'm trying to decide the best way to detect something like this.
>
> https://pastebin.com/hCX9MWNg
>
> Looking at the raw headers and body it's pretty easy to tell this is a
> spoof, but when it shows-up in an inbox, it looks pretty good.
>
> Something specific to Amazon (where this is purported
Am 05.12.2017 um 19:29 schrieb Colony.three:
>> Am 05.12.2017 um 19:13 schrieb Colony.three:
>>
>>> On 12/05/2017 01:17 AM, Colony.three wrote:
>>>
>>> |Looks like it's doing what it's supposed to, but just
>>> checking... Wha
Am 05.12.2017 um 19:13 schrieb Colony.three:
>> On 12/05/2017 01:17 AM, Colony.three wrote:
>>
>>> Looks like it's doing what it's supposed to, but just checking...
>>>
>>> What do you think it's supposed to be happening below? Those are
On 12/05/2017 01:17 AM, Colony.three wrote:
>> Looks like it's doing what it's supposed to, but just checking...
>>
>> What do you think it's supposed to be happening below? Those are just
>> normal hacking attempts from China to do SMTP authentication to
Looks like it's doing what it's supposed to, but just checking...
Dec 5 06:58:26 quantumn postfix/smtpd[51554]: lost connection after AUTH from
unknown[110.83.135.178]
Dec 5 06:58:26 quantumn postfix/smtpd[51554]: disconnect from
unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2
Dec 5 06:5
>> First, copy and paste lines from the log into a file called thing0.log where
>> thing is a mnemonic name for what you're trying to enable. In this example,
>> thing is smartd
>>
>> root# cd; mkdir selinux; cd selinux
>> root# cat > smartd0.log
>> type=AVC msg=audit(1425551687.181:491): avc: de
>> On 11/27/2017 10:34 PM, Colony.three wrote:
>>
>>>> ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin
>>>>
>>>> There's a root exploit for the "spamd" user in that last line. Assuming
>>>> you got the t
On 27 Nov 2017, at 22:45 (-0500), Colony.three wrote:
>> Is anyone using the unix:socket for spamaassassin's milter?
>> When I turned on SELinux, it will not let me change the group of the
>> spamass-milter socket. (/run/spamass-milter/postfix/sock)
>> /var/log/mess
Is anyone using the unix:socket for spamaassassin's milter?
When I turned on SELinux, it will not let me change the group of the
spamass-milter socket. (/run/spamass-milter/postfix/sock)
/var/log/messages
spamass-milter: group option, chown: Operation not permitted
G**gle's baffled how to set S
On 11/27/2017 11:53 AM, Colony.three wrote:
>> It simply would not create /run/spamassassin directory on boot. It is
>> supposed to create it automatically like clamd does, since /run is wiped
>> at each boot. To make it work I finally had to add:
>> ExecStar
> Am 27.11.2017 um 19:37 schrieb Colony.three:
>
>> Yes spamass-milter-postfix(root) is running fine, again you
>> underestimate me Harald.
>> So it is postfix==>milter==>spamassassin. But my actual question here
>> is how does that last connexion get made?
&
itor?
> Original Message
> Subject: Re: RHEL7: spamass-milter-postfix==>spamassassin
> Local Time: November 27, 2017 9:31 AM
> UTC Time: November 27, 2017 5:31 PM
> From: h.rei...@thelounge.net
> To: Colony.three
>
> Am 27.11.2017 um 18:28 schrieb Colon
I suspect you need an entry in /etc/tmpfiles.d so that directory gets
> created at boot time.
>
> Google tmpfiles.d or see this redhat blog page:
> https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-systemd-tmpfiles-on-rhel7/
Indeed there is no tmpfiles in the spamassassi
Anyone know how spamass-milter-postfix communicates with spamassassin?
There's a postfix socket, but no setting AFAICT for the milter to reach SA. I
gather that the mechanism may be through clamc, but I have no proof that this
is actually the case.
It seems that everyone is resigned to leaving
I have fought with this for days, and finally had to hotwire it. But I'd like
to understand what's going on.
RHEL7 with spamassassin 3.4.0 and spamass-milter-postfix 0.4.0.
/etc/sysconfig/spamassassin
SPAMDOPTIONS="--daemonize --create-prefs --max-children=5 --username=spamd
--groupname=spamd
17 matches
Mail list logo
