71GA's questions

I set up Opendkim milter to work with postfix on my machine. Now email is signed & verified correctly i.e. email source code shows DKIM-Signature header.

TXT record on the authorative dns is set up like this:

┌───┐
│ # │ root > server > ~
└─┬─┘
  └─> delv -t txt dkim-domain._domainkey.domain.eu
...
...
dkim-domain._domainkey.domain.eu. 1780 IN TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8drA4hH8gJaVpLaHhtQonhpOeanMo/oPmrAVehP3lBYAjsoxifCIclLqJo7kk0maelqu9SIN9ttQ0boCzEiQBMO1" "c1P+Sj/PxphZB71c8VNhqMJ32VG6Ky3ZD4Tds39Vye/wsWdi+842MUT3Z2dJnxS2AAG4pSkjaytFPCs0J94OUQC0tDErbnsMZh+gg+7IsYgND8FR/cRDzpXjD0qFJk4Cnc1q27WorPAGAiRsRfLt9u" "gkYgQRwapnofmKJ3hk/L8096YR7gan60L4+RGojsx5ppTdIEhYasyK9MokefmVeNyGwVXTJchqG8vhcg9uGjGy9mPiPg4B2TQgEBPwyQIDAQAB"
...
...

So on first glance everything is okay but when I run the diagnostics on my machine it says this:

┌───┐
│ # │ root > server > ~
└─┬─┘
  └─> opendkim-testkey -d domain.eu -s dkim-domain -vvv

opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'dkim-pistam._domainkey.pistam.eu'
opendkim-testkey: key not secure
opendkim-testkey: key OK

Note the key not secure answer. I read from this answer that warning exists because DNSSEC is not enabled. But DNSSEC for my domain domain.eu is enabled. according to the DNSViz.

ADD:

It may be that the topic I linked to earlier is missleading, because I later read an answer here, suggesting that warning is due to too permissive privileges regarding the key pair! I set user rights on the key pair and their folder like this:

┌───┐
│ # │ root > server > ~
└─┬─┘
  └─> ls -l /etc/opendkim/keys/
total 8
-rw------- 1 opendkim opendkim 1675 Dec 30 08:45 dkim-rsa-private.key
-rw------- 1 opendkim opendkim  451 Dec 30 08:46 dkim-rsa-public.key

┌───┐
│ # │ root > server > ~
└─┬─┘
  └─> ls -ld /etc/opendkim/keys/
drwx------ 2 opendkim opendkim 4096 Jan  1 07:18 /etc/opendkim/keys/

So it should be secure... But it is not.

Postfix installation procedure created a system user postfix and it's primary group postfix while installation procedure for OpenDKIM created a system user opendkim and it's primary group opendkim.

To enable Postfix and OpenDKIM to work together most of the administrators do two things:

A

They append a secondary group opendkim to Postfix.

B

They set OpenDKIM configuration file /etc/opendkim.conf to create a UNIX socket using these three (two) lines:

UMask                   002
PidFile                 /var/run/opendkim/opendkim.pid
Socket                  local:/var/spool/postfix/opendkim/opendkim.sock

Official OpenDKIM documentation states this for the configuration parameter UMask:

Requests a specific permissions mask to be used for file creation. This only really applies to creation of the socket when Socket specifies a UNIX domain socket, and to the PidFile (if any);

I know that UNIX sockets are convenient because they can limit user privileges. In my case I want OpenDKIM to work with Postfix as safe as possible. But with UMask set to 002 UNIX socket will be created with ownership opendkim:opendkim and privileges 664 = rw-rw-r--.

I understand that group members (Postfix) need to read and write to the UNIX socket, but I don't understand why almost all tutorials online (A, B, C...) leave read permissions for others?

Is this a general missconception? Wouldn't a reasonable value for UMask be 007? Also the PID file is created using the same privileges...

If I check any other UNIX socket on my system some also have rights for others... Why is that important to have?

┌───┐
│ # │ root > mailer > ~
└─┬─┘
  └─> ss -x -l | head -n 10
