[pfx] Postscreen & HAProxy Protocol v2
Hi All, When using `postscreen_upstream_proxy_protocol = haproxy` is there anything "special" that needs to be specified to ensure the use of v2 of the haproxy protocol, or does postfix automatically detect which version of the haproxy protocol is in use? The doco isn't clear (to me, anyway). :-) Thanks in advance Cheers Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SELinux/SMTP Relay Handshake Failure
On 04/12/2023 19:44, Carsten Strotmann (sys4) via Postfix-users wrote: Hi Dulux-Oz, On 4 Dec 2023, at 9:20, duluxoz via Postfix-users wrote: Hi All, This issue is definitely SELinux related, because it only crops up when SELinux is enabled. I'm getting a `TLS handshake failed for service=smtp peer=[104.199.96.85]:587` error when attempting to rely via mailjet (that's who's IP that is) and also brevo/sendinblue. Any one have any ideas (apart from disabling SELinux - that is *NOT* an option) :-) disabling SElinux is never a good option :) On which Linux-Distro is this issue happening? Can you send the SELinux messages from the Linux Audit Subsystem (where SELinux send information about policy violations) from around the time the issue is reported in the mail log? This would be the command: ausearch -m avc -i --start --end (see "man ausearch" for the syntax of the start- and end-times -- there might be a large number of log entries -- try to limit the time to a few minutes before/after the error occurred) I suspect some files have the wrong SElinux security context label, but which files that are will be told by the audit log messages. Greetings Carsten ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org Hi Carsten Its Rocky v9.1 That's the funny thing: I've done an `audit2allow -a` and all of the 'errors' are accounted for by update policys, and the suggested `ausearch` produces nothing - zip, narda, nil :-( ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] SELinux/SMTP Relay Handshake Failure
Hi All, This issue is definitely SELinux related, because it only crops up when SELinux is enabled. I'm getting a `TLS handshake failed for service=smtp peer=[104.199.96.85]:587` error when attempting to rely via mailjet (that's who's IP that is) and also brevo/sendinblue. Any one have any ideas (apart from disabling SELinux - that is *NOT* an option) :-) @Vickto: you mentioned in a previous reply (which I can't find) about someone else having an SELinux issue around postfix's smtp(8)/relay process (I think) when I asked a related Q before. Could you please point me back towards that other user's posts so I can see if that solution helps me - thanks Thanks all Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] non_smtpd_milters = $smtpd_milters
Thanks Ralf, OK, so what was leading to my Q is the Postfix Architect document seems to indicate (via the first diagram) that the `smtp_milters` is triggered from the `smtpd(8)` process which then feeds into the `cleanup(8)` process, which is what triggers the `non_smtp_milters` - hence me wondering if a piece of smtp mail went through both milter lists. Cheers On 01/12/2023 20:34, Ralf Hildebrandt via Postfix-users wrote: * duluxoz via Postfix-users: A quick question (just to clarify things in my own mind): If `non_smtpd_milters = $smtpd_milters`, does this mean that an email received on port 25 passes through the milters twice; once for the `smtpd_milters` (from the `smtpd(8)` process) and again for the `non_smtpd_milters` (from the `cleanup(8)` process)? No. non_smtpd_milters are for new mail that does not arrive via the Postfix smtpd server. This includes local submission via the sendmail command line, new mail that arrives via the Postfix qmqpd server, and old mail that is re-injected into the queue with "postsuper -r". smtpd_milters are for new mail that arrives via the Postfix smtpd(8) server. -- Peregrine IT Signature *Matthew J BLACK* M.Inf.Tech.(Data Comms) MBA B.Sc. MACS (Snr), CP, IP3P When you want it done /right/ ‒ the first time! Phone: +61 4 0411 0089 Email: matt...@peregrineit.net <mailto:matt...@peregrineit.net> Web:www.peregrineit.net <http://www.peregrineit.net> View Matthew J BLACK's profile on LinkedIn <http://au.linkedin.com/in/mjblack> This Email is intended only for the addressee. Its use is limited to that intended by the author at the time and it is not to be distributed without the author’s consent. You must not use or disclose the contents of this Email, or add the sender’s Email address to any database, list or mailing list unless you are expressly authorised to do so. Unless otherwise stated, Peregrine I.T. Pty Ltd accepts no liability for the contents of this Email except where subsequently confirmed in writing. The opinions expressed in this Email are those of the author and do not necessarily represent the views of Peregrine I.T. Pty Ltd. This Email is confidential and may be subject to a claim of legal privilege. If you have received this Email in error, please notify the author and delete this message immediately. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] non_smtpd_milters = $smtpd_milters
A quick question (just to clarify things in my own mind): If `non_smtpd_milters = $smtpd_milters`, does this mean that an email received on port 25 passes through the milters twice; once for the `smtpd_milters` (from the `smtpd(8)` process) and again for the `non_smtpd_milters` (from the `cleanup(8)` process)? Cheers Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Turn Off Verify Service?
On 29/11/2023 20:14, Matus UHLAR - fantomas via Postfix-users wrote: On Wed, Nov 29, 2023 at 03:00:24PM +1100, duluxoz via Postfix-users wrote: I was reading an on-line guide about hardening Postfix and came across a line that said that the Verify service could/should be turned off I the master.cf file. Is this actually good advice, or is there some sort of "gotcha" hiding in the background that'll bite us in the @rse? On 29/11/2023 15:38, Viktor Dukhovni via Postfix-users wrote: The advice is largely misguided, but mostly harmless, if you don't use sender or recipient verification. Leaving the service enabled does not materially affect the Postfix "attack surface", but it off when unused is fine too. On 29.11.23 16:28, duluxoz via Postfix-users wrote: For what it's worth, it is my opinion that misguided information, harmless or otherwise, is worse than useless, because it encourages bad habits which then enter the zeitgeist and perpetuate (see mandatory rotating passwords every 90 days) :-) On 29/11/2023 19:45, Matus UHLAR - fantomas via Postfix-users wrote: I completely agree, perhaps if you sent us a link we could comment. There is of course security practice of turning off everything you don't use, but in case of verify, it is only used when you configure it, so commenting it in master.cf means disabling it, not just turning it off. On 29.11.23 19:49, duluxoz via Postfix-users wrote: As requested :-) https://linux-audit.com/postfix-hardening-guide-for-security-and-privacy/ This talks aboud "VRFY" SMTP command, not about "verify service" which is very different issue. http://www.postfix.org/postconf.5.html#disable_vrfy_command Disable the SMTP VRFY command. This stops some techniques used to harvest email addresses. the harvesting is rarely done this way nowadays. It also won't stop harvesting by issuing "rcpt to:" smtp command. So, it's useless but harmless as well. My bad - thanks for the clarification (looks like I need to pay more attention to what I'm reading) :-) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Turn Off Verify Service?
On 29/11/2023 19:45, Matus UHLAR - fantomas via Postfix-users wrote: On Wed, Nov 29, 2023 at 03:00:24PM +1100, duluxoz via Postfix-users wrote: I was reading an on-line guide about hardening Postfix and came across a line that said that the Verify service could/should be turned off I the master.cf file. Is this actually good advice, or is there some sort of "gotcha" hiding in the background that'll bite us in the @rse? On 29/11/2023 15:38, Viktor Dukhovni via Postfix-users wrote: The advice is largely misguided, but mostly harmless, if you don't use sender or recipient verification. Leaving the service enabled does not materially affect the Postfix "attack surface", but it off when unused is fine too. On 29.11.23 16:28, duluxoz via Postfix-users wrote: For what it's worth, it is my opinion that misguided information, harmless or otherwise, is worse than useless, because it encourages bad habits which then enter the zeitgeist and perpetuate (see mandatory rotating passwords every 90 days) :-) I completely agree, perhaps if you sent us a link we could comment. There is of course security practice of turning off everything you don't use, but in case of verify, it is only used when you configure it, so commenting it in master.cf means disabling it, not just turning it off. As requested :-) https://linux-audit.com/postfix-hardening-guide-for-security-and-privacy/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Turn Off Verify Service?
On 29/11/2023 15:38, Viktor Dukhovni via Postfix-users wrote: On Wed, Nov 29, 2023 at 03:00:24PM +1100, duluxoz via Postfix-users wrote: I was reading an on-line guide about hardening Postfix and came across a line that said that the Verify service could/should be turned off I the master.cf file. Is this actually good advice, or is there some sort of "gotcha" hiding in the background that'll bite us in the @rse? The advice is largely misguided, but mostly harmless, if you don't use sender or recipient verification. Leaving the service enabled does not materially affect the Postfix "attack surface", but it off when unused is fine too. Thanks Viktor, For what it's worth, it is my opinion that misguided information, harmless or otherwise, is worse than useless, because it encourages bad habits which then enter the zeitgeist and perpetuate (see mandatory rotating passwords every 90 days) :-) Cheers ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Turn Off Verify Service?
Hey All, I was reading an on-line guide about hardening Postfix and came across a line that said that the Verify service could/should be turned off I the master.cf file. Is this actually good advice, or is there some sort of "gotcha" hiding in the background that'll bite us in the @rse? This is for a Mail Hub server, but could also be used on Null Client servers as well. Thanks in advance for any advice Cheers Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
Thanks Victor - so more t-shooting on our end, then - cool On 24/11/2023 04:16, Viktor Dukhovni via Postfix-users wrote: On Thu, Nov 23, 2023 at 07:48:33PM +1100, duluxoz via Postfix-users wrote: Hi All, This may be a stupid Q, but we're getting a `postfix/tlsproxy[89206]: TLS handshake failed for service=smtp peer=[104.199.96.85]:25` error in our logs when trying to relay via an SMTP Relay Service (both Mailjet and Brevo/SendInBlue). Could our issue be related to this LE issue? No, failure to complete the TLS handshake is not related to any issues with the certificates. That said, the handshake works for me: posttls-finger: Untrusted TLS connection established to 104.199.96.85[104.199.96.85]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 posttls-finger: > EHLO straasha.imrryr.org posttls-finger: < 250-smtpin.mailjet.com posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 15728640 posttls-finger: < 250-VRFY posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 posttls-finger: < 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250-SMTPUTF8 posttls-finger: < 250 CHUNKING posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye Unclear why your tlsproxy is having issues. Perhaps the same problem as Patrick was having with SELinux? Don't configure any client certificates on your end, or don't enable SELinux? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 2: Future Let's Encrypt CA choice randomisation.
Hi All, This may be a stupid Q, but we're getting a `postfix/tlsproxy[89206]: TLS handshake failed for service=smtp peer=[104.199.96.85]:25` error in our logs when trying to relay via an SMTP Relay Service (both Mailjet and Brevo/SendInBlue). Could our issue be related to this LE issue? On 19/11/2023 06:24, Viktor Dukhovni via Postfix-users wrote: On Sat, Nov 18, 2023 at 04:33:46PM +0900, Byung-Hee HWANG via Postfix-users wrote: or if you prefer: _25._tcp.mx1.org.example. IN CNAME _25._tlsa.org.example. _25._tcp.mx2.org.example. IN CNAME _25._tlsa.org.example. ... _25._tcp.mxN.org.example. IN CNAME _25._tlsa.org.example. ; _25._tlsa.org.example. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d ; R3 _25._tlsa.org.example. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 ; R4 _25._tlsa.org.example. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 ; E1 _25._tlsa.org.example. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 ; E2 Thank you for the clear summary. I did update all again. Good job, you're set until some future change a few years down the line. _25._tcp.yw-0919.doraji.xyz. IN CNAME rfc7671.doraji.xyz. _25._tcp.yw-1204.doraji.xyz. IN CNAME rfc7671.doraji.xyz. rfc7671.doraji.xyz. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d rfc7671.doraji.xyz. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 rfc7671.doraji.xyz. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 rfc7671.doraji.xyz. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 It may be prudent to mark your calendar to check the Let's Encrypt certificate page once or twice a year, and make appropriate changes if new intermediate issuer CAs are introduced, or extant ones retired. https://letsencrypt.org/certificates/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix Options Override Or Add When In Both mater.cfg & main.cfg
Hi All, Quick Q: Do the individual `-o` options in the `master.cfg` file *add to* or *override* the equivalent option in the `main.cfg` file? For eg: In the `master.cfg` file I've got a `-o smtpd_relay_restriction =` line with a couple of restrictions set on the `submission` service. I've got the same `smtpd_relay_restriction =` option set in the `main.cfg` with a different set of restrictions (with some overlap). When *submitting* mail is the list of restrictions the union of both sets (those listed in both files) or only the set listed in the `master.cfg` file? Cheers Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: No Permissions To TLS Certificates
(Sorry, can't remember if I should be top-posting or bottom-posting :-) ) The answer for both queries: * The root folder is 555 root:root * All other folders are 755 root:root * The certs themselves are 600 root:root (I think I mentioned this one in my original post - I think) Having raised this issue, it now raises another Q in my mind: could this be something to do with SELinux interfering somehow (I'm not really up to speed on SELinux, unfortunately)? Cheers On 12/10/2023 01:40, Wietse Venema via Postfix-users wrote: duluxoz via Postfix-users: Oct 11 17:33:05 mail.me.local email_postfix[2038]: find: '/etc/postfix/./certs/me.local.pem': Permission denied Oct 11 17:33:05 mail.me.local email_postfix[2039]: postfix/postlog: warning: not owned by root: /etc/postfix/./certs/me.local.pem What is the output from: ls -ld / /etc /etc/postfix /etc/postfix/certs /etc/postfix/certs/me.local.pem Oct 11 17:33:05 mail.me.local email_postfix[2038]: find: '/etc/postfix/./certs/me2.local.pem': Permission denied Oct 11 17:33:05 mail.me.local email_postfix[2040]: postfix/postlog: warning: not owned by root: /etc/postfix/./certs/me2.local.pem What is the output from: ls -ld / /etc/postfix /etc/postfix/certs /etc/postfix/certs/me2.local.pem Wietse ___ Postfix-users mailing list --postfix-users@postfix.org To unsubscribe send an email topostfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] No Permissions To TLS Certificates
Hi All,
Hoping someone can point me in the correct direction to solve this one
(ie why is postfix "not playing well" with our TLS Certs)
This is all internal (ie NOT on the Internet), so the below logs, etc,
have NOT been "edited" or obscured.
We're running two (internal) email domains: me.local and me2.local on
the one (Postfix v3.8.1) server (Rocky Linux v9.1). Dovecot is our MDA
and we're using MariaDB for our backend. Everything *seems* to be
working except for some TLS "stuff" (see below).
Each/Both email domains have an appropriate ECC Wildcard Certificate
from our internal CA (Step-CA, if it makes a difference), with the Key,
Hostname (ie "me.local" & "*.me.local"), the Intermediate CA & the Root
CA Certificates included, in that order. These Certificates also work on
our (internal) NginX Server for our internal websites - so that's all
good (as far as I can determine).
These Certificates (in .pem format) are placed in the
"/etc/postfix/certs/" folder. The folder and the certificates have
ownership of root:root and permissions of 0755/0600 respectively.
The sni_maps file (see next) has been hashed with "postmap -F
/etc/postfix/sni_maps".
~~~
me.local /etc/postfix/certs/me.local.pem
me2.local /etc/postfix/certs/me2.local.pem
~~~
We're getting the following warnings/errors on postfix start when we do
a "journalctl -u postfix" (which the postfix log file confirms):
~~~
Oct 11 17:33:05 mail.me.local systemd[1]: Starting Postfix Mail
Transport Agent...
Oct 11 17:33:05 mail.me.local email_postfix[2038]: find:
'/etc/postfix/./certs/me.local.pem': Permission denied
Oct 11 17:33:05 mail.me.local email_postfix[2039]: postfix/postlog:
warning: not owned by root: /etc/postfix/./certs/me.local.pem
Oct 11 17:33:05 mail.me.local postfix/postfix-script[2039]: warning: not
owned by root: /etc/postfix/./certs/me.local.pem
Oct 11 17:33:05 mail.me.local email_postfix[2038]: find:
'/etc/postfix/./certs/me2.local.pem': Permission denied
Oct 11 17:33:05 mail.me.local email_postfix[2040]: postfix/postlog:
warning: not owned by root: /etc/postfix/./certs/me2.local.pem
Oct 11 17:33:05 mail.me.local postfix/postfix-script[2040]: warning: not
owned by root: /etc/postfix/./certs/me2.local.pem
Oct 11 17:33:05 mail.me.local email_postfix[2044]: find:
'/etc/postfix/./certs/me.local.pem': Permission denied
Oct 11 17:33:05 mail.me.local email_postfix[2044]: find:
'/etc/postfix/./certs/me2.local.pem': Permission denied
Oct 11 17:33:05 mail.me.local email_postfix[2056]: postfix/postlog:
starting the Postfix mail system
Oct 11 17:33:05 mail.me.local postfix/postfix-script[2056]: starting the
Postfix mail system
Oct 11 17:33:05 mail.me.local postfix/master[2058]: daemon started --
version 3.8.1, configuration /etc/postfix
Oct 11 17:33:05 mail.me.local systemd[1]: Started Postfix Mail Transport
Agent.
~~~
Our "postconf -n" output is:
~~~
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
biff = no
command_directory = /usr/sbin
compatibility_level = 3.8
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_list = 192.168.1.0/24 192.168.2.0/24
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_destination_concurrency_limit = 20
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
fallback_transport =
header_size_limit = 4096000
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
local_recipient_maps = $virtual_mailbox_maps
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 104857600
meta_directory = /etc/postfix
milter_connect_macros = j {daemon_name} v {if_name} _
milter_default_action = accept
milter_protocol = 6
my_domain = me.local
my_external_ip =
my_hostname = mail.$my_domain
my_networks = 127.0.0.0/8 192.168.1.0/24 192.168.2.0/24
my_origin = $my_domain
my_relayhost =
mydestination = $myhostname localhost.$mydomain localhost
mydomain = $my_domain
myhostname = $my_hostname
mynetworks = $my_networks
myorigin = $my_origin
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
postscreen_access_list = permit_mynetworks
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = b.barracudacentral.org bl.spamcop.net
postscreen_dnsbl_whitelist_threshold = -2
postscreen_greet_action = enforce
postscreen_non_smtp_command_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
postscreen_upstream_proxy_protocol =
postscreen_upstream_proxy_timeout = 5s
proxy_interfaces = $my_external_ip
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix3-3.8.1/README_FILES
recipient_delimiter = +
relay_destination_concurrency_limit = 1
[pfx] Re: Looking For Advice/Guidance
Thanks Viktor On 10/09/2023 03:02, Viktor Dukhovni via Postfix-users wrote: On Sat, Sep 09, 2023 at 06:24:27PM +1000, duluxoz via Postfix-users wrote: ***My Questions*** In the mail.example.local's postfix main.cf file: 1. Should mydomin be set to example.local or one of the external facing domains? The value of this parameter is used as the default suffix for non-FQDN hostnames when "append_dot_mydomain = yes". Choose a setting that works for you. 2. Should myorigin be set to example.local or one of the external facing domains? The value of this parameter is used as the default domain part of bare username email addresses. Typically, mail from cron jobs, or users doing local submission via sendmail(1). Along with the domain names in $mydestination, email addresses whose domain parts are equal to this parmeter match "bare" user names in various address rewriting tables. Choose a setting that works for you. 3. Have I missed anything obvious to anyone? Test. Perhaps consider "soft_bounce = yes" as a *short-term* measure for the first few days of deployment, and watch the logs closely. Generally, best to avoid wildcard certificates, but you may have plausible reasons to want them. They reduce security and tend to create single points of failure when all the nodes in an HA setup field the same "wrong" wildcard cert. -- Peregrine IT Signature *Matthew J BLACK* M.Inf.Tech.(Data Comms) MBA B.Sc. MACS (Snr), CP, IP3P When you want it done /right/ ‒ the first time! Phone: +61 4 0411 0089 Email: matt...@peregrineit.net <mailto:matt...@peregrineit.net> Web:www.peregrineit.net <http://www.peregrineit.net> View Matthew J BLACK's profile on LinkedIn <http://au.linkedin.com/in/mjblack> This Email is intended only for the addressee. Its use is limited to that intended by the author at the time and it is not to be distributed without the author’s consent. You must not use or disclose the contents of this Email, or add the sender’s Email address to any database, list or mailing list unless you are expressly authorised to do so. Unless otherwise stated, Peregrine I.T. Pty Ltd accepts no liability for the contents of this Email except where subsequently confirmed in writing. The opinions expressed in this Email are those of the author and do not necessarily represent the views of Peregrine I.T. Pty Ltd. This Email is confidential and may be subject to a claim of legal privilege. If you have received this Email in error, please notify the author and delete this message immediately. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Looking For Advice/Guidance
Hi All, I'm looking for some advice / guidance / help / whatever in making sure that I'm setting up my postfix installation correctly. I've gone through various on-line tutorials and read just about all of the postfix doco, but I'm still unsure / confused about exactly how to set a couple of settings. I have a rather complex (network) setup which is what's throwing me "off". ***The Network*** Four domains: * example.local * example.net * example.com * example.org Lots of servers: * mail.example.local * sql.example.local (mariadb) * haproxy.example.local * dns.example.local (plus externally facing dns servers) * ca.example.local * www.example.local * others(.example.local) Notes: * I'm using a split-dns setup * example.net, .com, and .org are all Internet via their own dns server(s) * haproxy.example.local is a bastion host in the dmz and (almost) all traffic flows through it * haproxy.example.local proxies www.example.net, mail.example.net, etc, etc, etc * all servers apart from mail.example.local are null-client postfix boxes (for internal alerts, etc) * mail.example.local uses sql.example.local for virtual domains, mailboxes, etc * I run an interal pki (ca.example.net) and all servers have x.509 certificates * haproxy.example.local runs certbot to obtain Let's Encrypt wildcard certs for example.net, .com, and .org, and these three certs are also (securely) transferred automatically upon renewal to mail.example.local * mail.example.local also has a wildcard cert for example.local (from our internal pki) * I am using virtual domains, virtual mailboxes, etc * Mail from example.local does not go out to the Internet * Mail to example.local is not received from the Internet * Mail from example.net, .com, & .org does go out to the Internet * Mail to example.net, .com, & .org is received from the Internet * I've set up sni for each domain's wildcard cert ***My Questions*** In the mail.example.local's postfix main.cf file: 1. Should mydomin be set to example.local or one of the external facing domains? 2. Should myorigin be set to example.local or one of the external facing domains? 3. Have I missed anything obvious to anyone? Thanks in advance for the help Cheers Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Requesting A Sanity Check, Please, + A Couple Of Qs
Hi All, TL:DR: Could someone(s) please have a look-see at our config as a sanity check for us, and also answer the questions at the end of this post - thanks. So we're finally putting in an email stack and while I've read just about every tutorial I can find on the web - and read *all* of the Postfix documentation (yes, my brains *are* leaking out my ears :-) ) - we've got a somewhat complex environment and none of the online tutorials cover exactly how we're set up. Oh, our entire set-up is covered across multiple tutorials, but not one single tutorial covers everything, so we've had to do a bit of a "mix-and-match" to achieve what we want, and I'm a bit worried about (actually I'm scared sh!tless of) our domains ending up on Blacklists. So we're hoping that someone (or someones) would be kind enough to have a look-see at our (primarily Postfix) config as a "2nd set of eyes", a "sanity check", an/or a "wise old postfix admin" and let us know if we've "fire-trucked" things up in any way. Our Environment --- Note: All of the following is currently working without issue, both for the internal network and for the external Internet. - We have a single internal domain: example.local - We use the following private IP networks: - DMZ - 192.168.1.0/24 - Internal - 192.168.2.0/24 - We currently have the below servers on the indicated IP addresses (Note: these are the relevant hosts; there are more/others in the domain as well): - dns-external.example.local - 192.168.1.10 - dns-internal.example.local - 192.168.2.10 - freeipa.example.local - 192.168.2.11 - haproxy.example.local - 192.168.1.11 - mysql.example.local - 192.168.2.12 - www.example.local - 192.168.2.13 - There is a Gateway/NAT box on the network perimeter: - External IP - 1.2.3.4 (ie *not* the real IP address) - Internal IP - 192.168.1.1 - All of the internal hosts have a FreeIPA certificate assigned to them (ie we run our own internal Certificate Authority) - The internal FreeIPA certificates are being renewed automatically. - We are running a Split-Horizon DNS set-up. - We have the below four external-facing domains: - example.com - example.net - example.biz - example.org - We have a wildcard certificate from Let's Encrypt (LE) for each of the external domains - ie there are four certificates - haproxy.example.local is acting as a bastion host - (we're thinking of loading Fail2Ban on it, but haven't done so yet as the Gateway/NAT box is keeping things under control at the moment - but it's not really designed for that hence thinking about Fail2Ban). - Currently all inbound traffic (except for DNS queries to the external-facing DNS host (dns-external.example.local)) passes through haproxy.example.local before being forwarded to the relevant internal server. At the moment this is primarily web traffic (for our multiple websites). - dns-external.example.local has the correct zones set up for the external domains (including mx records) - haproxy.example.local is the termination point for all inbound (ie web) TLS traffic - ie this is the host where the LE certificates are located. - The LE certificates are being renewed automatically. Desired Outcome --- - A "mail-stack" server (mail.example.local - 192.168.2.14) with Postfix, Dovecot, ClamAV, OpenDKIM, OpenDMARC, and SpamAssassin (with Pyzor and Razor) installed - We are using Postfix version 3.7.4 - We are using Dovecot version 2.3.20 - All domains will be Virtual Mailbox Domains - All users will be Virtual Users - Mailboxes will be Maildir style mailboxes - The local email user account is vmail:vmail - MySQL (ie mysql.example.local) will be used as the primary data store/source (except for actual emails, of course) - The LE certificates are being periodically scp'd automatically from haproxy.example.local to mail.example.local (this is currently working) - A Null Client Postfix install on all other hosts for forwarding reports, web app emails, etc, to mail.example.local for further processing/forwarding/dovecot-delivery/etc. (This config can be provided if requested, but should not be required for this discussion.) - All internal inbound mail will be sent/forwarded to mail.example.local - By the above mentioned Null Client Postfix instances - By Dovecot for user emails - All mail for local delivery will be forwarded to Dovecot - All external inbound mail will be routed via HAProxy (haproxy.example.local) - The use of an SNI Map for the external domains (to ensure we use the correct LE certificate) - All outbound mail needs to be forwarded to a mail relay service (eg www.sendinblue.com) because our ISP will not / cannot allow us to set up a PTR DNS record (yes, we're seriously considering changing ISPs) Extra/Optional Desired Outcomes --- - RoundCube set up on www.example.local as an additional website and using mysql.example.local for data storage -
[pfx] Test Post - Please Ignore
Thanks Guys :-)___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Test Post - Please Ignore
Sorry Everyone, but I need to test if my posts are going through Please ignore (or feel free to send me a confirmation) Cheers Dulux-Oz ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
