Postfix - force port 587

I have Virtualmin installed on a Debian 10 Vultr VPS.

I am trying to get email set up. Vutlr blocks port 25, which is fine, since I want to use 587/465 anyway.

I’ve created a LE certificate and “copied to Postfix.”

I found a Virtualmin SMTPS guide that indicates that it should “just work” after copying to Postfix (I restarted Postfix for good measure).

Every email I send, though gets sent via Port 25 and therefore stuck in my Queue (network unreachable, since Port 25 is blocked).

I’m assuming there is more configuration that needs to be done, and I haven’t done anything other than copying the LE cert to Postfix.

The ‘open and free’ internet is standards based, so you cannot force port 587. If what you intend could be done then why would Vultr block just port 25? They would go on to block 587 as well, no?

They want to take your money but they don’t want you to send out unlimited email from their IP address.

However, there is a way forward for you. See Free smarthost / mail relay to work around port 25 block by VPS host

1 Like

Or just ticket Vultr. They are kind enough to open port 25 if you want (unless of course you’ve violated their terms previously).

1 Like

Port 25 is the relay port.
Port 587 is the submission port.
They are NOT interchangeable.
Port 465 is deprecated and should not be used in any case.

If you want to send mail and your host blocks port 25, you have two options:

  1. Use a relay service as @calport advised.
  2. Change your provider.

No, it’s not. Web hosts are businesses selling to other businesses. Blocking a port needed for communication would be like the telephone company telling you that you can have a handset, but no line; or the electric company telling you that you can have a light bulb, but no socket for it.

My answer to your problem would be to find a better host.

Part of the problem is that many hosting companies want to automate everything, so literally anyone can open an account with no human intervention. The host I use doesn’t. They manually verify a new client’s identity, address, and business license, and require a business credit card, before activating the client’s first server. But they don’t block any ports.

They made an exception in my case because they were aware of the meltdown that was going on at HFW: but only after a senior support tech interviewed me over the phone, decided I sounded legit, and checked the reputation of the IP on the server I was leaving. They let me migrate overnight (on Christmas Eve!), and do the paperwork the next business day.

I would run – not walk – away from any hosting company that blocked any service port. But I guess that’s just me, because there are many companies that do.

Richard

I somewhat agree, but at the same time most of the major players in the game do this.
And to be fair, if you could pay $0.02 to have a server for a couple of hours, blasting spam left & right without any consequence whatsoever, I feel that would be A LOT worse.
This is a fine approach to combat this problem and a ticket takes 1 minute to submit. They answer really fast and the closed port is no more.

If that’s the case, then it’s acceptable. I’m talking about the companies that won’t open it in any case. That’s simply unacceptable.

Richard

Well, that I agree on. Fortunately in most situations it’s only a ticket away, like f.ex. DO, Vultr, AWS and so on.

Back when I was working at a small town ISP we closed port 25 for all our consumer customers.
We only had 3-4k customers and even then several times per week we would have some moron who clicked a pop-up, got their computer infected and started sending spam.
After a while we found it easier to close it by default and those who had a legitimate reason to open it, we would put on a static IP range instead that had no restrictions.

This is slightly off topic, but still relevant as to WHY this is becoming more and more common practice. :slight_smile:

1 Like

I think I will just open a ticket with Vultr, for the time being. This is basically just a learning experiment for me, not really a production environment.

As I understand it, though, emails should be sent out 587, anyway…

Okay, in that case, I think you might find the whole process by which mail gets from your device to the recipient’s device interesting. This Wikipedia article isn’t a bad introduction.

In all honesty, if you read and understand that article, you’ll know more about email than a lot of people I know in this business (including more than a few who work support). It’s not rocket surgery, mind you. But most people don’t bother taking the time to learn. You apparently are one of the exceptions. That’s a good thing.

For my part, Postfix still baffles me because I used Exim for many years. But I have enough of an understanding of email itself that I manage to keep the mail moving. Otherwise, I would have farmed it out by now.

Sometimes – most times, really – it helps to have a little knowledge of the theory behind the mechanics.

Richard

1 Like

