[pfx] Re: [ext] TLS issues

2023-07-12 Thread Emmanuel Seyman via Postfix-users 
* Ralf Hildebrandt via Postfix-users [12/07/2023 11:15] :
>
> Try adding:
> smtp_tls_key_file = $smtpd_tls_key_file
> smtp_tls_cert_file = $smtpd_tls_cert_file

Once I added this to my main.cf and reloaded postfix, I saw that emails
were getting correctly delivered. Thank you, Ralf!

Emmanuel
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to verify that DH key generation parameters from RFC 7919 are used?

2023-07-12 Thread Viktor Dukhovni via Postfix-users 
On Wed, Jul 12, 2023 at 11:16:56AM +0300, Ivan Hadzhiev via Postfix-users wrote:

> You can copy from here:
> *https://github.com/internetstandards/dhe_groups/blob/main/ffdhe4096.pem 
> 
> *
> or you can create it
> 
> *openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 
> -out /etc/postfix/ffdhe4096.dh.param*

At this point, best to just use the defaults, and also to not to become
too obsessive about cranking up the cryptographic parameters.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to verify that DH key generation parameters from RFC 7919 are used?

2023-07-12 Thread Viktor Dukhovni via Postfix-users 
On Wed, Jul 12, 2023 at 10:09:34AM +0200, Paul Menzel via Postfix-users wrote:

> The Internet.nl email test, reports for molgen.mpg.de [1]:

Their criteria are cranked up to 11.  Do not attempt to get a 100% score
from their site.  It will be counterproductive (reduce security) by
making it difficult for some sites to negotiate an adequately secure
connection.  See .


> > Key exchange parameters
> > 
> > Verdict: At least one of your mail servers supports insufficiently
> > secure parameters for Diffie-Hellman key exchange.
> > 
> > Technical details:
> > 
> > c1241.mx.srv.dfn.de.DH-2048 insufficient
> > b1241.mx.srv.dfn.de.DH-2048 insufficient
> > a1241.mx.srv.dfn.de.DH-2048 insufficient

This is misguided.  If 2048-bit RSA root CAs are good enough for WebPKI,
system software updates, ... then 2048-bit DH parameters are also  good
enough for opportunistic TLS in SMTP.

> The test seems to follow Dutch recommendations:

The recommendations are much too strict.

> Postfix’ *TLS Forward Secrecy in Postfix* [4] says:
> 
> > Postfix ≥ 3.1 supports 2048-bit-prime FFDHE out of the box, with no
> > additional configuration.
> 
> Where in the code would I find the key material? `tlsproxy/tlsproxy.c` 
> calls `TLS_SERVER_INIT()`, and `tls_server_init()` in `tls/tls_server.c` 
> contains:

With sufficiently recent Postfix releases, just leave the dh parameters
unset, and Postfix will choose an appropriate good based on the rest of
handshake parameters (TLS 1.2) or as offered by the peer (TLS 1.3).

The explicit "auto" setting is equivalent to empty:

smtpd_tls_dh1024_param_file = auto

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How to verify that DH key generation parameters from RFC 7919 are used?

2023-07-12 Thread Paul Menzel via Postfix-users 

Dear Ivan,


Thank you very much for your reply.

Am 12.07.23 um 10:16 schrieb Ivan Hadzhiev:

You can copy from here:
https://github.com/internetstandards/dhe_groups/blob/main/ffdhe4096.pem
or you can create it

openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 -out 
/etc/postfix/ffdhe4096.dh.param


I downloaded the 3072 bit file and set it up:

# wget -O /project/mx/etc/ffdhe3072.pem 
https://github.com/internetstandards/dhe_groups/blob/main/ffdhe3072.pem

# postconf -n smtpd_tls_dh1024_param_file
smtpd_tls_dh1024_param_file = /project/mx/etc/ffdhe3072.pem
# postfix reload

But the Internet.nl email test still says that DH 2048 is offered by 
mx3.molgen.mpg.de [1].


mx3.molgen.mpg.de.  DH-2048 insufficient

So I am still curious, how to verify that.


Kind regards,

Paul


[1]: https://www.internet.nl/mail/recomb.org/972775/
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: [ext] TLS issues

2023-07-12 Thread Viktor Dukhovni via Postfix-users 
On Wed, Jul 12, 2023 at 11:15:14AM +0200, Ralf Hildebrandt via Postfix-users 
wrote:

> > smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
> > smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
> 
> Try adding:
> 
> smtp_tls_key_file = $smtpd_tls_key_file
> smtp_tls_cert_file = $smtpd_tls_cert_file

A knee-jerk response to Configure a random client certificate to present
to some random server is unlikely to solve the problem.

