All outgoing mail stays in mail queue (connection time out)

For days I'm trying to fix my outgoing mail problem. I believe I have seen and tried every possible solution on the internet by now.
This is my last resort 

The issue : All outgoing mails stay in the mail queue (referred) with a connection time out.

I tried disabling the Firewall, ClamAV, AMaVIS, Spamassassin.

I opened ports 25, 465, 10024, 10026

I did some Postfix rebuilds, etc...

This is an example of an email in the /var/log/maillog :

Code: [Select]

Aug 26 14:16:59 p00psc00p postfix/smtpd[435198]: 67FED740213F: client=localhost[127.0.0.1]
Aug 26 14:16:59 p00psc00p postfix/cleanup[435111]: 67FED740213F: message-id=<6465046723fbb34f8cd586083502efd6@c****ge.org>
Aug 26 14:16:59 p00psc00p postfix/qmgr[434249]: 67FED740213F: from=<****@c****ge.org>, size=961, nrcpt=1 (queue active)
Aug 26 14:16:59 p00psc00p postfix/smtp[435112]: 15F337401DDE: to=<red****@proton.me>, relay=127.0.0.1[127.0.0.1]:10024, delay=34, delays=0.07/0.03/0.02/34, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 67FED740213F)
Aug 26 14:19:29 p00psc00p postfix/smtp[435199]: 67FED740213F: to=<red****s@proton.me>, relay=none, delay=150, delays=0.01/0.02/150/0, dsn=4.4.1, status=deferred (connect to mailsec.protonmail.ch[185.70.42.129]:25: Connection timed out)
Aug 26 14:25:43 p00psc00p postfix/qmgr[436451]: 67FED740213F: from=<****@****ge.org>, size=961, nrcpt=1 (queue active)
Aug 26 14:27:49 p00psc00p postfix/pickup[436450]: 481F7740213E: uid=89 from=<****@c****ge.org> orig_id=67FED740213F
Aug 26 14:28:13 p00psc00p postfix/smtp[436454]: 67FED740213F: to=<red****@proton.me>, relay=none, delay=674, delays=524/0.06/150/0, dsn=4.4.1, status=deferred (connect to mailsec.protonmail.ch[185.70.42.129]:25: Connection timed out)
An overview of the related ports
25/tcp     4/-  -     (576800/root)        /usr/libexec/postfix/master -w          /usr/libexec/postfix/master
110/tcp    4/-  -     (449907/root)        /usr/sbin/dovecot -F                    /usr/sbin/dovecot
143/tcp    4/-  1     (449907/root)        /usr/sbin/dovecot -F                    /usr/sbin/dovecot
143/tcp    4/-  1     (598502/dovenull)    dovecot/imap-login                      /usr/libexec/dovecot/imap-login
143/tcp    4/-  1     (599460/dovenull)    dovecot/imap-login                      /usr/libexec/dovecot/imap-login
143/tcp    4/-  1     (599461/dovenull)    dovecot/imap-login                      /usr/libexec/dovecot/imap-login
465/tcp    4/-  -     (576800/root)        /usr/libexec/postfix/master -w          /usr/libexec/postfix/master
587/tcp    4/-  -     (576800/root)        /usr/libexec/postfix/master -w          /usr/libexec/postfix/master
783/tcp    -/-  -     (446611/root)        /usr/bin/perl -T -w /usr/bin/spamd -... /usr/bin/perl
783/tcp    -/-  -     (446628/root)        spamd child                             /usr/bin/perl
783/tcp    -/-  -     (446629/root)        spamd child                             /usr/bin/perl
953/tcp    -/-  -     (601562/named)       /usr/sbin/named -u named -c /etc/nam... /usr/sbin/named
993/tcp    4/-  3     (449907/root)        /usr/sbin/dovecot -F                    /usr/sbin/dovecot
993/tcp    4/-  3     (598502/dovenull)    dovecot/imap-login                      /usr/libexec/dovecot/imap-login
993/tcp    4/-  3     (599460/dovenull)    dovecot/imap-login                      /usr/libexec/dovecot/imap-login
993/tcp    4/-  3     (599461/dovenull)    dovecot/imap-login                      /usr/libexec/dovecot/imap-login
995/tcp    4/-  -     (449907/root)        /usr/sbin/dovecot -F                    /usr/sbin/dovecot
4190/tcp   -/-  -     (449907/root)        /usr/sbin/dovecot -F                    /usr/sbin/dovecot
10024/tcp  4/-  -     (448858/amavis)      /usr/sbin/amavisd (master)              /usr/bin/perl
10024/tcp  4/-  -     (448891/amavis)      /usr/sbin/amavisd (ch3-avail)           /usr/bin/perl
10024/tcp  4/-  -     (448892/amavis)      /usr/sbin/amavisd (ch3-avail)           /usr/bin/perl


