> > >
> > > /etc/postfix/main.cf:
> > > smtpd_sasl_type = dovecot
> > > smtpd_sasl_path = private/auth
> >
> > Can't this be done with tls withouth dovecot or sasl?
>
> Authentication is needed by Dovecot for IMAP access
> to read email. So it should be available for use by
> Postfix as well.
>
> Authentication should also be required by Postfix for
> submission of email from remote clients like
> Thunderbird. The only typical exception to that would
> be when the Thunderbird clients are on a "trusted"
> network, and so their IP address can take the place of
> SASL authentication in order for Postfix to decide that
> it's OK to accept mail from them to be relayed to the
> outside world. Some would argue that SASL
> authentication should always be used whenever possible.
>
> However, even though TLS (usually) only verifies the
> identity of the server, rather than authenticating the
> client, it can do that as well, by using client
> certificates in addition to the server certificate. See
> http://www.postfix.org/TLS_README.html for details.
>
Thank you
> So yes, you should be able to replace uses of
> permit_sasl_authenticated in various parameters
> with "smtpd_tls_req_ccert = yes" as -o option
> override in master.cf for your submission service.
> I'm sure there's more to it, but the TLS_README
> should help.
>
smtpd_tls_ask_ccert = yes
is on - so it is asking for client certificates?
But that is really not authetication, if I understand things.
> > I tried to do this and I get this error
> >
> >
> > An error occurred while sending mail: Outgoing server (SMTP) error. The
> > server responded: TLS not available due to local problem.
>
> The Postfix server's logfile should contain more information
> about what the local problem was.
FWIW, the error ended up being that there was no cache database
First I needed to create a pem file
/etc/postfix/tls/smtpd.pem which is a selft signed certificate and key
root readable only
www2:/etc/postfix/tls # ls -al
total 12
drwx------ 2 root postfix 4096 Jan 3 14:06 .
drwxr-xr-x 4 root root 4096 Jan 3 14:47 ..
-r-------- 1 root root 1998 Jan 3 11:27 smtpd.pem
and I had to create the cache database in /var/spool/postfix
queue_directory = /var/spool/postfix
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
>
> You can also use openssl to connect to the server and examine
> the certificate details, with a command like this for port 25 or 587:
>
> DOMAIN=example.com
> SERVER=example.com
> PORT=25
> echo | \
> openssl s_client -starttls smtp -showcerts -servername $SERVER -connect
> $DOMAIN:$PORT 2>/dev/null | \
> openssl x509 -inform pem -noout -text | less
>
> Or like this for port 465:
>
> DOMAIN=example.com
> SERVER=example.com
> PORT=465
> echo | \
> openssl s_client -showcerts -servername $SERVER -connect $DOMAIN:$PORT
> 2>/dev/null | \
> openssl x509 -inform pem -noout -text | less
>
> But will probably just confirm the local problem.
> The mail logs are more likely to help you identify
> the cause.
>
> > I have this in the config file now:
> >
> > /etc/postfix/main.cf
> >
> >
> > smtpd_sender_restrictions = hash:/etc/postfix/access,
> > reject_unknown_sender_domain
> >
> > smtpd_recipient_restrictions =
> > check_client_access hash:/etc/postfix/helo_client_exceptions
> > check_sender_access hash:/etc/postfix/sender_checks,
> > reject_invalid_hostname,
> > ### Can cause issues with Auth SMTP, so be weary!
> > reject_non_fqdn_hostname,
> > ##################################
> > reject_non_fqdn_sender,
> > reject_non_fqdn_recipient,
> > reject_unknown_sender_domain,
> > reject_unknown_recipient_domain,
> > permit_mynetworks,
> > reject_unauth_destination,
> > permit_mynetworks, reject_unauth_destination,
> > reject_invalid_hostname,
> > reject_non_fqdn_hostname,
> > reject_non_fqdn_sender,
> > reject_non_fqdn_recipient,
> > reject_unknown_sender_domain,
> > reject_unknown_recipient_domain,
> > reject_rbl_client zen.spamhaus.org,
> > reject_rbl_client bl.spamcop.net
> > reject_rbl_client cbl.abuseat.org,
> > permit
> > smtpd_data_restrictions = reject_unauth_pipelining, permit
> >
> > ############################################################
> > # SASL stuff
> > ############################################################
> > smtp_sasl_auth_enable = no
> > smtp_sasl_security_options =
> > smtp_sasl_password_maps =
> > smtpd_sasl_auth_enable = no
> > ############################################################
> > # TLS stuff
> > ############################################################
> > #tls_append_default_CA = no
> > relay_clientcerts =
>
> It looks like the relay_clientcerts parameter would do
> what you want, if you point it at a lookup table
> containing your client TLS certificate fingerprints.
> You'd need to use permit_tls_clientcerts in place of
> permit_sasl_authenticated in the appropriate
> smtp_*_restrictions parameter for the submission
> service in master.cf. See
> http://www.postfix.org/postconf.5.html#relay_clientcerts
> http://www.postfix.org/postconf.5.html#permit_tls_clientcerts
>
> However, it's probably much easier to use SASL authentication
> instead since you already have dovecot.
>
> > #tls_random_source = dev:/dev/urandom
> >
> > smtp_use_tls = yes
> > smtp_tls_loglevel = 1
> > smtp_enforce_tls = no
> > smtp_tls_CAfile = /etc/postfix/tls/smtpd.pem
> > #smtp_tls_CApath =
> > smtp_tls_cert_file = /etc/postfix/tls/smtpd.pem
> > smtp_tls_key_file = /etc/postfix/tls/smtpd.pem
>
> I don't think the above two parameters should be pointing
> to the same file. But I might be wrong about that. I've
> never had the Postfix server use a client certificate
> when sending mail out. But it really doesn't look right.
> Normally, the server would only use a specific client
> certificate for outgoing mail when sending to a particular
> transport that required it, not to all potential recipient
> servers as would be the case when putting those parameters
> in main.cf. It might be sensible to just replace the above
> with:
>
> smtp_tls_security_level = may
> smtp_tls_loglevel = 1
>
> > #smtp_tls_session_cache_timeout = 3600s
> > smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
>
> The above should probably use ${data_directory} rather
> than ${queue_directory}. But maybe that depends on the system.
> I think I had queue_directory originally but got warning messages
> in the logfile about it. If you aren't seeing those warnings,
> it's probably fine.
>
> > smtpd_use_tls = yes
> > smtpd_tls_loglevel = 1
> > smtpd_tls_CAfile = /etc/postfix/tls/smtpd.pem
> > #smtpd_tls_CApath =/etc/postfix/tls/smtpd.pem
> > smtpd_tls_cert_file =/etc/postfix/tls/smtpd.pem
> > smtpd_tls_key_file =/etc/postfix/tls/smtpd.pem
>
> The same pem file as above is being used as the server
> certificate as well. And the cert and key parameters
> are pointing to the same file again which looks unusual
> to me. Does it contain both the private key and the
> full chain? If so, you could use the
> smtpd_tls_chain_files parameter instead of
> smtpd_tls_cert_file and smtpd_tls_key_file.
>
> Using the same file for smtpd_tls_CAfile as well looks
> odd to me, but I'm not an expert. Maybe it's OK.
>
> > smtpd_tls_ask_ccert = yes
>
> Having the above in main.cf makes it apply to all
> incoming SMTP connections. I don't think you want that.
> You only want it for your own users whose client
> certificates you know about. It should be in master.cf
> where the submission/submissions services are defined.
> And it should be "smtpd_tls_req_ccert = yes" instead,
> so that the Thunderbird clients are required to possess
> a known client certificate (if SASL authentication is
> not going to be used).
>
> I hope what I've said makes sense.
>
> cheers,
> raf
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