When I send a probe (sendmail -bv) to postmas...@pwc.com, no request for
"TLS athentication" occurs:


postfix/pickup[99363]: D4EDF130B11: uid=1001 from=<...>
postfix/cleanup[99523]: D4EDF130B11: message-id=<...>
postfix/qmgr[39752]: D4EDF130B11: from=<...>, size=292, nrcpt=1 (queue 
active)
postfix/smtp[99528]: Untrusted TLS connection established to 
mx07-00096706.pphosted.com[185.132.181.231]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
postfix/smtp[99528]: D4EDF130B11: to=, 
relay=mx07-00096706.pphosted.com[185.132.181.231]:25, delay=2.8, 
delays=0.01/0.03/2.4/0.43, dsn=2.1.5, status=deliverable (250 2.1.5 Recipient 
ok)

The probe notification message confirms the above:

: delivery via
mx07-00096706.pphosted.com[185.132.181.231]:25: 250 2.1.5 Recipient ok

The OP's issue is most likely that ProofPoint expect messages from the
envelope sender in question to be *outbound*, because they host the
sender domain, and for outbound mail, they require authentication.

This could be viewed as an anti-forgery mechanism.  If you want to send
mail via their systems on behalf of the domain in question, the outbound
traffic has to be authenticated.

The key question here is what was the "anotherdomain.com" (sender
address domain part) in the OP's post, and is it a ProofPoint customer
for outbound and/or inbound email delivery?

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local sending - solved

2023-07-12 Thread Ken Gillett via Postfix-users 
I had already configured mydestination to include 'home', but looking back 
after sorting out my configuration issues, I just noticed that myhostname and 
mydomian both used a domain name I no longer use. Oops.

Having corrected both those, I am able to send to user@home from any host on 
the LAN and it arrives in the appropriate dovecot mailbox that I then access 
with IMAP, which is EXACTLY what I was trying to achieve.

Thank you for all your help, my local email is now how I want it.

Next step will be moving to FreeBSD, but won't be for a while yet.

Thanks again.


Ken  G i l l e t t

_/_/_/_/_/_/_/_/



> On Wed 12 Jul 2023, at 11:55, Jaroslaw Rafa via Postfix-users 
>  wrote:
> 
> Dnia 12.07.2023 o godz. 11:41:49 Ken Gillett via Postfix-users pisze:
>> 
>> Since the error stating it could not resolve 'home' I added an MX record
>> to the DNS and now the error says the address "loops back to myself". I
>> forget the exact wording as a power cut means I lost the full exact
>> message I copied.
> 
> "Loops back to myself" message means that Postfix isn't configured to handle
> mail addressed to "...@home" as local delivery - it doesn't "know" it should
> handle that mail, so tries to resolve "home" and relay the mail to the
> resolved address, and finds out the resolved address is its own address -
> hence "loops back to myself".
> 
> You have to make Postfix recognize "home" as its locally-handled hostname.
> "mydestination=" maybe?
> -- 
> Regards,
>   Jaroslaw Rafa

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local sending

2023-07-12 Thread Jaroslaw Rafa via Postfix-users 
Dnia 12.07.2023 o godz. 11:41:49 Ken Gillett via Postfix-users pisze:
> 
> Since the error stating it could not resolve 'home' I added an MX record
> to the DNS and now the error says the address "loops back to myself". I
> forget the exact wording as a power cut means I lost the full exact
> message I copied.

"Loops back to myself" message means that Postfix isn't configured to handle
mail addressed to "...@home" as local delivery - it doesn't "know" it should
handle that mail, so tries to resolve "home" and relay the mail to the
resolved address, and finds out the resolved address is its own address -
hence "loops back to myself".

You have to make Postfix recognize "home" as its locally-handled hostname.
"mydestination=" maybe?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: local sending

2023-07-12 Thread Ken Gillett via Postfix-users 
To be clear about this issue, although I object to organisations' sloppy 
attitude to standards, my question here is not about the use of an address 
without even an @. I use Apple Mail and that does not allow it, so I have set 
it up to use user@home and that will suffice.

The issue is that this does not work on the actual mail server. I can send from 
other rmachines ok, but not from the mail server itself.

Since the error stating it could not resolve 'home' I added an MX record to the 
DNS and now the error says the address "loops back to myself". I forget the 
exact wording as a power cut means I lost the full exact message I copied.

In reply to other replies that I did not receive due to email issues:-

I don't want to involve the hosts or any other file as everything is maintained 
centrally in the DNS.

It was stated that sending from a different host on the network used SMTP, 
implying that it does not when sent locally on the mail server. Does 
(postfix)sendmail not always use SMTP? In any case, how does that affect this 
problem?