My is master.cf is below. I copied this from another thread I found, and after restarting Postfix, I still get email sent out of Port 25.

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master" or
# on-line: http://www.postfix.org/master.5.html).
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp	inet	n	-	y	-	-	smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
#smtp      inet  n       -       y       -       1       postscreen
#smtpd     pass  -       -       y       -       -       smtpd
#dnsblog   unix  -       -       y       -       0       dnsblog
#tlsproxy  unix  -       -       y       -       0       tlsproxy
#submission inet n       -       y       -       -       smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628       inet  n       -       y       -       -       qmqpd
pickup    unix  n       -       y       60      1       pickup
cleanup   unix  n       -       y       -       0       cleanup
qmgr      unix  n       -       n       300     1       qmgr
#qmgr     unix  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       y       1000?   1       tlsmgr
rewrite   unix  -       -       y       -       -       trivial-rewrite
bounce    unix  -       -       y       -       0       bounce
defer     unix  -       -       y       -       0       bounce
trace     unix  -       -       y       -       0       bounce
verify    unix  -       -       y       -       1       verify
flush     unix  n       -       y       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       y       -       -       smtp
relay     unix  -       -       y       -       -       smtp
        -o syslog_name=postfix/$service_name
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       y       -       -       showq
error     unix  -       -       y       -       -       error
retry     unix  -       -       y       -       -       error
discard   unix  -       -       y       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       y       -       -       lmtp
anvil     unix  -       -       y       -       1       anvil
scache    unix  -       -       y       -       1       scache
postlog   unix-dgram n  -       n       -       1       postlogd
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# ====================================================================
#
# Recent Cyrus versions can use the existing "lmtp" master.cf entry.
#
# Specify in cyrus.conf:
#   lmtp    cmd="lmtpd -a" listen="localhost:lmtp" proto=tcp4
#
# Specify in main.cf one or more of the following:
#  mailbox_transport = lmtp:inet:localhost
#  virtual_transport = lmtp:inet:localhost
#
# ====================================================================
#
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
#
#cyrus     unix  -       n       n       -       -       pipe
#  user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user}
#
# ====================================================================
# Old example of delivery via Cyrus.
#
#old-cyrus unix  -       n       n       -       -       pipe
#  flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
#
# ====================================================================
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix	-	n	n	-	2	pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

submission	inet	n	-	y	-	-	smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
smtps	inet	n	-	y	-	-	smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may -o smtpd_tls_wrappermode=yes

That’s because mailservers communicate with other mailservers on port 25, you can’t change that.
You can relay via services like Mailchannels, Sendgrid whatever (which is a whole different setup) using other ports, but for sending emails to other servers you will need port 25 to be open, and this cannot be worked around I’m afraid.

Maybe I am missing something, but I can receive email with Port 25 being blocked, no?

Vultr by default only blocks outgoing, so in this case you will still be able to receive.

Okay, that part makes sense. I had Vultr unblock the port (after a bunch of back and forth).

What then, as far as what I configure on the mail server, makes the email traffic go out 587?

Your email client talks to the mail server (technically, the Mail Submission Agent) on port 587.

The mail server (technically, the Mail Transport Agent) talks to other Mail Transport Agents on port 25.

You talk to the server on 587.
The servers talk to each other on 25.

The only place you need to configure 587 is in your mail client; and because it’s the default, you probably won’t even have to do that.

Richard

I used to think closing port 25 was stupid but these days I support the practice. When I had a droplet at Digital Ocean they opened it for me in short time after asking. Vultr will likely do the same once they’re convinced you’re legit and harmless.

You can’t configure the Internet, you can only configure your server. The Internet thinks port 25 is the SMTP port. You aren’t going to convince the Internet otherwise by demanding it or repeating the demand to us here in the forums.

If you can’t send and receive mail on port 25, you don’t have a mail server. That’s not me or Virtualmin limiting you. I also cannot configure the Internet.

Providers blocking port 25 is common, even if we don’t love it. The ones that will open a port on request are much better than the ones that won’t (e.g. Google, Amazon, etc. most of the big cloud providers require you to relay through a third party, or pay for a separate relay or mail service from them).

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.