I just created my first Linode and I can’t send emails. Why? (Mailing ports 25, 465, and 587 blocked by default)

Linode Staff

In an effort to fight spam, new Linode accounts created after Tuesday, 5 November, 2019 have mailing ports (25, 465, and 587) restricted by default (see our blog post here for more information).

If you've recently signed up and need to send email, please open a ticket from the Cloud Manager and provide us with the following information:

  • Your name.
  • Your business or company name, if applicable.
  • A clear and detailed description of your email use case. Please include a description of how you'll avoid sending unwanted emails.
  • The domain(s) that will be sending emails.
  • Links to public information (e.g. your business or application's website, Twitter profile, GitHub, etc.)

Customers who need to send email from more than one compute instance may be asked to provide additional details. It may take up to 72 hours for us to review your request.

46 Replies

This is good news! 👍

Does the A record have to be hosted on Linode's DNS manager or can it be hosted elsewhere as long as it and the rDNS match?

You won't need to use Linode's DNS Manager if you prefer to use your registrar or a third party service. We can verify your records using commands like dig and dig -x to ensure they match up. You can read more about these methods here.

The title of this post is misleading and almost caused me to skip it. It should be called "Mailing ports (25, 465, and 587) blocked by default". Also, this is a major change that might have gone out as a special notice to us. I will defer further comment to the appropriate places.

Hey @LenAyers,

Thanks for taking the time to let us know about your experience with this Community Post. It really helps us make sure that we're getting the information where it needs to go effectively.

At your request, we edited the title of this post to clarify.

Please let us know how else we can help out!

Sincerely,
Tara T
Linode Support Team

At first glance, it might not be obvious whether the message is about incoming or outgoing mail traffic.

Consider this opening statement:
Beginning Tuesday, 5 November, 2019, in an effort to fight spam, outgoing mail traffic from new Linode accounts with destination ports 25, 465, and 587 are restricted by default (see our blog post here for more information).

Regards,
jk04

@jyoo What information is needed if I prefer to use my own registrar, when i send a request to support to unblock the ports?

@jk04 --

You write:

At first glance, it might not be obvious whether the message is about incoming or outgoing mail traffic.

If port 25 is blocked, that means transfer of email is blocked (in both directions). If ports 587 & 465 (submission, clear/TLS respectively) are blocked, you won't be able to send email.

Note that, since port 25 is blocked, the status of the post-office protocols (pop3 & IMAP) on clear/TLS ports 110/995 (pop3) and 143/993 (imap) are inconsequential (although, a well-known spammer trick is to try to send mail by direct delivery to an imap server on ports 143/993).

-- sw

Depending on how Linode blocks email ports, you may not be able to send email at all. If Linode blocks all the mail ports on localhost, then no email will flow, period. If not, your php(1) apps will be able to send email to other users on your Linode only.

The Linode folks are pretty smart. I would guess that they only block extra-Linode mail (mail originating from or destined to addresses outside the Linode) and that they leave localhost alone.

-- sw

The Linode folks are pretty smart. I would guess that they only block extra-Linode mail (mail originating from or destined to addresses outside the Linode) and that they leave localhost alone.

I’m pretty sure they just firewall off the ports externally to the Linode rather than inspecting the traffic for destination addresses, or running anything on the Linode itself to block it.

Therefore any mail traffic that doesn’t leave the Linode won’t be affected.

@andysh --

Just to be pedantic, ports are neither internal nor external…they just are. Addresses are internal and/or external.

-- sw

Just to be pedantic, ports are neither internal nor external

Yes I know. I meant external in the context that the traffic to these ports is blocked externally to the Linode (i.e. it’s a separate firewall device that checks what addresses are allowed to send traffic to the SMTP ports and blocks any that haven’t yet been allowed.)

As opposed to a firewall or something blocking the traffic on the Linode itself.

My point being that SMTP traffic destined for ‘localhost’ will not leave the Linode and thus not likely to be blocked as it never hits the external firewall.

@andysh --

I knew that you knew that. In Linux and most Unix implementations (i.e., those with networking based on BSD -- Free/Net/OpenBSD, NeXTStep/Darwin, SunOS/Solaris, HP/UX etc.), traffic internal to localhost short-circuits the network stack for better performance. Ditto for local-domain (neé Unix-domain) sockets…

Also, notes to the OP… If you are doing something really simple, it’s pretty easy to write a server that handles SMTP and IMAP yourself (even in PHP if you like) so that you don’t even need a production-grade email system like postfix(1)/dovecot(1)… Such a beast would have really good performance and no security worries because traffic never leaves the Linode (esp if it used local-domain sockets). It wouldn’t need DNS either.

If I was doing what I think you are trying to do, this is the approach I’d take. I did something similar in Ruby once… Make sure you use open-source components so you can modify the networking interface to suit your needs.

I would add here, that you wouldn't have to use SMTP to accomplish your goals. This can be entirely done with HTTP & PHP…get creative. If you're stuck on using SMTP, you don't have to send the email to a server operated by you…you could use gmail.com. That will certainly be easier to set up and maintain than a production email server without DNS!

-- sw

I would say it's good to fight SPAM.

It would be better if Linode default whitelist certain well-known 3rd party SMTP gateways. For example "email-smtp.us-west-2.amazonaws.com:587" for Amazon SES service.

I mainly use Amazon SES for email because of reliability. After I moved my website to linode, I found that all the email can't be send because Linode blocked my server connect to Amazon SES gateway. Now I have to open a ticket and wait for unblock, not a smooth experience overall.

@kam --

You write:

It would be better if Linode default whitelist certain well-known 3rd party SMTP gateways.

You would NOT BELIEVE how much spam I block on a daily basis that emanates from certain well-known 3rd party SMTP gateways.

While Linode is at it, maybe they should whitelist smtp.Агентство.Интернет-исследований.ru too…

-- sw

Using Linode for Webhosting I really need open Ports. I asked the support to let me at least whitelist some Accounts to send emails to, like my own account. They refuse to open my ports and ask me that I try again after having a three months billing history.

@gnuion writes --

I asked the support to let me at least whitelist some Accounts to send emails to, like my own account. They refuse to open my ports and ask me that I try again after having a three months billing history.

Hey Linode folks…

Is this a new policy or a special case with extenuating circumstances?

-- sw

Hey @stevewi - that has been the policy for some time, and something that is also in place to help deter spam. However, this is not set in stone - when a customer requests SMTP port access we review the account in full and make a decision from there, regardless of billing history.

@jtoscani --

I was specifically referring to the billing history. I knew about the blocked ports… It sounds like @gnuion's situation wrt billing history may have been a special case…

-- sw

Does this mean that I need to at least have a domain name to unblock sending emails?

I'm only using a gmail account and gmail's smtp for development purposes.

I'm sorry if the answer might have been too obvious. I'm still a newbie.

@johntestdev --

You write:

Does this mean that I need to at least have a domain name to unblock sending emails?

No, but if you connect to Gmail using some app that uses ports 25, 465, or 587, you'll need the ports to be open on your Linode…at least port 587 (port 587 is submissions -- submission with TLS). Gmail does not support port 465 (submission with SSL) anymore.

In order to do TLS, you'll need to acquire a certificate that Google likes. For that, you'll probably need a domain name. If you don't want to buy your own domain name, you can probably use the Linode hostname (membersXXXXXX.linode.com).

-- sw

sorry for upping old thread, I just open ticket support to open mailing ports, but from @gnuion post, it seems this support ticket was a hit and miss, sometimes approved, sometimes not. I don't want to create my own mail server, my app only act as smtp client to another mail provider. I hope linode admin approve my ticket. If fails I have to find other place :(

I understand why port 25 is blocked, but not the reason behind 465 and 587.
No mail server accepts unauthenticated mail on port 465 and 587. So they cannot be used for spamming . The whole reason they are in use, so that ISP's, hosters can block port 25.
If someone ( from a Linode server ) sends spam for example through an ESP and port 465, then the ESP is responsible for the spam, and not Linode ( they are the last hop, and do to auth they know who is sending the mail , they can rate limit etc).
Blocking 465/587 kinda defeats the purpose of blocking 25. Now everybody will ask for unblocking all mail ports, even if they want to send a couple mail through an ESP, so port 25 spam is possible.

@sandormarton --

You write:

No mail server accepts unauthenticated mail on port 465 and 587. So they cannot be used for spamming.

This is not true. Ports 465 and 587 are for encrypted submission of email. Authentication happens after encryption is set up. It is possible to submit properly encrypted email that is from an unauthenticated user. As you can see from this log, encryption happens BEFORE authentication (as it should):

  • Connect
Mar  9 06:39:03 myserver postfix/submission/smtpd[3767]: connect from unknown[<redacted>]
  • Set up encryption
Mar  9 06:39:03 myserver postfix/submission/smtpd[3767]: Anonymous TLS connection established from unknown[<redacted>]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
  • Authentication
Mar  9 06:39:03 myserver postfix/submission/smtpd[3767]: B908020086: client=unknown[<redacted>], sasl_method=PLAIN, sasl_username=stevewi@mydomain.com
  • Disconnect
Mar  9 06:40:03 myserver postfix/submission/smtpd[3767]: disconnect from unknown[<redacted>] ehlo=2 starttls=1 auth=1 mail=1 rcpt=3 data=1 quit=1 commands=10

Whether the mail server does authentication or not is a matter of server configuration. Your implication seems to be that no one in their right mind would (or should) do this (and I agree) but it is possible.

For example, here's the configuration of submission and smtps in my postfix(1) configuration file /etc/postfix/master.cf:

submission inet  n       -       y       -       -       smtpd
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o syslog_name=postfix/submission
...
smtps      inet  n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

If I change permit_sasl_authenticated,reject, to permit_any or permit_mynetworks,reject, submitted email will be properly encrypted but the entity submitting the email is not authenticated at all.

This is a simplistic example…in reality there are a few more configuration settings that in /etc/postfix/main.cf that need to be changed as well. However, that's not the point of this exercise…

-- sw

For those having using providers such as SendGrid, mails can also be sent using the API instead of SMTP.

I reckon the API uses port 443.

I was able to send out emails using the SendGrid API after some failed attempts with the SendGrid SMTP.

Patrick

@stevewi
That doesn't matter, since neither port allows unauthenticated mail by default. Also i don't know any common mail provider, which allows unathenticated mail on port 465 or 587 .
submission of email means accepting a mail for outgoing messages ( "The term "Mail Submission Server" refers to a server for the protocol specified in [RFC6409] (or one of its predecessors or successors) for submission of outgoing messages for delivery to recipients." ) , yes, it could be done without auth but nobody is doing it ( since 465/587 is used only by your users )
I could setup any port to receive submissions, does that mean Linode should block these ports aswell ?

I could setup any port to receive submissions

Sure…you could try to do that…then, all you'd have to do is get every other MTA/MUA in the world to talk to your server on your custom ports. Your proposition is Stallman-grade nonsense.

does that mean Linode should block these ports as well?

The default block of ports 25/465/587 on new Linodes is a Linode company policy. You can debate the merits all you want but it comes down to this: to play in Linode's sandbox, you must play by Linode's rules. If you don't like the rules, find another sandbox…or start your own. Engaging in such debate is less than pointless…

-- sw

@stevewi

Sure…you could try to do that…then, all you'd have to do is get every other MTA/MUA in the world to talk to your server on your custom ports.

I don't understand your logic. Your mail servers regularly get mail from other MTA's over submissions ports ?
I didn't mean to setup the custom port to receive email from all over the globe. I meant i could setup a remote server, at another provider, on a custom port, then relay the mail from my linode server to that server&port .

I'm aware that is a Linode policy. That doesn't mean that it can't be changed, especially if we request it . The thread was started by them, my reply was kind a suggestion, not a debate starting.
The change would be good for Linode too, since would reduce support load, without giving up the spam fight .
And just to make clear, i'm for blocking port 25. But i consider blocking ports 465 and 587 a mistake.

Linode says they lifted all restrictions on my account, but still the port 25 is blocked.

I'm not using a firewall, tried IPtables, but still blocked.
I don't know what else to do…

@inmobiliarialima I'm having the same problem, they say that port 25 is open, but it's not, I've tried to unlock it through iptables and nothing

Solved

First run the command

netstat -tunlp | grep 25

I didn't get any response, it means the port was still blocked even after releasing in linode firewall and iptables

After a lot of searching, I found an article that said to change the postfix master.cf file, so I did.

vi /ect/postfix/master.cf

Change

 587 inet n - n - - smtpd

for

 smtp inet n - n - - smtpd

restart postfix

 service postfix restart

check status

 service postfix status

See if port 25 appears open

 netstat -tunlp | grep 25

You should now be able to send and receive emails

@inmobiliarialima

Change

587 inet n - n - - smtpd

for

smtp inet n - n - - smtpd

Actually, this is incorrect. Port 587 is submission. The correct entry in master.cf is:

submission inet  n - n - - smtpd

to which I add the options:

  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o syslog_name=postfix/submission

The first forces submitters to authenticate before postfix will accept email. Unless you absolutely love spammers, this is a really good idea™. The second sets postfix/submission as the label for log entries…makes it easier to spot errors in mail.log.

It's not a good idea to use port 25 for email submission. First, port 25 is for server-server email relay. Second, port 25 can't be secured (it's the nature of the beast).

-- sw

Thanks for your answer @stevewi I don't know much about email settings, the answer I mentioned above was well upvoted on the forums so I implemented it.

Nobody really likes spammers

In postfix configuration I have:

smtp inet n - n - - smtpd

submission isset n - n - - smtpd

and

  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

  -o syslog_name=postfix/submission

Enabled.

I tried to comment out #smtp but I stopped receiving emails so I had to enable it again.

You have

submission isset n - n - - smtpd

This should be

submission inet n - n - - smtpd

 

I tried to comment out #smtp but I stopped receiving emails so I had to enable it again.

You need both.

smtp inet n - n - - smtpd

causes postfix to listen on port 25 for server-server relay emails.

While

submission inet n - n - - smtpd
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o syslog_name=postfix/submission

causes postfix to listen on port 587 for email submissions. There are no blank lines in this group of commands.

-- sw

I changed the postfix settings to the ones mentioned above by you, everything continues to work normally, thanks!

@stevewi Do you still require port 25 if your server accepts incoming email?

Yes.

  • port 25 is smtp (unencrypted)
  • port 465 is ssmtp (encrypted)
  • port 587 is submission (usually encrypted).

If your server relays mail, it will contact the upstream and downstream servers using port 25. If you don't want to use ssmtp port 25 will be required.

It's best to have all three…unless you're developing your own mail server and can dictate the policy about port usage, you don't have any idea about which ports the server will use and when.

-- sw

This policy really needs to be on the network tab or something, without needing to come digging into the help centre or forums… I just spent hours trying to work out why emails weren't sending without there having been a clear indication that the ports were blocked, and only after completing all possible troubleshooting for faults in our setup did I then come to the help centre to find out it was all pointless work…

I understand the reasons, don't have an issue with the policy, just disappointed it's not immediately noticeable when installing, for example, a cPanel instance. Perhaps a warning when installing anything from the Marketplace that by default uses the ports (eg. cPanel, Plesk, etx) so that you know the request needs to be made…?

Food for thought. Even though I agree with the policy, because of how much time I just wasted because of it being less obvious, I'm probably going to move elsewhere to somewhere that's a bit more user-friendly in that respect.

second that completely!
what a useless waste of time..

This policy really needs to be on the network tab or something, without needing to come digging into the help centre or forums… I just spent hours trying to work out why emails weren't sending without there having been a clear indication that the ports were blocked, and only after completing all possible troubleshooting for faults in our setup did I then come to the help centre to find out it was all pointless work…

This is to confirm that Linode, on demand, opening Mailing ports 25, 465, and 587 was successful in our case. Thanks Linode :)

For those who need to send and or receive emails, but somehow are presently not available to do the very complex configuration of a modern email server, or if it is presently not realistic for you to hire someone to configure it for you, I suggest continuing using Linode for all your hosting needs, but use another supplier only for your emails. Then connect both using your DNS A and MX records. So that you are able to continue enjoying Linode services. While at the same time, your emails are not block.

My favourite suppliers for email services are https://mailbox.org/en/ and https://posteo.de/en


Below is the same message as above. But with details if you're interested in those.

The main difference between Mailbox.org and Posteo.de is that Mailbox.org offers both Business and Personal plans. In comparison, Posteo.de offers only Personal plans. Mailbox.org Business plans are located at https://mailbox.org/en/business-mail#business-tariffs

Mailbox.org have been operating e-mail accounts for more than 20 years and are a highly reliable service provider.

Below is my review of Mailbox.org's email services

Strong Security & Privacy:

Features:

  • E-mails, calendars, contacts, tasks, word processing, and file sharing
  • Attachment size up to 137 MB
  • 2 to 50 GB storage space for e-mails.
  • Up to 100 GB storage space for documents and photos
  • Both the Standard and Premium plan are quickly & easily extendable within the same plan. Up to 250 GB for email storage, per email account. And 1,000 GB for cloud storage, per cloud storage account. Also, the Premium extended GB are half price than the Standard extended GB.
  • Smartphone synchronizing for contacts, calendars, etc.
  • Consistent encryption with SSL/TLS and GPG
  • Reliable spam and virus protection
  • User-defined filters, forwarding, and automated vacation responses
  • Completely ad-free, no analysis of user data
  • Compliant with German data privacy regulations
  • 2 server centres located in Berlin, Germany
  • Green hosting with green power

I do not have a conflict of interest with Mailbox.org I am a Linode client. Who is very happy with their services. But at Ubertus.org, for some of our clients, it's not realistic for them to install, configure, and maintain their own email service. The above suggested resolution was very successful.

Francois Carpentier (Francewhoa)

that completely!

This policy really needs to be on the network tab or something, without needing to come digging into the help centre or forums… I just spent hours trying to work out why emails weren't sending without there having been a clear indication that the ports were blocked, and only after completing all possible troubleshooting for faults in our setup did I then come to the help centre to find out it was all pointless work…

I am new to Linode, my domain is hosted at godaddy and I just purchased a linode to run my own mail server. One of the key requirements is for me to be able to send emails out. If I log a ticket, will Linode opens up port 25,465,587 to allow my linode to send emails out?

This policy really needs to be on the network tab or something, without needing to come digging into the help centre or forums… I just spent hours trying to work out why emails weren't sending without there having been a clear indication that the ports were blocked, and only after completing all possible troubleshooting for faults in our setup did I then come to the help centre to find out it was all pointless work…

Same. What an absolute waste of time. I was able to find out about this only through Google after seeing that a site I moved to Linode is not able to send emails. I was planning on using Linode as the infra for a WordPress-related SaaS hosting project. Seeing how you can't even use the Google Apps mail that you pay $5 per head for because port 465 is also blocked is just surreal. Moreover, they want you to post a support ticket for every single domain that will need to send email - so no multi-tenant hosting at Linode infra, either on Linodes or in Kubernetes. You'd have to open a ticket for each and every one of your website/saas customers.

I contacted them to get them to enable port 465 for one single site while I look for somewhere to move the clients to.

@Codebard I'd be happy to clarify any misunderstanding. It is not necessary to open a SMTP restriction removal ticket for each domain on your account. We'd be happy to review a request for account wide removal. If the account is in good standing or has at least 3 months of positive billing, request approval is more likely. That being said, this is on a case-by-case basis and we can provide you with more account specific guidance in a Support Ticket.

@rdaniels Yes, that's what I suspected from the support ticket that I posted - you don't need to open a ticket for each domain/account. That would have been a GDPR liability with the private information that the original post says that's required. It seems that you need to open a ticket about your own business and domain, not your clients' businesses. Thanks for confirming that - the support ticket did not make it clear.

Account-wide removal with good standing over time seems to be more in line with others' policies (like Digitalocean) so it does look like it's workable.

Thanks for the clarification. It would be very good if the original post has been edited to reflect the actual policy though.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct