How important to uncomment "submission" and "smtps" lines in /etc/postfix/master.cf ?
says this:
> …uncomment the two lines [of master.cf] starting with submission and smtps.
I have ran a Postfix server for years without doing this. It seemed to be running fine. I didn't get any complaints from mail server checkers out there.
But to be sure, I thought I'd ask: was not uncommenting these lines a bad idea? What could the consequences have been?
10 Replies
smtps
Edited: last sentence was worded incorrectly and stated the opposite of what I meant. Should be clearer now.
@Vance:
Uncommenting these "submission" line instructs Postfix to listen on port 587 for mail submission. If you don't have users submitting mail from outside the server, then this is not a problem. Uncommenting the "
" line prevents Postfix from listening on port 465 for mail over TLS, but this is not generally used since STARTTLS is widely supported. smtps
As always, thanks for your replies. Not sure what I'd have done without you here over the years. Much appreciated.
To make sure I'm understanding you right (I believe you may have written your words in a hurry so some of it sounded incorrect, but I could be mistaken):
* Uncommenting "submission" as shown in the guide turns on Postfix listening on port 587.
- Uncommenting "smtps" as shown in the guide turns on Postfix listening on port 465.
Please correct me if I'm wrong.
* Are you able to explain, the way you see it, the differences between ports 25, 587, and 465?
The answers at
don't explain everything to me.
First of all, I am actually able to do [plain SMTP] + [STARTTLS] on all three ports using the tool https://github.com/drwetter/testssl.sh
So I don't see the real difference between these three ports yet. I "just don't get it", as they say.
Furthermore:
There are three things that my linode's Postfix does:
4. Receives emails from other email servers when people on my linode are receiving emails.
Accepts emails from desktop email clients that people on my linode wish to send to others.
Sends the emails mentioned in point 2 above to other email servers.
What I still do not know is this:- * Which of the three ports are used in the above three scenarios?
@dee4:
* Uncommenting "submission" as shown in the guide turns on Postfix listening on port 587.
- Uncommenting "smtps" as shown in the guide turns on Postfix listening on port 465.
This is correct. The "submission" and "smtps" are names that can be used in place of port numbers. If you look at /etc/services, you will see a whole long list of these names and the ports to which they correspond. Postfix, and many other programs (but not all) recognize the names in /etc/services. For example, telnet bar.example.net smtp would attempt to connect to port 25 on bar.example.net.
@dee4:
Are you able to explain, the way you see it, the differences between ports 25, 587, and 465?
Port 25 has been used for many, many years for exchanging mail. All connections are initially plaintext, but can be upgraded to an encrypted connection if both sides support STARTTLS. You can test this as follows, assuming your Internet provider does not block connections to port 25 (very many do):
$ telnet bar.example.net 25
Trying 4.3.2.1...
Connected to bar.example.net.
Escape character is '^]'.
220-bar.example.net ESMTP Sendmail 8.14.4/8.14.4
220 Keep your spam, please. We don't want it.
EHLO foo.example.org
250-bar.example.net Hello foo.example.org [5.6.7.8], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE 5242880
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
QUIT
221 2.0.0 bar.example.net closing connection
Connection closed by foreign host.
In this test, the EHLO and QUIT lines are commands I typed. In response to the EHLO, the server responded that it supports STARTTLS. You'll also note that it supports AUTH, which means that one could authenticate with a username and password when sending a message.
According to the Wikipedia entry
Port 587 is intended for mail submission. Distinct from relaying, where a mail server simply hands a message off to another that it thinks is an appropriate destination, some additional assumptions (delineated in RFC 6409
* Port 587 is only used by desktop email clients to send emails to my mail server (the desktop user's end being to send emails to others). Port 587 is never used for anything else.
Port 25 can, like port 587, be used by a desktop email client to send emails to my mail server (the desktop user's end being to send emails to others). But port 25 is also used by a mail server to send emails to another mail server.
Finally, port 465 (although deprecated) is, like port 25, used by a mail server to send emails to another mail server. It is never used for anything else. Update: No, I believe I was wrong. Seems like 465 is also only for submission like 587. If I only use recent email clients, I should block this port entirely.
And finally, of course: Getting new emails by desktop email clients is done through IMAP/Dovecot on port 993 which has nothing to do with Postfix.
Is all of this correct, or are there still some holes in my understanding?
Configuring things using Linode's guide, port 465 doesn't end up like a real SSL end-point. It behaves just like SMTP + STARTTLS – just like 25 and 587.
This confuses me.
On the other hand, there is a smtpdtlswrappermode that I can set to yes only for port 465 (smtps) within Postfix's master.cf file. Doing this seems to turn it into a genuine SSL endpoint. Do you recommend I do this?
@dee4:
Port 587 is only used by desktop email clients to send emails to my mail server (the desktop user's end being to send emails to others). Port 587 is never used for anything else.
Correct. (Although it doesn't necessarily have to be a "desktop" client; for example, postfix is capable of acting as a client
@dee4:
Port 25 can, like port 587, be used by a desktop email client to send emails to my mail server (the desktop user's end being to send emails to others). But port 25 is also used by a mail server to send emails to another mail server.
Also correct. The normal configuration for postfix should only allow relaying from trusted machines (permitmynetworks) or from clients that have authenticated with a username and password (permitsasl_authenticated), no matter which port the mail comes in via. As I previously noted, many (most?) ISPs block outgoing connections to port 25, so if you have clients sending mail through your server you should definitely enable port 587.
@dee4:
Finally, port 465 (although deprecated) is, like port 25, used by a mail server to send emails to another mail server. It is never used for anything else. Update: No, I believe I was wrong. Seems like 465 is also only for submission like 587. If I only use recent email clients, I should block this port entirely.
I honestly don't know. You'd probably have to research this a bit to see whether it was intended for server-to-server connections. My opinion (which is largely uninformed) is that unless you specifically have clients which need port 465, don't bother with it.
@dee4:
Configuring things using Linode's guide, port 465 doesn't end up like a real SSL end-point. It behaves just like SMTP + STARTTLS – just like 25 and 587.
This doesn't make sense to me. If you were going to just offer STARTTLS, then port 25 is just fine. The only logical reason to use a separate port is if it is TLS only. The postfix TLS README
@dee4:
And finally, of course: Getting new emails by desktop email clients is done through IMAP/Dovecot on port 993 which has nothing to do with Postfix.
Also correct. I can't really help much with Dovecot questions. :-)
@dee4:
And one other thing that confuses me is port 465.
Configuring things using Linode's guide, port 465 doesn't end up like a real SSL end-point. It behaves just like SMTP + STARTTLS – just like 25 and 587.
The key is understanding that ports 25 (smtp) and 587 (submission) listen "in the clear" and use the STARTTLS command to turn on SSL encryption, while port 465 (smtps) listens using SSL from the start and so doesn't need STARTTLS. 465's been obsolete for it's original purpose (an alternative to port 25 for encrypted server-to-server transfer) for a long time, but it's been repurposed as an alternative to 587 for old mail clients that can use SSL but that don't support the STARTTLS command. Since all modern mail clients do STARTTLS just fine, 465 isn't normally needed and can be left disabled. If you hit old mail client software that just refuses to work with 587, turning on 465 and telling the client to use SSL and port 465 for outgoing SMTP is a last resort.
If you follow the Linux guides and the default settings in master.cf, the ports are:
25 - listens in the clear, supports STARTTLS. Used for server-to-server mail transfer, doesn't support the authentication needed for mail clients to use it.
587 - listens in the clear, supports and requires STARTTLS, supports and requires authentication. Used for mail clients to submit outgoing mail.
465 - listens using SSL, always encrypted, supports and requires authentication. Used for mail clients to submit outgoing mail. Not needed unless you have to support very old mail client software.
@tknarr:
@dee4:465 - listens using SSL, always encrypted, supports and requires authentication. Used for mail clients to submit outgoing mail. Not needed unless you have to support very old mail client software.
I use Evolution and Android clients but as long as it's available I plan to continue to use 465. "listens using SSL, always encrypted, supports and requires authentication" sounds really good compared to "listens in the clear and …".
@diltonm:
@tknarr:
@dee4:465 - listens using SSL, always encrypted, supports and requires authentication. Used for mail clients to submit outgoing mail. Not needed unless you have to support very old mail client software.
I use Evolution and Android clients but as long as it's available I plan to continue to use 465. "listens using SSL, always encrypted, supports and requires authentication" sounds really good compared to "listens in the clear and …".
I use port 587 with TLS/STARTLS required. Once given the mail server name, Android and iOS clients detect the port & encryption and work just fine.