Also that the executables being run are likely to be the default ones and not 
those configured for the MacOSX Server. So I will change the PATH order and see 
if that makes any difference.

Any repetition here is because I'm not sure if previous emails reached the 
list. External email issues have required me to change the email address I'm 
using to avoid any future problems.


Ken  G i l l e t t

_/_/_/_/_/_/_/_/



> On Tue 11 Jul 2023, at 21:28, Wietse Venema via Postfix-users 
>  wrote:
> 
> Ken Gillett via Postfix-users:
>> I disagree about Apple. In this respect they most definitely ARE
>> idiots. Email addresses do NOT require anything after the @. That
>> simply means the user of that name on the current host. If they
> 
> Postfix by design makes this impossible; it was written as a 
> networked MTA. If you run it on an isolated instance, you can use
> username@localdomain.
> 
>   Wietse
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: [ext] TLS issues

2023-07-12 Thread Ralf Hildebrandt via Postfix-users 
> smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
> smtpd_tls_key_file = /etc/pki/tls/private/postfix.key

Try adding:

smtp_tls_key_file = $smtpd_tls_key_file
smtp_tls_cert_file = $smtpd_tls_cert_file

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] TLS issues

2023-07-12 Thread Emmanuel Seyman via Postfix-users 

Hello, all.

Last weekend, $WORK moved over to 2 smtp gateways running
postfix/clamav/spamassissin. This setup has been running with only one
issue: two domains refuse to accept mail from us.

Investigating this, we realized that both domains use the same mail
servers and that they both require TLS authentication. From the debug
trace, it appears that we successfully use TLS but that the server on
the other side keeps on requesting TLS authentification.

If anyone knows how to fix this, any help would be much appreciated.

I've attached my "postconf -n" output and log of one exchange. Both have
been slightly edited to protect the guilty and the innoncent alike.

Regards,
Emmanuel
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 5
debug_peer_list = mx07-00096706.pphosted.com mx08-00096706.pphosted.com
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = mail01.mydomain.com
mynetworks = 193.XX.YY.0/24
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_policy_maps = hash:/etc/postfix/smtp_tls_policy
smtp_tls_security_level = may
smtpd_milters = 
unix:/run/clamav-milter/clamav-milter.socket,unix:/run/spamass-milter/spamass-milter.sock
smtpd_recipient_restrictions = check_sender_access 
hash:/etc/postfix/sender_access
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_mailbox_domains = adomain.de anotherdomain.com mydomain.com 
yetanotherdomain.de
virtual_transport = smtp:internalsmtp.mydomain.com
Jul 11 17:18:42 ehlpg1fr postfix/smtp[519030]: D9B68665FC0: 
to=, 
relay=internalsmtp.mydomain.com[193.XX.YY.210]:25, delay=1.8, 
delays=1.6/0.08/0.02/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
47FE271083C)
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: smtp_stream_setup: maxtime=300 
enable_deadline=0
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: vstream_buf_get_ready: fd 17 got 
51
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 220 mx08-00096706.pphosted.com 
ESMTP mfa-m0240466
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: > 
mx08-00096706.pphosted.com[91.207.212.192]:25: EHLO mail01.mydomain.com
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: vstream_fflush_some: fd 17 flush 
29
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: vstream_buf_get_ready: fd 17 got 
167
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 250-mx08-00096706.pphosted.com 
Hello mail01.mydomain.com [193.XX.YY.130], pleased to meet you
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 250-ENHANCEDSTATUSCODES
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 250-PIPELINING
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 250-8BITMIME
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 250 STARTTLS
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: server features: 0x1017 size 0
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: Using ESMTP PIPELINING, TCP send 
buffer size is 46080, PIPELINING buffer size is 4096
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: smtp_stream_setup: maxtime=300 
enable_deadline=0
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: > 
mx08-00096706.pphosted.com[91.207.212.192]:25: STARTTLS
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: vstream_fflush_some: fd 17 flush 
10
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: vstream_buf_get_ready: fd 17 got 
30
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: < 
mx08-00096706.pphosted.com[91.207.212.192]:25: 220 2.0.0 Ready to start TLS
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: event_request_timer: reset 
0x7f363cfe23b0 0x5654d0945f10 5
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: send attr request = seed
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: send attr size = 32
Jul 11 17:18:43 ehlpg1fr postfix/smtp[519030]: vstream_

[pfx] Re: How to verify that DH key generation parameters from RFC 7919 are used?

2023-07-12 Thread Ivan Hadzhiev via Postfix-users 

You can copy from here:
*https://github.com/internetstandards/dhe_groups/blob/main/ffdhe4096.pem 


*
or you can create it

*openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 
-out /etc/postfix/ffdhe4096.dh.param*


**

