How can I distinguish my internal networks from the evil internet in a
spamassassin rule?
I want to give messages coming from "not mynetworks" but using my
domain in the From: header some additional points:
header MY_FROM From =~ /charite.de/i
describeMY_FROM Sender is from charite.d
On Mon, 27 Nov 2017 13:57:25 +0100
Ralf Hildebrandt wrote:
> How can I distinguish my internal networks from the evil internet in a
> spamassassin rule?
>
> I want to give messages coming from "not mynetworks" but using my
> domain in the From: header some additional points:
>
> header MY_F
ALL_TRUSTED should fire if msg is only transported via trusted hosts, so
you can do && !ALL_TRUSTED
But would it not be better to not accept such messages in first place
and reject them on your border mta?
Am 27.11.2017 um 13:57 schrieb Ralf Hildebrandt:
> How can I distinguish my internal network
* Tobi :
> ALL_TRUSTED should fire if msg is only transported via trusted hosts, so
> you can do && !ALL_TRUSTED
> But would it not be better to not accept such messages in first place
> and reject them on your border mta?
This is my border MTA.
--
Ralf Hildebrandt Charite Univ
On Mon, 27 Nov 2017 14:32:11 +0100
Tobi wrote:
> But would it not be better to not accept such messages in first place
> and reject them on your border mta?
There are legitimate reasons to receive them, e.g. mailing lists.
Ralf Hildebrandt skrev den 2017-11-27 13:57:
How can I distinguish my internal networks from the evil internet in a
spamassassin rule?
I want to give messages coming from "not mynetworks" but using my
domain in the From: header some additional points:
header MY_FROM From =~ /charite.de/i
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
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 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/
On Mon, 27 Nov 2017, Colony.three wrote:
I have fo
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
On Mon, 27 Nov 2017, Colony.three wrote:
I suspect you need an entry in /etc/tmpfiles.d so that directory gets
created at boot time.
Indeed there is no tmpfiles in the spamassassin package. (I've never heard of
this in 22 years) How can this be, in the 21st Century? As I'd suspected,
every
tmpfiles.d became a thing when /run became a temporary filesystem, so
it is relatively new. And most of the time packages install the
necessary files in /usr/lib/tmpfiles.d, so admins may have never run up
against this issue since it became a thing.
As John says, you can file a bug report with R
Yes spamass-milter-postfix(root) is running fine, again you underestimate me
Harald.
And now that I've determined a bug in the spamasassin.service file, that is
running fine too, with the addition of
RuntimeDirectory=spamassassin
RuntimeDirectoryMode=770
... which actually creates the -missing
Thanks for that. jessiebackports to the rescue.
Upgraded SA to 3.4.1 and it did clear up the error.
...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
> sha...@shanew.net kirjoitti 27.11.2017 kello 20.32:
>
> or what it's worth, there's no
> tmpfiles.d entry on my Ubuntu or Gentoo systems (Gentoo does its
> thing in the init script).
Debian (well, Raspbian for me) does have it. Apparently Ubuntu has removed it!
signature.asc
Description:
On Mon, 27 Nov 2017, sha...@shanew.net wrote:
I wonder if it's worth adding a note to the wiki, or even the
--socketpath section of the spamd man-page?
*That* would be something the SA team *could* do...
I'd be happy to do the commit if someone could provide some text.
On Mon, 27 Nov 2017,
On 27 Nov 2017, at 8:57 (-0500), Ralf Hildebrandt wrote:
* Tobi :
ALL_TRUSTED should fire if msg is only transported via trusted hosts,
so
you can do && !ALL_TRUSTED
But would it not be better to not accept such messages in first place
and reject them on your border mta?
This is my border MT
On 27 Nov 2017, at 11:58 (-0500), Colony.three wrote:
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
> 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?
>>
>> as i showed you
>>
>> /usr/sbin/sp
* Bill Cole :
> On 27 Nov 2017, at 8:57 (-0500), Ralf Hildebrandt wrote:
>
> > * Tobi :
> > > ALL_TRUSTED should fire if msg is only transported via trusted
> > > hosts, so
> > > you can do && !ALL_TRUSTED
> > > But would it not be better to not accept such messages in first place
> > > and reject
Ralf Hildebrandt skrev den 2017-11-28 00:31:
Putting my rules in place already pointed out several hosts not on our
network
sending mail as charite.de senders...
your rules, your problem :=)
in amavisd 0.01 it was designed to use xclient forwards in postfix so
amavisd know what clients it r
The ".date" TLD just started bombarding my inbox...
header FROM_RARE_TLDFrom:addr =~
/\.(?:wor(?:k|ld)|space|club|science|pub|red|blue|green|link|ninja|lol|xyz|faith|review|download|top|global|(?:web)?site|tech|party|pro|bid|trade|win|moda|news|online|biz|host|loan|study|click|stream|x
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:
> ExecStartPre=/usr/bin/mkdir /run/spamassassin
>
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:
>> ExecStartPre=/usr/bin/mkdir /run/spamassassin
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 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/messages
spamass-milter: group option, cho
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/messages
>> spamass-milter: group op
27 matches
Mail list logo