Netid State  Recv-Q Send-Q                               Local Address:Port                                   Peer Address:Port                                 
u_dgr UNCONN 0      0                              /run/systemd/notify 14848                                             * 0                                    
u_str LISTEN 0      128               /var/run/dovecot/director-userdb 13957121                                          * 0                                    
u_str LISTEN 0      128                           /run/systemd/private 14852                                             * 0                                    
u_str LISTEN 0      100                          /var/run/dovecot/dict 13957125                                          * 0                                    
u_str LISTEN 0      128                    /var/run/dovecot/dict-async 13957129                                          * 0                                    
u_str LISTEN 0      1                      /var/run/irqbalance568.sock 17673                                             * 0                                    
u_dgr UNCONN 0      0                      /run/systemd/journal/syslog 14859                                             * 0                                    
u_str LISTEN 0      128                        /var/run/dovecot/config 13957133                                          * 0                                    
u_str LISTEN 0      128                   /var/run/dovecot/login/login 13957135                                          * 0                                    

┌───┐
│ # │ root > mailer > ~
└─┬─┘
  └─> ls -l /var/run/dovecot/config 
srw------- 1 root root 0 Dec 31 07:35 /var/run/dovecot/config

┌───┐
│ # │ root > mailer > ~
└─┬─┘
  └─> ls -l /var/run/dovecot/login/login 
srw-rw-rw- 1 root root 0 Dec 31 07:35 /var/run/dovecot/login/login

I am using this login_greeting for IMAP(S) protocol:

protocol imap {
  login_greeting = "mail.domain.eu -------> \"WELCOME TO PORT 993!\""
}

I want to know if it's possible to add a new line character at the beginning of the string? This doesn't work:

protocol imap {
  login_greeting = "\nmail.domain.eu -------> \"WELCOME TO PORT 993!\""
}

And this reports an error because it looks like configuration parameters have to be in one line:

protocol imap {
  login_greeting = "
  mail.domain.eu -------> \"WELCOME TO PORT 993!\""
}

Any other idea?

I wonder if it is okay to generate a key pair (.key and .cert files) for DKIM like this:

openssl req -newkey rsa:2048 -sha256 -x509 -nodes -days 3650 -keyout dkim-rsa.key -out dkim-rsa.cert

By reading RFC 6376 I can see that standards only demand RSA algorythm sha256 and maximum length of 2048. Are there any other recommenrdations that you would have for me before I create the keys?

I am using this chunk of code inside /etc/postfix/master.cf to force people to securely "subimt" email through port 465 which uses protocol SMTPS. SMTPS supports mandatory TLS which I use to demand from clients to 1st "encrypt" connection using mandatory TLS and 2nd "authenticate" using SASL mechanism.

smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
#
  -o smtpd_use_tls=yes
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_cert_file=/etc/ssl/certs/server-rsa.cert
  -o smtpd_tls_key_file=/etc/ssl/private/server-rsa.key
  -o smtpd_tls_eccert_file=/etc/ssl/certs/server-ecdsa.cert
  -o smtpd_tls_eckey_file=/etc/ssl/private/server-ecdsa.key
#
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=smtpd
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#

This works as expected. It actualy works great!

I wanted to secure the port 25 in the same way but it looks like it is imposible as this port has two inbound functionalities i.e. "submission" and "relay recieving" (it is stupid to prolong the life of this port that we should get rid of ASAP).

