Hello,
I would like to ask your help to find out how to best resolve the
following warnings. We are having a lot of such warnings; here is a sample:
...
Jun 29 06:07:33 mailgw1 postfix/smtpd[471365]: warning: hostname
chg.server1.ideacentral.com does not resolve to address 173.236.106.135
Jun
Hello,
Our postfix v3.8.3 mail gateway server (for incoming mail) filters
clients using postscreen as follows:
postscreen_dnsbl_sites =
zen.spamhaus.org*3
b.barracudacentral.org*2
bl.spameatingmonkey.net*2
bl.spamcop.net
dnsbl.sorb
On 10/1/2024 5:24 μ.μ., Matus UHLAR - fantomas via Postfix-users wrote:
If you use postscreen, remove reject_rbl_client from *_restrictions.
reject_rhsbl_client, reject_rhsbl_sender and reject_rhsbl_helo are
fine to stay since they use something postscreen does not.
Thanks Matus for your pr
On 10/1/2024 6:30 μ.μ., Bill Cole via Postfix-users wrote:
You should be more selective about your long lists of DNSBLs. They are
not all the same thing, and so are not all suitable for use at
postscreen time. It seems like you are ignoring the fact that the
underlying cause of this rejection i
Hello,
The two mail gateway servers (MX 10 mailgw1.noa.gr and ΜΧ 20
mailgw3.noa.gr) of our org (noa.gr), running Rocky 8 and Postfix 3.9.1,
are working fine (for a long time - thanks Wietse), but we are having
issues with fortimailcloud servers.
These servers seem to be trying to connect but
On 14/2/2025 3:09 μ.μ., Wietse Venema wrote:
This means that GLIBC (or whatever your equivalent is) has problems
not POSTFIX.
Thank you Wietse and Victor for the diagnosis.
As in RHEL / Rocky 8 we are at glibc v2.28 and it's really difficult to
switch to a new server (e.g. RHEL / Rocky 9 with
On 15/2/2025 7:28 μ.μ., Wietse Venema via Postfix-users wrote:
The evidence suggests that different versions of Rocky Linux have
failed an important real-world test.
That's true. It would be interesting if someone could cross-check this
behavior in any RHEL / AlmaLinux / Scientific Linux / Ora
On 15/2/2025 5:18 μ.μ., Viktor Dukhovni via Postfix-users wrote:
Have you tried adding "options edns0" to your resolv.conf? The "A"
RRset for this name exceeds 512 bytes, and so, absent edns0 can only be
returned via TCP, and some Linux versions had no TCP fallback support in
the libc resolver.
On 15/2/2025 11:40 π.μ., Viktor Dukhovni via Postfix-users wrote:
I don't recall seeing you testing with "getaddrinfo" (and perhaps also
"getnameinfo" to see whether it is slow PTR lookup that is the problem).
It may also help to perform tcpdumps to see how long the delay is
between that client c
On 15/2/2025 7:37 μ.μ., Viktor Dukhovni via Postfix-users wrote:
Yes, but what you really need is working TCP fallback, when the DNS
response is truncated due to exceeding the UDP packet size limit (even
happens with EDNS0, the default UDP buffer size could still be too small
for some queries).
On 14/2/2025 11:41 π.μ., Florian Piekert wrote:
...
could
reject_unknown_reverse_client_hostname
in the smtpd_recipient_restrictions be responsible, since there are
dns resolution issues for the hostname.
...
Thanks Florian for the reply.
Interestingly, dns reverse record query does work o
On 15/2/2025 1:45 π.μ., Wietse Venema via Postfix-users wrote:
It is possible to override these system library functions by providing
your own alternatives with LD_PRELOAD.
Thanks Wietse, it makes sense.
Would it be sufficient to LD_PRELOAD 2.34 libs for smptd or we should do
so for other exe
12 matches
Mail list logo
