> Note that after the above you're allowing TLS 1.0 by default, where you
> insisted on TLS 1.2 or higher before. Postfix parsing of the legacy
> protocol negations has not changed. But you should be using the
> preferred min/max forms.
I know you're saying nothing changed, but I'm telling yo
> Perhaps Postfix does not "listen" on the IPv6 address? You can use nc or lsof
> to find out.
>
See above where I said "worked fine before the update". "Worked fine" includes
external validation, i.e. direct email delivery and ipv6 test websites such as
internet.nl
For the records, I *th
Following a Debian Bookworm update I am now seeing connectivity issues that
were not present before (everything was working perfectly before)
Postfix on the instance starts up fine, i.e. indicating no configuration errors.
The error is:
$ openssl s_client -connect [IPV6_ADDRESS_REDACTED]:25 -sta
> $ postqueue; echo $?
> postqueue: fatal: usage: postqueue -f | postqueue -i queueid | postqueue -j |
> postqueue -p | postqueue -s site
> 69
>
> With an empty mail queue:
>
> $ postqueue -p; echo $?
> Mail queue is empty
> 0
>
> $ postqueue -j; echo $?
> 0
>
> $ postqueue -f; echo $?
> 0
> They should instead read output from "postqueue -j" which provides
> information in JSON format. JSON support was added in Postfix 3.1
> (i.e. in 2015).
>
What are the minimum permissions required for postqueue ?
postqueue run as an unprivileged user returns :
- no output
- 0 exit code
Bo
>
> Data collecting programs should use supported interfaces such as
> postqueue output. If the supported interfaces are not sufficient,
> people can ask for or contribute what's missing.
>
> Wietse
Thanks Wietse.
The only reason I was planning to use it is because, e.g. postfix-exporter for
In its default configuration, Postfix makes /var/spool/postfix/public/qmgr
world accessible whilst the parent directory /var/spool/postfix/public is not.
This means that metric gathering is not able to connect to
/var/spool/postfix/public/qmgr.
I'm guessing the wrong answer is to make the met
Why doesn't dovecot_destination_recipient_limit get a mention in the postconf
docs (https://www.postfix.org/postconf.5.html)
I discovered I needed it today because of an obscure error in my logs affecting
only certain mails.
Those mails worked again after dovecot_destination_recipient_limit=1
> I guess we are talking about your auth-user relay instance.
We are indeed. I am not touching the other instances.
>
> If that one does not get mail via smtp on port 25, or only gets mail from
> authenticated users via that port, you can move configuration to main.cf.
Indeed that is the
> in such case, it should also not be added into "smtp" service, unless Laura
> (OP) uses different instance for incoming mail (or has more services in
> master.cf)
>
Basically a derived version of
https://www.postfix.org/MULTI_INSTANCE_README.html
I have :
- Null instance
- Inbound instan
Sent with Proton Mail secure email.
On Wednesday, 7 August 2024 at 11:20, Viktor Dukhovni via Postfix-users
wrote:
> On Wed, Aug 07, 2024 at 09:29:35AM +0000, Laura Smith via Postfix-users wrote:
>
> > > You may want to check that with
> > >
> > >
> > 3/ Referenced it under
> > submissions inet n - y - - smtpd
> > submission inet n - y - - smtpd
> > smtp inet n - y - - smtpd
> >
> > using the same options setting for all three:
> > -o cleanup_service_name=myheadercleanup
>
>
> You may want to check that with
>
> postmulti -i postfix-my
I am running an instance of Postfix that is an authenticated relay.
Overall it is working great except user IPs are leaking through Received
headers.
I thought I configured it right, but obviously not.
Here's what I've done:
1/ Create header_checks file with the following:
/^Received:/ IGNORE
> My doubt is that since the outgoing email server identifies itself as
> host1.example.com in the EHLO, is there a requirement or even an
> expectation that postmas...@example.com will be able to receive email.
I think the reality is that we are in 2024, and the chances of a human reading
p
I too am interested in experiences with rspamd and LLMs, so if there is
anything people don't want to share on-list, please loop me in. :)
Thanks !
Laura
On Tuesday, 30 July 2024 at 18:51, Walt E via Postfix-users
wrote:
> Can you share your experience on LLM for rspamd? Any links/resources
>
> > I know you're desperately trying to finger point elsewhere but I'm
> > pretty sure you are barking up the wrong tree. Everything else
> > works, apart from postfix.
>
>
> At the risk of demonstrating my level of thick I have seen similar
> messages about "Temporary failure in name reso
> On Sun, Jul 28, 2024 at 09:45:45AM +0000, Laura Smith via Postfix-users wrote:
>
> > The reporting program is postfix/smtpd
> >
> > postconf output:
> >
> > smtp inet n - y - - smtpd
>
>
> It runs in a chroot jail, where likely /etc/resolv.c
> > But I cannot understand why. Running, e.g. "dig foo.example.com"
> > returns instantly with the IP address, no problems with resolution?
>
>
> Are you typing that command as root? Most Postfix daemons don't.
>
Yes, of course ! dig is a simple command that doesn't require root privilege
Note that my copy/paste messed up the formatting, of course my user= line is on
a seperate line:
hosts=foo.example.com
user=myuser
password=mypass
dbname=mydb
query=select foo from bar('%s')
___
Postfix-users mailing list -- postfix-users@postfix.org
To
I'm getting the following in my logs:
" warning: connect to pgsql server foo.example.com: could not translate host
name "foo.example.com" to address: Temporary failure in name resolution?"
But I cannot understand why. Running, e.g. "dig foo.example.com" returns
instantly with the IP address,
20 matches
Mail list logo