On port 25 there is only protocol SMTP which does not support mandatory TLS! So for inbound email i.e. "submission" and "relay receiving" all that can be enabled is oportunistic TLS (can be hacked). So all I can enable is a bad "encryption" which can later be enhanced using DANE (can't be hacked easily).

So for port 25 I have hopes for my "encryption" to be sufficient at some point while I don't understand how to set up SASL "authentication"!

I tried using this chunk of code in /etc/postfix/master.cf where 1st part of the code sets up oportunistic TLS the second part of code should set up SASL "authentication".

smtp      inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtp
#
  -o smtpd_use_tls=yes
  -o smtpd_tls_security_level=may
  -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_cert_file=/etc/ssl/certs/server-rsa.cert
  -o smtpd_tls_key_file=/etc/ssl/private/server-rsa.key
  -o smtpd_tls_eccert_file=/etc/ssl/certs/server-ecdsa.cert
  -o smtpd_tls_eckey_file=/etc/ssl/private/server-ecdsa.key
#
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=smtpd
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination
#

Unfortunately, I discovered that line:

  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

on one hand forces clients, who want to "submit" email through port 25, to "authenticate" and on the other hand rejects all the "relay received" email arriving from other MTA!

So how can I achieve both:

• preventing anyone from the internet to "submit" email using port 25 on my server.
• "relay receive" all the email comming from other MTA to my port 25.

Why do administrators mostly use +a alongside +mx in SPF records? This is the example:

@              10800 IN TXT     "v=spf1 +a +mx -all"

Isn't it enough to only use +mx parameter e.g.:

@              10800 IN TXT     "v=spf1 +mx -all"

I thought MX record's task is to send email and not A record's. Can anyone explain the scenario why would anyone use +a then?

On my Postfix server I use port 465 for submission, and port 25 for relay ("relay receiving" and "relay sending"). I use port 993 configured in Dovecot for mail "retrieval".

When I was setting up Postfix I avoided configuring ports 25 & 465 inside /etc/postfix/main.cf which remains simple:

smtpd_banner = $myhostname -------> "HELLO!"
biff = no
append_dot_mydomain = no
readme_directory = no
compatibility_level = 2
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.domain.eu
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
myorigin = /etc/mailname
mydestination = $myhostname, tekpi-eu, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
mydomain = domain.eu
mynetworks_style = host
virtual_mailbox_base = /var/mail/
virtual_mailbox_domains = domain.eu
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailboxes
virtual_gid_maps = static:997
virtual_uid_maps = static:997
virtual_alias_maps = hash:/etc/postfix/virtual_aliases

It seems more logical to individually configure ports 25 & 465 in /etc/postfix/master.cf.

smtp      inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtp
  -o smtp_use_tls=yes
  -o smtp_tls_loglevel=1
  -o smtp_tls_security_level=encrypt
  -o smtp_tls_wrappermode=yes
# -o smtp_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtp_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtp_tls_cert_file=/etc/ssl/certs/server-rsa.cert
  -o smtp_tls_key_file=/etc/ssl/private/server-rsa.key
  -o smtp_tls_eccert_file=/etc/ssl/certs/server-ecdsa.cert
  -o smtp_tls_eckey_file=/etc/ssl/private/server-ecdsa.key
#
  -o smtpd_use_tls=yes
  -o smtpd_tls_security_level=may
  -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_cert_file=/etc/ssl/certs/server-rsa.cert
  -o smtpd_tls_key_file=/etc/ssl/private/server-rsa.key
  -o smtpd_tls_eccert_file=/etc/ssl/certs/server-ecdsa.cert
  -o smtpd_tls_eckey_file=/etc/ssl/private/server-ecdsa.key
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=smtpd
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_use_tls=yes
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_cert_file=/etc/ssl/certs/server-rsa.cert
  -o smtpd_tls_key_file=/etc/ssl/private/server-rsa.key
  -o smtpd_tls_eccert_file=/etc/ssl/certs/server-ecdsa.cert
  -o smtpd_tls_eckey_file=/etc/ssl/private/server-ecdsa.key
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=smtpd
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
...
...
...

AFAIK in /etc/postfix/master.cf:

• commands starting with -o smtpd_ configure inbound connections
• commands starting with -o smtp_ configure outbound connections

Furthermore parameters starting with -o applied after the line below only modify port 25:

smtp      inet  n       -       y       -       -       smtpd

Similarly parameters starting with -o applied after the line below only modify port 465:

smtps     inet  n       -       y       -       -       smtpd

So as you can see I have configured a mandatory TLS on port 25 outbound connections but when I send email to Gmail, message is labeled with a warning saying: "This message wasn't encrypted":

If I inspect email header, there is no sign of encryption in the first Received field:

Delivered-To: [email protected]
Received: by 2002:a50:a414:0:0:0:0:0 with SMTP id u20csp5876423edb;
        Wed, 23 Dec 2020 10:04:30 -0800 (PST)
X-Google-Smtp-Source: ABdhPJz/H6LVTTELjEg4kyxfY5WvBpShW3zeBpEASR/dmz8FHcT8QBpRbaNbCdGaTON4PTFMXVds
X-Received: by 2002:a05:6402:366:: with SMTP id s6mr25548681edw.44.1608746670340;
        Wed, 23 Dec 2020 10:04:30 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1608746670; cv=none;
        d=google.com; s=arc-20160816;
        b=0GELxkiim2MQGGCIrMsuVfXIiuzCbPnx6q6q7Sxuhssnb6XxCc1dtmsdUCVaGorqL/
         NWMA9sBfBZkz2ZCb90AoAk4Tyi1YzYw3WVLblw2+xQkbq+JwuYwdAjEQj2i2EJlBI3Zk
         KyYC2zfZqMkWMNRL27bI6pYwNtRYM7FifUeKmxaGuGuXv+7KY9wkrv9LTGI3a/UN634r
         Mqhog1Em8L8uLys0tDlj9GB08ZO52pPw01vJNU1AXqwOeRVznF9FPwfzP6Pn1drc4cOM
         x2vA5NJ+TgguOhqhgTSMW1hQrhNpyku3bYRW9PKQChZdHMowtSotpldYy1sJCf/VYeuA
         6fGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-language:content-transfer-encoding:mime-version:user-agent
         :date:message-id:subject:from:to;
        bh=ZnLGQleFTlvpbWbWBAKrwartxhkzwpbLw0l/ILVPQLo=;
        b=Lt/88Ansftfa790xIUJbRfnuHWadZtBq5QHPDlDjJeGLBlmrLiyfIlzG5xwZTkqZmY
         XPImCgNHC+JfBDOhTFbiyahI7OMMAJGJAZDrr8K60TCztYqKE4Gkr6SZ7h3nAZVjLE8Y
         QBr0NOHZSQkMac/3WKOU86NtPEJwIu53Is71ucdpvNvwj8U5XHDDK9zUw8rcO9XF9JL+
         VUXTOhHmpEqhFgZDq+ldLANLkML+Ix/qvAnyb6JSss+rfsJO0h3Q2nh/LSQzbTFeWBbq
         oGksWfsCX7L0cfSij1GLWwYJ+1RrT/UBdb9p6OIK7sV2IpzAFmLgdRHoV2XHuB3XYSDy
         8gyw==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 2a01:4f8:211:2a4::2 as permitted sender) [email protected];
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=domain.eu
Return-Path: <[email protected]>
Received: from mail.domain.eu ([2a01:4f8:211:2a4::2])
        by mx.google.com with ESMTP id j10si12321635ejf.404.2020.12.23.10.04.30
        for <[email protected]>;
        Wed, 23 Dec 2020 10:04:30 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 2a01:4f8:211:2a4::2 as permitted sender) client-ip=2a01:4f8:211:2a4::2;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 2a01:4f8:211:2a4::2 as permitted sender) [email protected];
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=domain.eu
Received: from [192.168.64.100] (188-230-147-194.dynamic.t-2.net [188.230.147.194])
    by mail.domain.eu (Postfix) with ESMTPSA id B486F15A1315
    for <[email protected]>; Wed, 23 Dec 2020 19:04:29 +0100 (CET)
