Ok, thanks Bill.
I have postscreen enabled.
master.cf
smtp inet n - n - 1 postscreen
However, I had the postscreen_access_list setting set to ignore ….. so learning
all the time :-)
Now to look at pf. Thanks for the excellent tips there.
Robert
> On 5 Mar 2016, at 00:42, Bill Cole
> <postfixlists-070...@billmail.scconsult.com> wrote:
>
> On 4 Mar 2016, at 9:47, Robert Chalmers wrote:
>
>> thanks, that seems to work - how to make it permanent next …
>>
>> but, it should be working in postfix in any case shouldn’t it?
>>
>> Wep, weekend coming up.
>> Robert
>>
>>> On 4 Mar 2016, at 13:48, L.P.H. van Belle <be...@bazuin.nl> wrote:
>>>
>>> Very simple, route it to localhost.
>>>
>>> Like :
>>> route add -host 174.46.142.137 127.0.0.1
>
> That's really a sloppy fix. It works (until your next reboot) but routing
> packets to the loopback interface isn't scalable and ignores other problems
> that you clearly have:
>
> 1. You have a lot of postscreen settings but don't seem to actually have
> postscreen enabled, although it may be that you just didn't show the
> postscreen log lines. If you do have postscreen actually working, you can use
> the postscreen_access_list setting that you already have to blacklist that IP
> in the cidr map you seem to intend to be using.
>
> 2. In reference to this:
>> Mac. OSX 10.11
>> Postfix.
>>
>> I’ve even tried setting it in the firewall - but I’m missing something,
>> because there it
>> is again...
>>
>> I have the domain IP in a blacklist on both the pf.conf firewall
>
> I offer my condolences. Part of why I still run some things (including my
> personal Postfix instance) on older MacOS is that the newer and objectively
> better pf firewall has persistently confused me and I have all these little
> tools for ipfw that work around even the Apple-custom breakages in it.
> However, I do have *some* familiarity with pf so I can try to help.
>
> If you THINK you have the IP blocked by a rule in pf.conf yet clearly do not,
> that's a serious problem. Either pf is turned off or there's a rule ordering
> problem or something more arcane, but in any case pf isn't doing what you
> think it should be doing, and that's never a good thing in a firewall. The
> first thing to check is whether you actually have an active pf rule or rules
> related to that IP, which you might not. Easy enough to check with the
> command:
>
> pfctl -v -s rules
>
> That will list your rules with some stats, and near the end of the list
> should be something like these:
>
> block return in log quick inet proto tcp from 174.46.142.137 to any
> port = 25
> [ Evaluations: 15858 Packets: 0 Bytes: 0 States: 0 ]
> [ Inserted: uid 0 pid 77467 ]
> block return in log quick inet proto tcp from 174.46.142.137 to any
> port = 465
> [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
> [ Inserted: uid 0 pid 77467 ]
> block return in log quick inet proto tcp from 174.46.142.137 to any
> port = 587
> [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
> [ Inserted: uid 0 pid 77467 ]
>
> Which is the three active rules that would be generated by having this at the
> end of /etc/pf.conf when it was last reloaded:
>
> block return in log quick proto tcp from 174.46.142.137 to any port
> {25,465,587}
>
> Your rule may differ in small ways, yet be entirely reasonable. If you have a
> rule in pf.conf that doesn't seem to have resulted in one or more in the
> active listing, maybe you just forgot to reload:
>
> pfctl -f /etc/pf.conf
>
> Or if the rule shows in the active list but isn't working, maybe this will
> help:
>
> pfctl -e
>
Robert Chalmers
rob...@chalmers.com <mailto:rob...@chalmers.com>.au Quantum Radio:
http://tinyurl.com/lwwddov
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11.
XCode 7.2.1
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB.
Lower Bay
