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

Reply via email to