To: [email protected]
From: Z L <[email protected]>
Subject: TEST (mandatory TLS): domain --> gmail
Message-ID: <[email protected]>
Date: Wed, 23 Dec 2020 19:04:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US

CONTENT TEXT

There is no sign of encryption also when I send email to myself. Here is an example email source:

Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from [192.168.64.100] (unknown [188.230.147.194])
    by mail.domain.eu (Postfix) with ESMTPSA id 3BE6015A132B
    for <[email protected]>; Wed, 23 Dec 2020 23:03:15 +0100 (CET)
To: [email protected]
From: Z L <[email protected]>
Subject: TEST (mandatory TLS): domain --> domain
Message-ID: <[email protected]>
Date: Wed, 23 Dec 2020 23:03:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US

CONTENT TEXT

Mandatory TLS works on port 465. What did I missconfigure so it won't work on port 25? How can I fix this to have a mandatory TLS or oportunistic TLS on 25 outbound connections?

Problem:

I have a Postfix server with dovecot running. Ports that are listening are 25, 465 and 993 where last two have a mandatory TLS. Other "email" ports are not listening.

This means that client's MUA must use port 465 for email "submission" and port 993 for email "retrieval". This means one function per port (nice).

Port 25 on the other hand has three functions i.e. email "relay sending" email "relay recieving" and email "submitting" (a mess).

