Eduardo Júnior wrote:
So, SMTPS (465/tcp) is deprecated and I can remove this line from my master.cf
I actived submission (587/tcp) and I ask:
For my experience, this would useful only to users to send messages (a
dedicated daemon) and port 25 (other SMTP daemon) to receive mail from
others servers, correct?
What the real beneficit after that?
I already have TLS actived in my SMTP daemon and the submission only
would alter the port to connect?
Both submission and smtps are intended for use by your own
authenticated users. You only need smtps if you have users
with a client that can't use submission - generally older
versions of Outlook/OE, and some (current) mobile devices.
"smtps" must run on a separate port because it's incompatible
with normal SMTP. This happened before the current standard
STARTTLS command was invented.
Some ISPs block port 25 access to "home" users. If your user
happens to be on such an ISP, they need an alternate to port
25 for submitting mail. This is the intent of the submission
port.
Also, separating user submissions from general internet
traffic allows you to easily apply different policies to the
different classes of traffic.
My submission is the default:
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
This is fine. It rejects any unauthenticated client.
You might want to explicitly add
-o smtpd_delay_reject=yes
in case someone unwisely changes the default in main.cf, never
giving the user a chance to authenticate.
Some people like to explicitly set all the
smtpd_*_restrictions on the submission entry so that main.cf
parameters don't interfere with submission port settings.
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=
-- Noel Jones