Re: config check
On Mon, Dec 09, 2019 at 07:17:46AM +, Felix Rubio wrote:
> My requirements are:
> - Require encrypted and authenticated user to submit mail from non-local
> (other than 127.0.0.x) connections
> - Allow unencrypted/unauthenticated users to submit mail from local
> (127.0.0.x) connections
> mynetworks = 127.0.0.0/24, 10.8.0.0/24, 172.17.0.0/16
> smtpd_relay_restrictions =
>permit_mynetworks
>permit_sasl_authenticated
>reject_unauth_destination
Well, clearly your definition of "non-local" is broader than 127.0.0.x,
it also include two RFC1918 address (sub)blocks.
> smtpd_tls_eecdh_grade = ultra
With OpenSSL 1.0.2 and later, the default is "auto", and you very much
SHOULD NOT override that.
> smtpd_tls_exclude_ciphers = aNULL, LOW, EXP, MEDIUM, ADH, AECDH,
> MD5, DSS, ECDSA, CAMELLIA128, 3DES, CAMELLIA256, RSA+AES, eNULL
What on earth is all that? Just go with the default setting instead of
pasting in random garbage from some clueless blog.
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
I'd leave TLS 1.0 enabled for at least another year, safer than
cleartext, and still used to some degree with SMTP.
> smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
Not needed, now that we have session tickets.
> tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
Don't, the default is fine.
> tls_ssl_options = no_ticket, no_compression
I doubt you can provide a good reasons to disable session tickets,
don't disable them.
> To fulfill my requirements with respect to local/remote authentication
> and encryption settings, in master.cf I have:
>
> smtp inet n - y - - smtpd
> -o smtpd_sasl_auth_enable=no
> submission inet n - y - - smtpd
> -o
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
This is largely ineffective. See the stock Postfix master.cf file for a
much better approach.
> 127.0.0.1:588 inet n - y - - smtpd
>-o smtpd_sasl_exceptions_networks=
>-o smtpd_tls_auth_only=no
There's no reason for this. Just use a single port 587 submission
service, then allow traffic from the loopback interface, and otherwise
reject unencrypted sessions via "reject_plaintext_session". The
below client access table should work.
allow-loopback.cidr:
127.0.0.0/8 OK
::1 OK
Then just:
mua_client_restrictions =
check_client_access cidr:${config_directory}/allow-loopback.cidr,
reject_plaintext_session,
permit_sasl_authenticated,
reject
Since the loopback clients won't need to authenticate, you don't need to
set "smtpd_tls_auth_only = no".
Your configuration looks much too dense with extraneous settings, I
don't have the cycles to review them all. Resist the urge to
over-customize, especially settings you don't fully understand.
--
Viktor.
config check
Hi all,
I have been running a postfix server for a while. Though I think I
have come with a sensible configuration, I have not been able to check
if it is really sound. Can somebody give it a look, security-wise?
My requirements are:
- Require encrypted and authenticated user to submit mail from non-local
(other than 127.0.0.x) connections
- Allow unencrypted/unauthenticated users to submit mail from local
(127.0.0.x) connections
Thank you very much for any hint you guys might have!
Felix
Output of postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_status_update_time = 2h
append_dot_mydomain = no
biff = no
compatibility_level = 2
confirm_delay_cleared = yes
default_process_limit = 5
delay_warning_time = 1h
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 26214400
milter_default_action = accept
milter_mail_macros = "i {mail_addr} {client_addr} {client_name}
{auth_authen}"
milter_protocol = 6
mydestination = $myhostname localhost.$mydomain localhost
mail.$mydomain
mydomain = example.com
myhostname = mail.example.com
mynetworks = 127.0.0.0/24, 10.8.0.0/24, 172.17.0.0/16
mynetworks_style = host
myorigin = $mydomain
notify_classes = resource, software
recipient_delimiter = +
relay_domains = $mydestination
relayhost = [smtp.myprovider.com]:587
smtp_cname_overrides_servername = no
smtp_connect_timeout = 30
smtp_header_checks = pcre:/etc/postfix/smtp_header_checks
smtp_helo_timeout = 60
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = high
smtp_tls_fingerprint_digest = sha1
smtp_tls_loglevel = 1
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keyword_address_maps =
hash:/etc/postfix/discard_ehlo
smtpd_error_sleep_time = 30
smtpd_etrn_restrictions = reject
smtpd_hard_error_limit = 4
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname
regexp:/etc/postfix/helo.regexp permit
smtpd_milters = local:/var/run/rspamd/worker-proxy.sock
smtpd_recipient_restrictions = permit_sasl_authenticated
permit_mynetworks reject_invalid_hostname reject_non_fqdn_hostname
reject_non_fqdn_sender reject_non_fqdn_recipient
reject_unknown_sender_domain reject_unauth_pipelining
reject_unverified_recipient permit
smtpd_relay_restrictions = permit_mynetworks
permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks
permit_sasl_authenticated reject_non_fqdn_sender
reject_unauth_pipelining reject_unlisted_sender permit
smtpd_soft_error_limit = 2
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /opt/example.com/certs/certificate.RSA.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = /opt/example.com/certs/dh4096.pem
smtpd_tls_eccert_file = /opt/example.com/certs/certificate.EC.pem
smtpd_tls_eckey_file = /opt/example.com/certs/private.EC.key
smtpd_tls_eecdh_grade = ultra
smtpd_tls_exclude_ciphers = aNULL, LOW, EXP, MEDIUM, ADH, AECDH,
MD5, DSS, ECDSA, CAMELLIA128, 3DES, CAMELLIA256, RSA+AES, eNULL
smtpd_tls_fingerprint_digest = sha256
smtpd_tls_key_file = /opt/example.com/certs/private.RSA.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_scache
strict_rfc821_envelopes = yes
tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
tls_ssl_options = no_ticket, no_compression
transport_maps = hash:/etc/postfix/transport
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
virtual_alias_domains =
virtual_alias_maps =
mysql:/etc/postfix/virtual/mysql-virtual-alias-maps.cf,
mysql:/etc/postfix/virtual/mysql-virtual-email2email.cf
virtual_gid_maps = static:5000
virtual_mailbox_domains =
Re: Unable to send mail via "smtp.office365.com"
* Gerard E. Seibert : > Thank you for that quick and accurate answer. I was just wondering, is > this a bug in 'libsasl' or is it due to a change in Outlook? My setup > had been working for years without any errors. It's very likely not a bug, but simply how SASL works. Unless configured explicitly to act different (any) SASL will always try to use the mechanism that offers the highest security strengh factor. OAUTH2 offers higher security than PLAIN, simply because PLAIN sends the identity (username, password) BASE64 encoded only. Encrypted connections are out of scope of the PLAIN mech. This said I do assume your system upgrade added OAUTH2 mechs, where there had been none on your old system. And what used to work because PLAIN was the only mech and therefore had the highest security strengh factor suddenly began to fail because now OAUTH2 was preferred over PLAIN. Limiting the list of SASL mechs that may be used, just like Wietse wrote, explicitly configures Cyrus SASL to ignore any other mechs except for those on the list. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Unable to send mail via "smtp.office365.com"
Wietse: >According to posttls-finger (below my signature), they support two >SASL authentication methods: LOGIN and XOAUTH2. > >Let's get rid of XOAUTH2: > ># postconf -e "smtp_sasl_mechanism_filter = login" ># postfix reload > >and see if that makes a difference. Gerard E. Seibert: > Thank you for that quick and accurate answer. I was just wondering, is > this a bug in 'libsasl' or is it due to a change in Outlook? My setup > had been working for years without any errors. That is a good question for: - The Cyrus SASL team. - Microsoft. Postfix code knows nothing about how SASL works. Wietse
Re: Unable to send mail via "smtp.office365.com"
On Sun, 8 Dec 2019 10:30:33 -0500 (EST), Wietse Venema stated: >Gerard E. Seibert: >> Dec 8 09:42:30 scorpio postfix/smtp[87448]: 47W8Dj4Q1jz1xx1: SASL >> authentication failed; cannot authenticate to server >> smtp.office365.com[52.96.58.98]: invalid parameter supplied > >The "invalid parameter supplied" is a libsasl error message. > >According to posttls-finger (below my signature), they support two >SASL authentication methods: LOGIN and XOAUTH2. > >Let's get rid of XOAUTH2: > ># postconf -e "smtp_sasl_mechanism_filter = login" ># postfix reload > >and see if that makes a difference. > > Wietse > >% posttls-finger 52.96.58.98 >...plaintext handshake and tls handshake deleted... >posttls-finger: Untrusted TLS connection established to >52.96.58.98[52.96.58.98]:25: TLSv1.2 with cipher >ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO >tail.porcupine.org posttls-finger: < >250-MN2PR13CA0023.outlook.office365.com Hello [70.104.130.26] >posttls-finger: < 250-SIZE 157286400 posttls-finger: < 250-PIPELINING >posttls-finger: < 250-DSN posttls-finger: < 250-ENHANCEDSTATUSCODES >posttls-finger: < 250-AUTH LOGIN XOAUTH2 >posttls-finger: < 250-8BITMIME >posttls-finger: < 250-BINARYMIME >posttls-finger: < 250-CHUNKING >posttls-finger: < 250 SMTPUTF8 >posttls-finger: > QUIT >posttls-finger: < 221 2.0.0 Service closing transmission channel > > Wietse Thank you for that quick and accurate answer. I was just wondering, is this a bug in 'libsasl' or is it due to a change in Outlook? My setup had been working for years without any errors. -- Gerard
Re: Unable to send mail via "smtp.office365.com"
Gerard E. Seibert: > Dec 8 09:42:30 scorpio postfix/smtp[87448]: 47W8Dj4Q1jz1xx1: SASL > authentication failed; cannot authenticate to server > smtp.office365.com[52.96.58.98]: invalid parameter supplied The "invalid parameter supplied" is a libsasl error message. According to posttls-finger (below my signature), they support two SASL authentication methods: LOGIN and XOAUTH2. Let's get rid of XOAUTH2: # postconf -e "smtp_sasl_mechanism_filter = login" # postfix reload and see if that makes a difference. Wietse % posttls-finger 52.96.58.98 ...plaintext handshake and tls handshake deleted... posttls-finger: Untrusted TLS connection established to 52.96.58.98[52.96.58.98]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO tail.porcupine.org posttls-finger: < 250-MN2PR13CA0023.outlook.office365.com Hello [70.104.130.26] posttls-finger: < 250-SIZE 157286400 posttls-finger: < 250-PIPELINING posttls-finger: < 250-DSN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-AUTH LOGIN XOAUTH2 posttls-finger: < 250-8BITMIME posttls-finger: < 250-BINARYMIME posttls-finger: < 250-CHUNKING posttls-finger: < 250 SMTPUTF8 posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Service closing transmission channel Wietse
Unable to send mail via "smtp.office365.com"
I use Postfix with "sender_dependent_relayhost_maps". Up until yesterday, it had been working flawlessly for years. Now, I am suddenly unable to send mail using "smtp.office365.com". This is the latest log entries for the last attempt. Dec 8 09:42:30 scorpio postfix/smtp[87448]: Trusted TLS connection established to smtp.office365.com[52.96.58.98]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Dec 8 09:42:30 scorpio postfix/smtp[87448]: 47W8Dj4Q1jz1xx1: SASL authentication failed; cannot authenticate to server smtp.office365.com[52.96.58.98]: invalid parameter supplied Dec 8 09:42:30 scorpio postfix/smtp[87448]: Trusted TLS connection established to smtp.office365.com[52.96.9.178]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Dec 8 09:42:30 scorpio postfix/smtp[87448]: 47W8Dj4Q1jz1xx1: SASL authentication failed; cannot authenticate to server smtp.office365.com[52.96.9.178]: invalid parameter supplied Dec 8 09:42:30 scorpio postfix/smtp[87448]: Trusted TLS connection established to smtp.office365.com[52.96.38.82]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Dec 8 09:42:30 scorpio postfix/smtp[87448]: 47W8Dj4Q1jz1xx1: SASL authentication failed; cannot authenticate to server smtp.office365.com[52.96.38.82]: invalid parameter supplied Dec 8 09:42:31 scorpio postfix/smtp[87448]: Trusted TLS connection established to smtp.office365.com[52.96.62.226]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Dec 8 09:42:31 scorpio postfix/smtp[87448]: 47W8Dj4Q1jz1xx1: to=, relay=smtp.office365.com[52.96.62.226]:587, delay=1.8, delays=0.14/0.02/1.7/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server smtp.office365.com[52.96.62.226]: invalid parameter supplied) I am not sure what the "invalid parmameter supplied" refers to. I am using postfix mail_version = 3.5-20191109 on a FreeBSD 11.3 system. Openssl version: OpenSSL 1.1.1d 10 Sep 2019 if it makes any difference. -- Gerard