Other two ports are already demanding mandatory TLS and now I have to configure port 25 to do that as well. I know that Postfix is used to configure this port as it is SMTP port. I also understand that in /etc/postfix/master.cf I can use -o parameters under the below line to configure port 25:

smtp      inet  n       -       y       -       -       smtpd

We have some embedded devices on the field that can't speak TLS and can only "submit" emails through port 25. This is why this port can use opurtunistic TLS but not mandatory TLS.

I already set up oportunistic TLS for the inbound requests i.e. email "submission" and email "relay recieve" like this:

smtp      inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtp
#
  -o smtpd_use_tls=yes
  -o smtpd_tls_security_level=may
  -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_cert_file=/etc/ssl/certs/server-rsa.cert
  -o smtpd_tls_key_file=/etc/ssl/private/server-rsa.key
#
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=smtpd
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

NOTE:
Parameters starting with -o smtpd_ configure only inbound requests, while parameters starting with -o smtp_ (currently I have none) configure outbound requests.

Question:

Now I am wondering...

• Should I set mandatory TLS for outbound requests i.e. "relay sending" on port 25? What problems could occur?
• What happens if I set mandatory TLS for outbound requests i.e. "relay sending" on port 25 and some destination server does not support mandatory TLS or oportunistic TLS on it's "relay recieving" port 25?
• Is oportunistic TLS what should be set for outbound requests i.e. "relay sending" on port 25 to avoid problems?
• I know that oportunistic TLS is not 100% safe and I know it can be protected using DANE but who exactly DANE prottects? "Relay sender" or "relay reciever"? So should DANE be set for inbound or outbound requests?

I want to get to the bottom of the term email "submission" and "relay". So what does this really mean?

In my head I have two possible scenarios:

SCENARIO 1

What the terms mean is:

• "relaying" ⟹ "event of sending email using SMTP protocol"
• "submission" ⟹ "event of recieving using SMTP protocol"

In this scenario I have to always tell who in the email chain I am refering to.

SCENARIO 2:

What the terms mean is:

• "relaying" ⟹ "event of email passing through any device using SMTP protocol (email is recieved & sent ie. forwarded)"
• "submission" ⟹ "event of sending using SMTP protocol"

So which scenario is correct?

I set the Postfix so that my mailboxes (maildir format) for my virtual users are set like this:

┌───┐
│ # │ root > myserver > ~
└─┬─┘
  └─> ls -l /var/mail/
total 4
drwxr-sr-x 5 postfix postfix 4096 Dec  2 12:27 pistam.eu

┌───┐
│ # │ root > myserver > ~
└─┬─┘
  └─> ls -l /var/mail/domain.eu/
total 12
drwx--S--- 5 postfix postfix 4096 Dec  2 12:10 user_1
drwx--S--- 5 postfix postfix 4096 Dec  1 22:35 user_2

┌───┐
│ # │ root > myserver > ~
└─┬─┘
  └─> ls -l /var/mail/domain.eu/user_1/
