I have a mail host that I want to receive mail from that dies not have a valid
rDNS (it recently moved and their ISP is comcast and it seems to be taking a
stupidly long time). Anyway, I first tried this:
check_sender_access pcre:$config_directory/sender_access.pcre
/@name.of.host/ OK
This
@lbutlr:
> Jun 24 07:39:38 mail postfix/smtpd[59684]: NOQUEUE: reject: RCPT from =
> unknown[xx.xx.xx.xx]: 550 5.7.25 Client host rejected: cannot find your =
> hostname, [xx.xx.xx.xx]; from= =
> to= proto=ESMTP helo=<*protectTheGuilty*>
Blocked by reject_unknown_client_hostname.
> smtpd_recipien
I've enabled the post-220 postscreen tests now on my server, and this is
making a significant difference -- most spam from random garbage domains
is never returning anymore after the initial soft rejection.
However, a handful of spam messages are still getting through. It seems
some spam-sending
On 25/06/19 5:12 AM, Rich Wales wrote:
However, a handful of spam messages are still getting through. It seems
some spam-sending engines are getting smarter and are retrying almost
immediately after an initial rejection -- before Spamhaus has had a
chance to list them -- and since they already g
Hi,
we're publishing lookup tables through our control git repo but hashing all
tables before commiting them to git is cumbersome. What do you recommend?
several postfix servers are getting same lookup table from central
repository.
we're using it this ways:
smtpd_sender_restrictions = check_se
Rich Wales:
> Is there -- or should there be -- a configuration parameter to tell the
> postscreen server to reject new(ish) clients for a specified minimum
> period of time before stepping out of the way and allowing them to pass?
> At the moment, it seems to me that requiring a minimum of 5 minu
On 24 Jun 2019, at 08:56, Wietse Venema wrote:
> elete reject_unknown_client_hostname, or add
>
>check_client_access inline:{1.2.3.4:ok}
Thank you.
--
Belief is one of the most powerful organic forces in the multiverse. It
may not be able to move mountains, exactly. But it can create some
On 24 Jun 2019, at 18:51, @lbutlr wrote:
> On 24 Jun 2019, at 08:56, Wietse Venema wrote:
>> elete reject_unknown_client_hostname, or add
>>
>> check_client_access inline:{1.2.3.4:ok}
>
> Thank you.
A note that I just noticed while making sure all was working (it was with the
issue I posted
