[pfx] Re: [ext] multi smtp servers question
* Corey Hickman via Postfix-users : We have 3 smtp servers for sending messages. When mail in one server has delivery issue, how can we setup it to use another more servers for second/third delivery? Ralf Hildebrandt via Postfix-users skrev den 2023-05-04 14:41: You could use smtp_fallback_relay On 04.05.23 15:15, Benny Pedersen via Postfix-users wrote: this will work for mx with one ipv4, one ipv6, but fails if mx have more ips, think greylistning forever if the OP only configures one mailserver as smtp_fallback_relay - which is recommended delivery delays won't get significantly higher, and they happen only for mail that wasn't immediately delivered, which means delay already happened. switching outgoing IPs between delivery attempts causes delays no matter if you use fallback relay or not. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Remember half the people you know are below average. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. I had this problem too and I think that explicitly stating something like: virtual_alias_maps (if set) expansion is applied to all recipient addresses, even if they aren't local, so this way it's possible to redirect mail for remote recipients would help much. Also, mentioning the main difference between virtual_alias_maps (applied at input) and alias_maps (applied at delivery, supporting :include:, pipe and file destinations just as owner- prefix) would be nice to have. Especially since it's advised to move address expansion from aliases to virtual_alias_maps when possible to avoid double deliveries for problematic destinations. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. agree. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Matus UHLAR - fantomas via Postfix-users: > On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: > >While Wietse has his word processor open, I'd like to share a few of > >my greatest misdirects in my evolving understanding of Postfix. > > > >To quote a like minded individual > > > >I simply want to help others avoid my points of confusion, in the belief I > >am not a uniquirely incapable or unintelligent reader. > > > >1) virtual_alias_maps is not only applied to virtual_alias_domains, > >but to _all_ domains that Pf receives mail for. > >http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in > >this respect. I really wish I had understood this earlier, it would > >have saved a lot of time. > > I had this problem too and I think that explicitly stating something like: The problem is that this information exists in some places but not all places where aliasling is discussed. New text for postconf(5): virtual_alias_maps (default: $virtual_maps) Optional lookup tables with aliases that apply for all email deliveries, unlike alias_maps that apply only for local(8) delivery. [...] alias_maps (default: see "postconf -d" output) Optional lookup tables with aliases that apply only for local(8) delivery, unlike virtual_alias_maps which apply for all email deliveries. [...] New text for ADDRESS_CLASS_README: Virtual aliasing Note: virtual aliasing (virtual_alias_maps) applies for all email deliveries, unlike local aliasing (alias_maps) which applies only to local(8) delivery. Local alias database Note: local aliasing (alias_maps) applies only for local(8) delivery, unlike virtual aliasing (virtual_alias_maps) which applies for all email deliveries. Are there any other placs that need to bve updated? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
Viktor Dukhovni via Postfix-users:
> > So I would assume from that setting inet_interfaces to empty has the
> > same effect as setting it to all (it will listen on all interfaces)?
>
> No, it does not. Rather, it leaves zero listener addresses enabled,
> which only works if all "inet" services are disabled or all use explicit
> IP endpoints:
>
> May 05 03:43:45 amnesiac postfix/postfix-script[2812173]: starting the
> Postfix mail system
> May 05 03:43:45 amnesiac postfix/master[2812175]: fatal:
> /etc/postfix/master.cf: line 12: no valid IP address found: smtp
> May 05 03:43:47 amnesiac postfix/postfix-script[2812176]: fatal: mail
> system startup failed
>
> This is rarely what you want. I'd be inclined to require that the
> "inet_interfaces" parameter be non-empty (though it could still be
> effectively empty as a list by setting it to be a mixture of spaces and
> at least one comma).
There is code in Postfix that allows an empty inet_interfaces value.
That supports a valid use case, for example, an MTA that sends email
only.
Rather than tinkering with inet_interfaces semantics, I have
improved the error message a bit:
postfix/master[10639]: fatal: /etc/postfix/master.cf: line 79:
service definition requires valid host name or address, or
non-empty inet_interfaces setting
With master.cf line 79 containing
smtp inet n - n - 1 postscreen
The improved error message should be actionable enough.
Wietse
--- /var/tmp/postfix-3.9-20230504/src/master/master_ent.c 2021-01-08
20:19:30.0 -0500
+++ src/master/master_ent.c 2023-05-05 13:45:44.747539001 -0400
@@ -367,10 +367,17 @@
inet_addr_list_uniq(MASTER_INET_ADDRLIST(serv));
serv->listen_fd_count = MASTER_INET_ADDRLIST(serv)->used;
} else {
- MASTER_INET_ADDRLIST(serv) =
- strcasecmp(saved_interfaces, INET_INTERFACES_ALL) ?
- own_inet_addr_list() : /* virtual */
- wildcard_inet_addr_list(); /* wild-card */
+ if (strcasecmp(saved_interfaces, INET_INTERFACES_ALL) == 0) {
+ MASTER_INET_ADDRLIST(serv) = wildcard_inet_addr_list();
+ /* Errors, and no interface found, are fatal. */
+ } else {
+ MASTER_INET_ADDRLIST(serv) = own_inet_addr_list();
+ /* Errors are fatal, but inet_interfaces can be empty. */
+ if (MASTER_INET_ADDRLIST(serv)->used == 0)
+ fatal_with_context("service definition requires valid"
+ " host name or address, or non-empty"
+ " %s setting", VAR_INET_INTERFACES);
+ }
inet_addr_list_uniq(MASTER_INET_ADDRLIST(serv));
serv->listen_fd_count = MASTER_INET_ADDRLIST(serv)->used;
}
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] TLS Library Problem? (SSL_accept error from ...)
I have setup Postfix so that internally I offer TLS to systems but do not require it since I have no control over their configuration. I did extensive testing to ensure that the mail gateway supports TLS and accepts email from another Postfix system where TLS is disabled. But today I found a system failing to route email through the Postfix gateway today that has me baffled. My best guess based on searching the archives is that there may be a defect in the remote system that is causing the issue. I looked at the documentation and I think the next step would be to configure the smtpd_discard_ehlo_keyword_address_maps option and use a CIDR file for the mapping. (i.e. smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/smtpd_discard_ehlo_keyword_address_maps). The contents of the file would be the IP address of the system and the STARTTLS keyword if I want to disable TLS for this IP (i.e. 123.456.789.123 STARTTLS). I tested this on my test system with good ole telnet and it seems to have the effect I desired. Am I missing anything? [snippet from main.cf] smtpd_tls_security_level = may [snippet from log] May 05 16:27:59 zzz postfix/smtpd[1234567]: connect from xxx.xxx.xxx[yyy.yyy.yyy.yyy] May 05 16:27:59 zzz postfix/smtpd[1234567]: SSL_accept error from xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 May 05 16:27:59 zzz postfix/smtpd[1234567]: warning: TLS library problem: error:0398:digital envelope routines::invalid digest:crypto/evp/m_sigver.c:343: May 05 16:27:59 zzz postfix/smtpd[1234567]: warning: TLS library problem: error:0A0C0103:SSL routines::internal error:ssl/statem/statem_srvr.c:2684: May 05 16:27:59 zzz postfix/smtpd[1234567]: lost connection after STARTTLS from xxx.xxx.xxx[yyy.yyy.yyy.yyy] ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote: > postfix/smtpd[1234567]: SSL_accept error from xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 > postfix/smtpd[1234567]: warning: TLS library problem: > error:0398:digital envelope routines::invalid > digest:crypto/evp/m_sigver.c:343: > postfix/smtpd[1234567]: warning: TLS library problem: > error:0A0C0103:SSL routines::internal error:ssl/statem/statem_srvr.c:2684: This problem may be worth further analysis. It appears that OpenSSL has chosen a signature algorithm (public key algorithm + digest method, e.g. RSA with SHA256, ...) at the TLS layer, but failed to initialise a signature context at the crypto API layer. This is odd, because the known TLS layer combinations should map to known crypto layer primitives. Are you on a RedHat system perhaps? RedHat's latest releases have turned up crypto policy to "11", and may refuse to, for example, support RSA with SHA1. The remote client may have one of the really dated TLS stacks that doesn't know how to do anything better. If your system is a RHEL or recent Fedora or similar system, or perhaps by now other distributions have joined the club, then you'll to find the relevant crypto policy file and dial it down a bit (on an MTA doing opportunistic TLS, RSA with SHA1 is better than cleartext). Similar considerations may apply not only to MTAs but also to validating DNS resolvers, and perhaps other applications. The various distributions may publish instructions on recommnded ways to tune the crypto policy. If all the above is false lead, then the problem is more mysterious, and perhaps a PCAP file capturing a failed handshake would be a good next step. You should of course also share (https://www.postfix.org/DEBUG_README.html#mail) $ postconf -nf $ postconf -Mf without any changes in whitespace, including line breaks. Attaching these as text files may be simplest if your mail client won't coöperate. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote: > I have setup Postfix so that internally I offer TLS to systems but do not > require it since I have no control over their configuration. I did > extensive testing to ensure that the mail gateway supports TLS and accepts > email from another Postfix system where TLS is disabled. But today I found > a system failing to route email through the Postfix gateway today that has > me baffled. > > My best guess based on searching the archives is that there may be a defect > in the remote system that is causing the issue. I looked at the > documentation and I think the next step would be to configure the > smtpd_discard_ehlo_keyword_address_maps option and use a CIDR file for the > mapping. (i.e. smtpd_discard_ehlo_keyword_address_maps = > cidr:/etc/postfix/smtpd_discard_ehlo_keyword_address_maps). The contents > of the file would be the IP address of the system and the STARTTLS keyword > if I want to disable TLS for this IP (i.e. 123.456.789.123 STARTTLS). I > tested this on my test system with good ole telnet and it seems to have the > effect I desired. > > Am I missing anything? > > [snippet from main.cf] > smtpd_tls_security_level = may > > [snippet from log] > May 05 16:27:59 zzz postfix/smtpd[1234567]: connect from > xxx.xxx.xxx[yyy.yyy.yyy.yyy] > May 05 16:27:59 zzz postfix/smtpd[1234567]: SSL_accept error from > xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 > May 05 16:27:59 zzz postfix/smtpd[1234567]: warning: TLS library problem: > error:0398:digital envelope routines::invalid > digest:crypto/evp/m_sigver.c:343: > May 05 16:27:59 zzz postfix/smtpd[1234567]: warning: TLS library problem: > error:0A0C0103:SSL routines::internal error:ssl/statem/statem_srvr.c:2684: > May 05 16:27:59 zzz postfix/smtpd[1234567]: lost connection after STARTTLS > from xxx.xxx.xxx[yyy.yyy.yyy.yyy] Because TLS/SSL things are very complex, you have to show us real settings all. Like me: (yw-0919: inbound, yw-1204: outbound) [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 [2] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-1204 Then we go to check things, IMHO. Sincerely, ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
> > > > Because TLS/SSL things are very complex, you have to show us real > settings all. Like me: (yw-0919: inbound, yw-1204: outbound) > [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 > [2] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-1204 > And Postfix TLS support, https://www.postfix.org/TLS_README.html -- https://kenpeng.pages.dev/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Fri, May 05, 2023 at 08:28:48PM -0400, Viktor Dukhovni via Postfix-users wrote: > You should of course also share > (https://www.postfix.org/DEBUG_README.html#mail) > > $ postconf -nf > $ postconf -Mf > > without any changes in whitespace, including line breaks. Attaching > these as text files may be simplest if your mail client won't coöperate. And, if applicable, post the content of: /usr/share/crypto-policies/DEFAULT/opensslcnf.txt Which on a sample Fedora36 system holds: CipherString = @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256 TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3 DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2 SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 [openssl_init] alg_section = evp_properties [evp_properties] rh-allow-sha1-signatures = yes Postfix (at least in a default configuration) is not affected by: CipherString TLS.MinProtocol TLS.MaxProtocol DTLS.MinProtocol DTLS.MaxProtocol But currently has no controls to override: # TLS 1.3 ciphersuites (not a priority to fine-tune) Ciphersuites = ... # TLS 1.2 signature algorithm negotiation (the RH list is fine) SignatureAlgorithms = ... # If this is set to "no", TLS 1.0 key exchange is likely to break. # In some cases certificate verification may break. rh-allow-sha1-signatures = yes 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. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