*Cheers,*
*Ivan*
On 12.7.2023 г. 11:09, Paul Menzel via Postfix-users wrote:

Dear Postfix folks,


The Internet.nl email test, reports for molgen.mpg.de [1]:


Key exchange parameters

Verdict: At least one of your mail servers supports insufficiently
secure parameters for Diffie-Hellman key exchange.

Technical details:

c1241.mx.srv.dfn.de. DH-2048 insufficient
b1241.mx.srv.dfn.de. DH-2048 insufficient
a1241.mx.srv.dfn.de. DH-2048 insufficient

DHE: The security of Diffie-Hellman Ephemeral (DHE) key exchange
depends on the lengths of the public and secret keys used within the
chosen finite field group. We test if your DHE public key material
uses one of the predefined finite field groups that are specified in
RFC 7919. Self-generated groups are 'Insufficient'.


The test seems to follow Dutch recommendations:


See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1'
from NCSC-NL [2], guideline B5-1 and table 9 for ECDHE, and guideline
B6-1 and table 10 for DHE (in English).
How can I check myself, what “DHE public key material“ is used to 
compare it with the ones specified in RFC 7919 [3]?


Postfix’ *TLS Forward Secrecy in Postfix* [4] says:


Postfix ≥ 3.1 supports 2048-bit-prime FFDHE out of the box, with no
additional configuration.


Where in the code would I find the key material? `tlsproxy/tlsproxy.c` 
calls `TLS_SERVER_INIT()`, and `tls_server_init()` in 
`tls/tls_server.c` contains:


    if (*props->dh1024_param_file != 0)
    tls_set_dh_from_file(props->dh1024_param_file);
    tls_tmp_dh(server_ctx, 1);

That then seems to use the OpenSSL function d2i_DHparams?

    tls/tls_dh.c:    if (d2i_DHparams(&tmp, &endp, sizeof(builtin_der))


Kind regards,

Paul


PS: Is the “preferred” in the comment in `tls/tls_server.c` outdated?

 * Diffie-Hellman key generation parameters can either be 
loaded from
 * files (preferred) or taken from compiled in values. First, 
set the


[1]: https://www.internet.nl/mail/molgen.mpg.de/968847/
[2]: 
https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1

[3]: https://www.rfc-editor.org/rfc/rfc7919.html
[4]: https://www.postfix.org/FORWARD_SECRECY_README.html
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] How to verify that DH key generation parameters from RFC 7919 are used?

2023-07-12 Thread Paul Menzel via Postfix-users 

Dear Postfix folks,


The Internet.nl email test, reports for molgen.mpg.de [1]:


Key exchange parameters

Verdict: At least one of your mail servers supports insufficiently
secure parameters for Diffie-Hellman key exchange.

Technical details:

c1241.mx.srv.dfn.de.DH-2048 insufficient
b1241.mx.srv.dfn.de.DH-2048 insufficient
a1241.mx.srv.dfn.de.DH-2048 insufficient

DHE: The security of Diffie-Hellman Ephemeral (DHE) key exchange
depends on the lengths of the public and secret keys used within the
chosen finite field group. We test if your DHE public key material
uses one of the predefined finite field groups that are specified in
RFC 7919. Self-generated groups are 'Insufficient'.


The test seems to follow Dutch recommendations:


See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1'
from NCSC-NL [2], guideline B5-1 and table 9 for ECDHE, and guideline
B6-1 and table 10 for DHE (in English).
How can I check myself, what “DHE public key material“ is used to 
compare it with the ones specified in RFC 7919 [3]?


Postfix’ *TLS Forward Secrecy in Postfix* [4] says:


Postfix ≥ 3.1 supports 2048-bit-prime FFDHE out of the box, with no
additional configuration.


Where in the code would I find the key material? `tlsproxy/tlsproxy.c` 
calls `TLS_SERVER_INIT()`, and `tls_server_init()` in `tls/tls_server.c` 
contains:


if (*props->dh1024_param_file != 0)
tls_set_dh_from_file(props->dh1024_param_file);
tls_tmp_dh(server_ctx, 1);

That then seems to use the OpenSSL function d2i_DHparams?

tls/tls_dh.c:if (d2i_DHparams(&tmp, &endp, sizeof(builtin_der))


Kind regards,

Paul


PS: Is the “preferred” in the comment in `tls/tls_server.c` outdated?

 * Diffie-Hellman key generation parameters can either be 
loaded from
 * files (preferred) or taken from compiled in values. First, 
set the


[1]: https://www.internet.nl/mail/molgen.mpg.de/968847/
[2]: 
https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1

[3]: https://www.rfc-editor.org/rfc/rfc7919.html
[4]: https://www.postfix.org/FORWARD_SECRECY_README.html
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org