At this moment I commented out "#content_filter=smtp-amavis:[127.0.0.1]:10024" in /etc/postfix/main.cf
and also in master.cf

When I send an email to another account on the same server, the message is getting delivered without an issue.

Is this behind a NAT?

What kind of 'rebuilds' did you do?

127.x (local only IP) shouldn't be showing at all.
It should be showing your servers base IP.

The server is a Digital Ocean droplet and not behind a NAT

The rebuilds I did where the ones in CWP7pro (Email -> Mailserver Manager -> Rebuild Mail Server).

127 x => I don't know... I was expecting that CWP7pro knows how to set up a server 

Why I was wondering is ports 10024 & 10025 aren't used for email.
SMTP uses ports 25, 487, 586.

Local email will always work, since they are on the same server.

Check with DO to make sure port 25 is open.

The try https://www.mail-tester.com/ and see what it has to say.

Ok, I did some reading and Digital Ocean blocks port 25 by default, but when I nmap the ports its says they are open.
To be sure I contacted DO to be sure.

In meanwhile I use Sendgrid as my outgoing mail service.

As soon as I receive a reply from DO I will post it here

I don't know... I was expecting that CWP7pro knows how to set up a server 

Funny, CWP expects that you know how to set up a server

Funny, CWP expects that you know how to set up a server

This is the first time that I set up a CWP server and it is the first server set up in about 5 years. the previous servers where all ubuntu with other CPs.

Reply by Digital Ocean

Thank you for contacting DigitalOcean Support. My name is *****, and I’ll be assisting you with your request.

We understand you have concerns regarding SMTP restrictions in place on your account. DigitalOcean is not a dedicated email host and stopping spam is a constant fight. Due to this, restrictions have been imposed on all accounts.

We would also like to provide some additional background on this issue. Since IP addresses in cloud environments get used and released back to available pools very frequently, they are considered dynamic and untrustworthy. For example, you’re currently assigned an IP address and you're a responsible mail user. You follow all best practices for mail and never send spam or unsolicited mail. Later, when you no longer need that Droplet, you destroy it and the IP address is free to be assigned to another DigitalOcean user. That user takes the opportunity to send out a large volume of spam before our Security team takes action on the offending account.

Mail providers like Gmail, Microsoft, and others cannot determine if email coming from an IP is legitimate or not until it gains a poor reputation. By that time, the damage had already been done. It's safer to just block all mail coming from platforms, like Internet Service Providers and Cloud hosting environments, where IP addresses are dynamically assigned and inherently risky.

While this does reduce avenues that spammers have available to them, it also impacts legitimate users. Our Abuse Operations team is working with SBLs to get the IPs delisted. Due to this, we are restricting SMTP traffic across the DigitalOcean platform. This means that we are unable to remove the SMTP restriction that is placed on your account.

We understand that your workflow may have email needs. As a solution to this restriction, we have partnered with SendGrid to offer all our customers a better solution where you would not need to worry about IP reputation and blacklisting. Through SendGrid, you will be able to send 100 free emails per day and if your requirement is beyond the free tier, feel free to reach out to SendGrid support to opt for a better plan to meet your requirement.

But yet DO allows hacker groups in violation of their 'policies'...

As does Vultr.

Looks like they must get a kickback from SendGrid since they are pushing them specifically.

But SendGrid does have a wiki how to modify Postfix to send email thru their service.
Too bad that service is on allot of SBL's.
Now I kinda know why if DO has partnered with them for SMTP.