Ah, OK. I wondered as PMG already uses one file with key + cert/fullchain combined (/etc/pmg/pmg-tls.pem), which looks perfectly fitted for the smtpd_tls_chain_files parameter.
Yes, both RSA and ECDSA. No special considerations though. I just noticed that Let's Encrypt has changed the default...
Since Postfix 3.4 (packed with Buster) the preferred way to specify TLS keys and certs seems to be smtpd_tls_chain_files, but PMG still uses the legacy smtpd_tls_cert_file and smtpd_tls_key_file parameters.
Is there a specific reason for this or is it safe to use the new parameter?
I had the same problem with my previous provider and solved it by
1) relaying outgoing mail through the ISPs mail servers and
2) using an e-mail store/forward service for incoming mail. I used Dynu, but there are others too, like No-IP, but those are bit more expensive.
Hi,
For diagnostic purposes I would like to have SpamAssassin (SA) insert a header:
add_header all RelaysUntrusted _RELAYSUNTRUSTED_
I've tried to insert it by adding the line to the config file /etc/mail/spamassassin/local.cf (via the template, I verified and the line is there).
After some...
Thanks all for this post, took me a while to solve this one, especially as the Debian 10 Buster containers I upgraded past months didn't have this problem. It first occurred when building a Debian 11 Bullseye from scratch.
Small improvement:
Because ListenStream can be defined multiple times in...
Aha, clear! Thanks for the quick clarification.
As I understand this will be the same for all future (upgraded and new) Debian 11 and other containers with new systemd version. Might be an idea to make a note in the upgrade guides for PVE and PMG.
Running PMG as LXC container on Proxmox Virtual Environment. Just upgraded it from 6.4 to 7.0.
When troubleshooting slow SSH logins I found the solution is to enable nesting (https://forum.proxmox.com/threads/delay-to-log-in-ssh-session-after-upgrade-from-6-x-to-7-x.92755/), and it worked, SSH...
Is this intended? I stumbled upon this nesting needing to be enabled to fix slow SSH logins (https://forum.proxmox.com/threads/delay-to-log-in-ssh-session-after-upgrade-from-6-x-to-7-x.92755/), but according to Oguz it's considered less secure to enable it on a container...
Nope. Changed IP via PVE, rebooted ct, ran `pmgconfig sync` and fetchmail config still has the old IP. Only "touching" a setting in a fetchmail entry (change, OK, change back, OK) seems to update the fetchmail config.
Btw, also tried changing IP via PMG interface, but that doesn't work. PVE...
Aaah, you're right, it is PMG's address indeed.
Sorry for the confusion.
Btw, there's definitively a slash, exactly like I posted above. I haven't customized it's template, so this is from the stock template in /var/lib/pmg:
smtphost [% ipconfig.int_ip %]/[% pmg.mail.ext_port %]
Hmmm, well...
After I changed the IP address of the internal mail server behind PMG, I updated the IP address of the Default Relay host (Configuration -> Mail Proxy -> Relaying -> Default Relay) in PMG accordingly. I tested sending a mail from outside and PMG correctly passed it through to the mail server.
I...
After I changed the IP address of the Default Relay host (Configuration -> Mail Proxy -> Relaying -> Default Relay) I noticed fetchmail didn't work. It still had the old relay-host IP address in it's config, apparently it wasn't re-generated after changing the Default Relay. Changing a setting...
Almost all mails have the status "accepted/delivered" (in Tracking Center), but mail sometimes gets status "accepted/accepted". I can't figure out the difference between those statuses. The latter one isn't included in the help...
I stumbled upon this too. Managed to remove the last header using Postfix option to filter headers using header_check:
1) Copied main.cf template from /var/lib/pmg/templates/ to /etc/pmg/templates/ and added:
#
# Control content of headers with Postfix built-in content inspection.
# For pcre...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.