total 12
drwx--S--- 2 postfix postfix 4096 Dec  2 12:27 cur
drwx--S--- 2 postfix postfix 4096 Dec 13 15:17 new
drwx--S--- 2 postfix postfix 4096 Dec 13 15:17 tmp

Now I am setting up Dovecot server (IMAPS/SASL) and I want to use one system user that will manage all the mailboxes for all the Postfix virtual users. I saw many articles where administrators create user vmail like e.g.:

# useradd -r -m -d /home/vmail vmail

and they use it as the default Dovecot user by setting these two lines in /etc/dovecot/conf.d/10-master.conf:

mail_access_groups = vmail
default_login_user = vmail

But in my case group postfix has "setuid" bit which means that these folders will always be manipulated by user postfix.

So what is the point in creating user vmail? Why not just using user postfix for Dovecot to do that instead? Are there any risks doing this? There are also these two users that Dovecot installation procedure created:

┌───┐
│ # │ root > myserver > ~
└─┬─┘
  └─> cat /etc/passwd | grep dove
dovecot:x:112:118:Dovecot mail server,,,:/usr/lib/dovecot:/usr/sbin/nologin
dovenull:x:113:119:Dovecot login user,,,:/nonexistent:/usr/sbin/nologin

Why not use one of those? There are also these two hints in the configuration file /etc/dovecot/conf.d/10-master.conf:

# Login user is internally used by login processes. This is the most untrusted
# user in Dovecot system. It shouldn't have access to anything at all.
#default_login_user = dovenull

# Internal user is used by unprivileged processes. It should be separate from
# login user, so that login processes can't disturb other processes.
#default_internal_user = dovecot

Table below shows which protocols/ports could be used in each step of the email transfer. Table also indicates which protocols/ports I want to use on my postfix server setup by marking them with ✘ or ✔.

Before I continue I would ask you to agree or disagree with two of assumptions:

ASSUMPTION A:

I assume from this old answer that Postfix service 465 was renamed to smtps somewhere along the way. Therefore I am using service smtps in order to listen on "mail submission" SMTPS port 465.

ASSUMPTION B:

The top of my /etc/postfix/master.cf file looks like this:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       y       -       -       smtpd
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_security_level=encrypt
  -o smtpd_use_tls=yes
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
  -o smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
  -o smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

  ...

I read here that:

postfix/smtpd - is SMTP daemon process for "incoming mail" and routing it to the appropriate internal location.

postfix/smtp - is SMTP daemon process for "outgoing mail" out to the world.

So now I am assuming that postfix/smtpd is listening on port 465 for "incoming email" from local users and on port 25 for "incomming email" from everywhere else. I am also asumming that postfix/smtp is using port 25 where it sends "outgoing email".

PROBLEM:

When I was configuring Postfix somewhere along the way I disabled an entire TLS section inside /etc/postfix/main.cf because I did not want global settings to mess with my settings for individual services that I set inside /etc/postfix/master.cf.

As you can see I used no -o options for the service smtp while I used a lot -o options for service smtps. What confuses me most is that in the official documentation /etc/postfix/main.cf I can find a lot of almost duplicated options like:

• smtp_tls_protocols
• smtpd_tls_protocols

According to the cited text I should use:

• the ones starting with smtp_ for "outgoing mail"
• the ones starting with smtpd_ for "incomming mail".

If my philosophy is correct, then my current setup should work. It partialy does because I can achieve a TLS 1.3 handshake using openssl command on a different computer like this:

┌───┐
│ $ │ ziga > ziga--workstation > ~
└─┬─┘
  └─> openssl s_client -connect pis.eu:465 -tls1_3

CONNECTED(00000003)
depth=0 CN = tek-eu
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = tekpi-eu
verify return:1
---
Certificate chain
 0 s:CN = tek-eu
   i:CN = tek-eu
---
Server certificate
-----BEGIN CERTIFICATE-----

  < REMOVED FOR CLARITY >

-----END CERTIFICATE-----
subject=CN = tek-eu

