The Fedora crypto policies apply to both servers and clients. Your
client doing the tests is almost certainly using the default SECLEVEL=2,
which disables TLSv1 and TLSv1.1. If you configure the client to also
allow these protocols, the test will work as expected. The problem is
not on the Post
i updated a postfix server,
postconf mail_version
mail_version = 3.8.1
on
lsb_release -rd
Description:Fedora release 38 (Thirty Eight)
Release:38
with
openssl version
OpenSSL 3.0.9 30 May 2023
I don't even know whether RedHat exposes any mechanisms for applications> to opt-out
of crypto policy and use only application-driven OpenSSL> configuration. This is
should perhaps be looked into in the Postfix 3.9> timeframe.
from my notes dealing with new Fedora crypto-policies on a number o
I changed the preferred chain here, and for all my domains (thx o/ !).
it certainly didn't hurt.
Presumably you then also *force* renewed the certificate chain.
yes
After the dns cleanup, switching BACK the preferred chain didn't
reinit the issue.
Did you *force* renewal at that point?
a
Also look into other possibilities, the DST Root issue is a bit of a
longshot. If you can get an account on Outlook.com, send mail and see
if it bounces with usable diagnostics in the bounce.
i changed the preferred chain here, and for all my domains (thx o/ !). it
certainly didn't hurt.
but
Original Message
From: Viktor Dukhovni via Postfix-users [mailto:postfix-users@postfix.org]
Sent: Tuesday, May 2, 2023 at 11:32 AM EDT
To: postfix-users@postfix.org
Subject: [pfx] Re: inbound failures only from outbound.protection.outlook.com.
Cert issue in this log?
On Tue,
What are some domains your server accepts mail for? Do you perhaps
publish DANE TLSA records and have botched certificate rotation?
See if dropping the DST cross cert from your certificate chain will
help. That root CA has long ago expired.
nothing in that cert chain reports a past date.
wha
a server that i don't have shell access to atm has, today, started seeing
undelivered mail from only one domain -- *outbound.protection.outlook.com.
apparently, everything else inbound is flowing. and, i'm told, inbound from
outlook.com was working yesterday.
all i've got so far is this log sn
For sending, it uses (like pretty much any network application) whatever the
TCP stack in your OS chooses.
this may be useful
https://www.postfix.org/postconf.5.html#smtp_bind_address
"An optional numerical network address that the Postfix SMTP client should bind to
when making an IPv4 conn
This was fixed almost 2 years ago in postfix-3.3.19, postfix-3.4.22,
postfix-3.5.12, postfix-3.6.3.
thx.
dropped from Fedora v3.0.8 pkgs:
https://src.fedoraproject.org/rpms/postfix/blob/rawhide/f/postfix.spec#_807
___
Postfix-users mailing list -
fedora 38/rhel pkg builds carry a few patches
i'm trying to figure out what still needs to be carried
one was reported @ distro
Bug 1977732 - [Regression] postfix "cleanup" crashes when processing messages
containing a "whitespace-only" fullname
https://bugzilla.redhat.com/sho
fyi
if SpamAssassin's in use in your Postfix message flow, then its TextCat plugin,
https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Plugin_TextCat.html
does a decent job of detecting many langs. good enough for scoring but NOT for
outright policy reject, here.
__
what is the practical difference between using inet or UNIX domain
socket in /etc/opendkim.conf ?
@ http://www.opendkim.org/staging/opendkim-README
see section "SOCKET SELECTION"
What do I need to put into /etc/postfix/main.cf instead of inet:localhost ?
smtpd_milters = inet:localhost:889
That's a surprise - thanks. I've just checked and seen that opendkim and
opendmarc set up init-style services. I'll do a systemd service for this
milter, but I'd be interested to hear if there's any policy or other advice
about whether we should be using master.cf or a service.
ultimately up
Thanks. As of a few minutes ago there's a dkimpy 1.1.1, although there aren't
any changes that will affect you one way or the other if you're using it for
dkimpy-milter.
thx,
Name: dkimpy
Version: 1.1.1
Name: dkimpy-milter
Version: 1.2.3
the 'hardest' part is
The problem with dkimpy/dkimpy-milter, is that they don't exist in enterprise
distros (Alma, Rocky, Oracle) via EPEL.
FWIW, it's a trivial install with python/pip, and plays nicely in a venv.
works a charm here.
rpm spec's also straightforward.
here's one for Fedora,
https://src.fe
* Scott Kitterman via Postfix-users :
That would be great. I started dkimpy-milter for two reasons: I wanted to
experiment with the new DKIM crypto types that lead to RFC 8463 and there
didn't seem to be much activity with opendkim maintenance (this is, of course,
ironic given how well I did wit
No solution so far, I think there are 2-3 open bug reports on
github, but since the project is very dead, nobody has bothered to
fix the problem.
So what's the option for a more upto date version of DKIM milter for debian?
fwiw, for inbound DKIM, DMARC, ARC, etc, this
https://github.com/fas
18 matches
Mail list logo
