Postings by Micah Anderson

possible to reach hardenize's requirements?

The site <a href="" title=""></a> provides relatively decent Email reports,
along with other reports. It checks a number of things including certs,
MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all
good checks and recommendations, with the exception of the TLS one, I do
not see how its possible to meet their standards, and provide an email
server on the internet. However, I could be wrong, so I'm interested to
know if I am.

1. TLS versions: They don't like that TLS v1.1 and v1.0 are possible.

Update to recommended TLS settings

In 2015, Viktor wrote an email detailing the current recommended TLS

Now that we are three years later, are these still the best settings? Is
there something better we can be recommending?

If anything, I think that 'smtp_tls_security_level = may' should be
recommended (it actually should be *default*), but I'm wondering about
the other recommended ciphers/protocols/excludes etc. as well.


smtpd_reject_footer and smtps


I tried to add a smtpd_reject_footer to submission and smtps as an
option in my

submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c For further help, contact the support desk
smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c For further help, contact the support desk

the submission one took, but with smtps, I got an error:

"fatal: unexpected command-line argument: For"

why is it that th

Restricting From:


tl;dr: Is there really no way in postfix to restrict what "From" headers
a user may specify?

For outgoing mail, we would like to restrict the "From" header to match
the address users SASL authenticate with, or is configured as an alias
in their account. We have setup smtpd_sender_login_maps to use a SQL map
and configured smtpd_sender_restrictions to have the configuration
option reject_authenticated_sender_login_mismatch before
permit_sasl_authenticated. This works as expected.

However the problem is that the envelope "From" is being restricted, not
the header "From".

check_sasl_access duplicates


I've configured check_sasl_access to be a sql map, like so:


and that check_sasl_access.sql file has the regular database DBI bits,
and then the following query:

query = SELECT CONCAT("PREPEND X-User-ID: ", encrypt_user_id(mailboxes.user_id)) FROM mailboxes WHERE mailboxes.address = '%s';

this encrypt_user_id(mailboxes.user_id) is a stored procedure in the
database which allows me to create a hash of the sasl authenticated
user_id, with a secret, and returns a header value that helps us
identify users (esp.

Is there the opposite of $permit_tls_clientcerts available?

For the purposes of better scaling things out, I would prefer to
maintain a table of certificate fingerprints that I want to deny, rather
than a table of certificates that I want to allow. Such a table would
need to be updated a small fraction of the time that an allow list would
need to be updated, and would produce the same effect, but more

However, from what I can tell, postfix only has $permit_tls_clientcerts,
and no $denied_tls_clientcerts. Because I will have a lot of churn with
new certs being generated continually, I would rather have the

postfix hardening - what can we do?

From my understanding of the way postfix currently operates, there is no
smtpd/stmp TLS setting that can be set that would provide a
configuration that would result in a more 'hardened' configuration,
without causing interoperability problems.

problem talking to server private/tlsmgr: Resource temporarily unavailable

I'm running a busy server that is periodically experiencing problems
with tlsmgr, at various times (typically once a day at minimum), the
following appears in the logs:

Jun 16 07:34:40 willet postfix/smtp[24449]: warning: connect to private/tlsmgr: Resource temporarily unavailable
Jun 16 07:34:40 willet postfix/smtp[24449]: warning: problem talking to server private/tlsmgr: Resource temporarily unavailable


this sometimes results in mailer-daemon bounces to postmaster with the
SMTP protocol messages including "TLS unavailable due to local

Why use EGD instead of /dev/urandom in tls_random_source?

Obviously it is well understood that the security of cryptographic
software, such as TLS, depends on good random numbers. Postfix's
tlsmgr(8) maintains a PRNG pool, which is fed from an external source,
configured via tls_random_source, typically /dev/urandom (default on
Linux systems). Presumably, the tlsmgr's PRNG takes the data from the
tls_random_source and mixes it around in its own pool.

The TLS_README[0] talks about the possibility of specifying EGD as a
random source, but I'm not sure why you would specify EGD directly as a
random source because EGD keeps the kernel pool topped off.

mysql transport failover

I would like to reduce the mysql transport retry time (or perhaps the
proxymap retry time?), is there a variable that I can tweak down to
reduce the time between retries of mysql transport connection losses?

I'm using mysql for transport_maps and virtual_mailbox_maps.

transport_maps = proxy:mysql:$maps_dir/
virtual_mailbox_maps = mysql:$maps_dir/

these are configured to contact a locat stunnel process which connects
to a mysql cluster over an encrypted connection.