Still not able to send external mail

Maintenance
#1

Like others who have (helpfully) posted here, I ran into errors when upgrading MiaB. (In my case from v0.40 to v0.52.) With the steps below, all configuration errors now seem to have been cleared up, and new DNS records have been propagated. But attempts to send emails to external addresses still return the error…

“Recipient address rejected”

From the beginning: just after the upgrade, MiaB Status Check presented this error…

“MTA-STS policy is missing: STSFetchResult.NONE”

These fixes were performed…

  • provisioned new TLS certificate
  • re-ran MiaB installation script
  • rebooted
  • that Status Check error no longer displayed
  • but I cannot send email to external addresses

Started afresh…

  • deleted all custom DNS records I created previously, except these needed for my external web server…
		<my domain #1>		A	<ip of web server>
		www.<my domain #1>	A	<ip of web server>

  • ran: sudo mailinabox

  • then: sudo reboot

  • all checks are green except…

  The SSH server on this machine permits password-based login
  Web has been disabled for this domain because you have set a custom DNS record
  A redirect from <my domain #1> has been disabled for this domain...
  • still cannot send email to external addresses

Further checks: MTA-STS VALIDATOR (https://esmtp.email/tools/mta-sts/) shows (red cross) error for…

“Valid TLSRPT TXT record”

These fixes were performed…

  • in MiaB Mail & Users page created new email alias on my #1 domain for “tlsrpt@<my #1 domain>”
  • tested that this correctly forwards emails
  • in MiaB Custom DNS page, added records for my two domains…
		_smtp._tls.<my domain #1>  TXT  v=TLSRPTv1; rua=mailto:tlsrpt@<my domain #1>
		_smtp._tls.<my domain #2>  TXT  v=TLSRPTv1; rua=mailto:tlsrpt@<my domain #1>
  • now MTA-STS VALIDATOR shows all green checks
  • waited one hour
  • still cannot send email to external addresses

QUESTION #1: According to one post on this forum, an _smtp._tls TXT record should also be set for box like this

_smtp._tls.box.<my domain #1>

…but I’m not seeing a way to create records for box in MiaB’s Custom DNS page. How/should I do this?

QUESTION #2: What else can I try to allow emails to be sent to external addresses?

Edits: formatting

#2

What is the full header (or error) for this?

For question 1, on the custom DNS page, enter _smtp._tls.box in the Name input (unless I misunderstood your question).

#3

with what reasons does this come with?

#4

@daveteu and @tinkel

Thanks for the replies!

Test emails don’t make it out of Thunderbird, so there’s no bounced email header to check. From the server’s /var/log/mail.log, here’s the entry for a failed attempt to send to an aol.com address. The entry for a gmail.com address looks about the same.

Mar 3 10:28:19 box postfix/submission/smtpd[27452]: NOQUEUE: reject: RCPT from (my mail server IP info): 550 5.1.1 (recipient address): Recipient address rejected: (recipient domain); from=(sender address) to=(recipient address) proto=ESMTP helo=<[192.168.2.11]>

Is there another source of error information to look for?

@tinkel
Just adding .box at the end of the record name worked!
But after waiting an hour, emails still are not going out to external addresses.

Help!

#5

first, troubleshoot by sending email from roundcube, and identify what is 192.168.2.11. If you send to e.g. Gmail, you should see something like hello<…gmail> if it’s rejected.

Make sure you have not previously when setting up old box, modified the conf files, for example https://serverfault.com/a/355977/362794

#6

@daveteu
Thanks for those suggestions. The results are the same from Roundcube, and (I should have mentioned earlier) 192.168.2.11 is my local sending computer.

But your questions inspired a few more thoughts that may eventually lead to a solution. What do you think of this theory…

According to this RFC (https://tools.ietf.org/html/rfc3463), a 550 x.1.1 error means “Bad destination mailbox address”. Yet this is not true for my test addresses. They receive mail from other sources just fine.

Apparently though, that same error is returned from some destination servers if your sending IP has been blacklisted. A search on my IP address shows that one list provider, UCEPROTECT (http://www.uceprotect.net/en/rblcheck.php), has my address listed because it’s part of a range of suspect DigitalOcean IP addresses.

This post (https://www.digitalocean.com/community/questions/how-to-removed-my-ip-as-blacklisted-in-uceprotectl3-spam) suggests that I might not be alone with this issue.

'Will be interested in hearing your opinion on this theory. In the mean time I’ve started a DigitalOcean support ticket and am exploring mail relay services. Any other suggestions would be appreciated.

#7

I personally don’t think it has anything got to do with blacklisting. ( and you can ignore UCEPROTECT completely). I have set up another 3 mailinabox for my clients on linode + D/O and I am able to deliver mails just fine.

550 5.1.1 can be due to multiple kind of errors including MX records if you have not set it up correctly. , or dns servers not running correctly, and even accidentally bad /etc/hosts records

Pretty much since you did not share anything with regards to your domain, the domains you sending to etc, it will be pretty hard to know what is going on, and you are on your own.

#8

“…have set up another 3 mailinabox for my clients on linode + D/O…”

That’s interesting. So those IP addresses are showing up on UCEPROTECT’s blacklist and yet emails can still be sent from them?

#9

You can do a search for UCEPROTECT in this forum, there are a couple of discussions on this. You can pretty much ignore this blacklist, unless you have a specific client with their own custom mail server who insist on using this blacklist.

I have no problem with outlook, live, hotmail, gmail, yahoo, and majority of my contacts.

#11

ping (to keep this topic open, not sure if it will auto-close or not)

#12

If you truly want assistance, you’re going to have to trust someone with your domain name and actual mail log information. Feel free to PM me. Also, have you installed MiaB locally? How is it that your sending IP is 192.168.2.11?

You mention using Thunderbird as your email client, so my first inclination is to think that you have something set incorrectly within Thunderbird, however you have reported the same behavior with Roundcube, so let’s troubleshoot Roundcube first, then worry about external email clients. @patrickR

1 Like
#13

A long belated thanks. I ran out of time and temporarily reverted to a backup. Just recently found a block of time to again work on this issue. 'Never did isolate the problem but after contacting DigitalOcean support they discouraged me from using their services…

Sorry to hear that the emails that you send are blocked due to a bad IP reputation. This is one of the reasons why we recommend not run your own mail server, rather utilize dedicated mail relay services such as SendGrid or MailChimp. I would recommend referring to this article which should provide some insights on why we say this: Why You May Not Want To Run Your Own Mail Server | DigitalOcean. Also, DigitalOcean is not a dedicated email host and does not have a postmaster to maintain our IP reputation. As a result, some DigitalOcean IP ranges are blacklisted.

So instead I set up MiaB on a Vultr Cloud Compute (25GB SSD, 1GB, 1 CPU) instance. Now all seems to be well. Port 25 was available without asking and outlook/google accept tests directly into Inboxes. The IP Vultr gave me was not blacklisted anywhere (including UCEPROTECT) but you were probably right that my original problem was a configuration issue on my part.

For anyone else reading this, I largely following these Vultr MiaB install instructions (slightly different from my DO steps)…

Notes…

  1. MiaB is skipping Ubuntu 20.04 (MiaB won’t install on 20.04). No problem because Vultr still offers v18.04 instances.
  2. Contrary to the instructions, MiaB prefers the Reverse DNS to not include the IP address. So simply use box.yourDomainName

HTH

1 Like