On 2024-12-12 23:46, max.hesserchen via Postfix-users wrote: > > I am the only user of my setup on my debian 12 server. I am convinced > that minimalism is the best security.
Not in the sense you're using it. It's about minimalism in exposure surface, not in configuration burden and you seem to be doing the latter, stripping down functions (also security ones). > The only thing I'm currently still evaluating is whether I should set > /smtp_tls_security_level/ higher.And now as I write this I realize that > I will also set /smtp_tls_mandatory_protocols/ to >=TLSv1.3. Well, you could also close port 25 - there's little to be more minimalistic here... If you worry about exposing your e-mail address, then I doubt you should use mail anyway. You could also reject all incoming mail except from well-known senders. I don't know the threat you're trying to protect from, but I doubt increasing TLS is something you need for one-user environment (I guess you're not some government agency nor send confidential data that need to stay secure in post-quantum world). Do you communicate in some closed-group? Then requesting validated certificates for mail is the fastest way to make it "closed". > But apart from that, I wonder what other settings I can make to make my > system even more secure and minimalistic? More secure, but more complex: 1. using one-time/per-sender mail addresses, possibly using non-standard recipient_delimiters (there can be more of them), 2. using postscreen, 3. using milters (e.g. MIMEDefang; I see two in your config), for example I'm limiting recipients in To: and CC: fields against "exposing entire address book" scenarios (when used instead of BCC:) and disabling MDN requests for accounts that shouldn't ever respond to them. 4. (Selective) greylisting, 5. using geolocation to apply different policies (e.g. by redirecting traffic to different port with different restrictions), 6. disabling IPv6 (another controversial move), 7. using DNS filters, threat intelligence sources (various CERT/CSIRT lists), 8. other options, like: # this is "security" in terms of assuring/watching deliverability delay_warning_time = 1h confirm_delay_cleared = yes enable_threaded_bounces = yes always_add_missing_headers = yes allow_percent_hack = no # "system" security authorized_flush_users = authorized_mailq_users = authorized_submit_users = respectful_logging = no # limits for "sanitization" kind of security default_destination_recipient_limit = 12 hopcount_limit = 12 smtpd_client_auth_rate_limit = 6 smtpd_client_connection_count_limit = 12 smtpd_client_connection_rate_limit = 20 smtpd_client_message_rate_limit = 32 smtpd_client_new_tls_session_rate_limit = 20 smtpd_client_recipient_rate_limit = 64 smtpd_recipient_limit = 32 smtpd_recipient_overshoot_limit = 8 virtual_alias_address_length_limit = 256 virtual_alias_expansion_limit = 96 virtual_alias_recursion_limit = 32 smtpd_soft_error_limit = 3 smtpd_hard_error_limit = 5 smtpd_junk_command_limit = 5 strict_rfc821_envelopes = yes smtputf8_enable = no smtpd_error_sleep_time = 10s # smuggling in older versions smtpd_forbid_bare_newline = yes smtpd_forbid_unauth_pipelining = yes smtpd_sasl_auth_enable=no smtpd_discard_ehlo_keywords=silentdiscard,dsn,etrn,size,chunking,vrfy # masking authenticated/local user in outgoing mail header_checks=pcre:/etc/mail/header_checks /^Received: from \S+ \(\S+ \[[.\d]+\]\)(.*)$/ REPLACE Received: from localhost (localhost [127.0.0.1])${1} Also, your *_restrictions look a bit too simple - mine are ~100 lines long (one per line, including newlines and comments). > Compatibility with old systems > is currently not a priority (which is for example why >= TLSv1.3), and I > don't care about optimal performance at the moment. Then maybe disable IPv4 and leave IPv6 only? Again - not sure what's your threat model. I guess your milters already do SPF, DKIM and DMARC checks. > My request does not refer to general things like ssh or fail2ban, only > to Postfix. Do you have any ideas? Expose your e-mail in the wild and start solving real problems that arise, this is where ideas come from. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org