issuer=CN = tek-eu

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1286 bytes and written 313 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 45F832A32F5F27CEAA41B271F28545ECA98DC1AC61F51A484123DD28B2535C30
    Session-ID-ctx: 
    Resumption PSK: 3175AD1641D8D77511FD5C76508D339D01F5D1CE02DBF90F33FEBD334A7E76FD44B52808A846C281616469143977B6F1
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:

    < REMOVED FOR CLARITY >

    Start Time: 1607602078
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
220 mail.pis.eu -------> "HELLO!"

Above I used a parameter -tls1_3 that should work because my configuration parameter -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1 should forbid any handshake other thanTLS 1.2 and TLS 1.3. But if change parameter -tls1_3 to -tls1 to try TLS 1 handshake it suceeds!?

┌───┐
│ $ │ ziga > ziga--workstation > ~
└─┬─┘
  └─> openssl s_client -connect pis.eu:465 -tls1
CONNECTED(00000003)
depth=0 CN = tek-eu
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = tek-eu
verify return:1
---
Certificate chain
 0 s:CN = tek-eu
   i:CN = tek-eu
---
Server certificate
-----BEGIN CERTIFICATE-----

  < REMOVED FOR CLARITY >

-----END CERTIFICATE-----
subject=CN = tek-eu

issuer=CN = tek-eu

---
No client certificate CA names sent
Peer signing digest: MD5-SHA1
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1385 bytes and written 227 bytes
Verification error: self signed certificate
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: C1E39786A475DA48ED222EAB5247CCE57D49875AE9A442A73027FBE1F9BB7C4D
    Session-ID-ctx: 
    Master-Key: 5900F37B79A7949871008A827904F2BA907F42EE8BBC73328CD49DF7E37AF2687C06B316922D7D76DDC36FA1DF912E7A
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:

    < REMOVED FOR CLARITY >
    
    Start Time: 1607602884
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: yes
---
220 mail.pis.eu -------> "HELLO!"

How come that this suceed? What am I doing wrong? Curently my setup only has -o smtpd_ options. Should I also use -o smtp_ options? Where should I put these?

As you see I am confused...

RFC standards literally force us to accept unencrypted connections on port 25. To understand why, we have to understand how emailing works. But emailing is quite a complex topic and I created this example together with a table to try and understand everything.

Can anyone read and tell me if I am wrong in any part of the explanation? Because I am not quite sure if my understanding of the topic is correct.

EXAMPLE

When user (sender) sends email through "mail user agent" (MUA), this email is immediately transfered to the "mail submission agent" (MSA) which is or isn't on a separate machine. MSA preprocesses the email and hand it over to "mail transfer agent" (MTA) on the same machine. MTA (sender) then uses DNS and determines to which MTA (receiver) email should be sent. This portion of the transport is only done over port 25. When the MTA (reciever) gets the email, it handles it over to the MSA on the same machine and then user (receiver) can read the email using MUA.

Communication between MUA & MSA and MSA & MTA can use secure ports but connection betweem MTA & MTA can't. Table below shows which protocols are used or can be used and which ports can be used for each step of the above example. We also use ✘ and ✔ where there is a choice to indicate what a modern setup should use.

I read here that iptables package is part of the Linux Kernel and that every GUI firewall tools are in the end translated in some kind of iptable rules.

Now I am setting up Centos 8 server folowing this guide which sets up firewall settings using these lines:

sudo firewall-cmd --zone=public --permanent --add-service=http
sudo firewall-cmd --reload

Prior to this I could not visit my index page /var/www/html/index.html using http://xxx.xxx.xxx.xxx/index.html in my browser. But after this I could visit the site.

I was surprised that there was nothing appended to any of the three chains inside iptables table. In other words table was completely empty:

[ziga@localhost ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

[ziga@localhost ~]$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

It looks like firewall-cmd is doing something I don't understand and I want to avoid this. Is there a way to achieve exactly the same result that firewall-cmd by only using iptable commands?