My MiaB instance has been hosted at DigitalOcean for the past few years with no trouble. It looks like all inbound mail to my instance began to silently fail a few weeks back.
Testing today shows all green v56 on my status page and emails sent from my domain to a gmail account succeed. When I send mail to my domain from gmail, it just never seems to show up. The sender gmail end doesn’t get any failures I can see. Attempting a “telnet DOMAIN 25” fails from my home network out, while a “telnet DOMAIN 587” succeeds.
Does this sound like something suddenly blocking inbound port 25 at the DigitalOcean end? Any recommendations here?
Does you home network connect on port 25 to Google? It is common for residential ISPs to block port 25.
Is there anything in
/var/log/mail.log when Google connected to MiaB?
I did get access to a different machine, not on my local network. Telnet on 25 to my MiaB instance on digitalocean did work from that machine, so no problem there it seems.
It did a few more tests and found a hopefully useful error in the mail.log. I use a significant number of mailbox aliases that point to this particular mailbox. Unsure what it’s complaining about though. Mail sent to and from other mailboxes does succeed.
You are only adding aliases through the dashboard?
Have you changed anything else on the system?
Approximately how many aliases is a significant number?
Only aliases from the dashboard, no other changes. Somewhere on the order of 200 aliases (I know). I did seem to figure it out though.
I double checked a few recent alias additions. Normally it’s NEW_EMAIL@DOMAIN as alias with “forwards to” set as my common mailbox, say xyz@domain. On one entry I had reversed those fields somehow. So it was trying to forward mail thinking that common mailbox xyz@domain was itself an alias, hence the log error.
This closed github issue entry gave me the idea. Thanks for prompting me in the right direction @openletter ! Alisas · Issue #186 · mail-in-a-box/mailinabox · GitHub
With some additional testing, more specifically my email alias misconfiguration which gave the “unreasonable virtual_alias_maps map nesting” mail.log error was trying to route mail to a mailbox which did not exist, while the configured alias name conflicted with an existing mailbox.
For example, firstname.lastname@example.org configured to forward to doesNotExist@domain.com will send back a “could not deliver” message to the sender. But my above scenario silently fails for both sender and receiver. I’ll work this one as an issue on github [Feature Request] Detect Misconfigured Aliases · Issue #2112 · mail-in-a-box/mailinabox · GitHub
Yep. As someone with hundreds of aliases I recognize this problem; it happened to me once. It would be nice to have a pulldown menu with valid mailboxes in the 'Forwards To" field so the chance of entering a non-existent address would be lower.
But then, that would be probably unworkable for anyone with a lot of mailboxes in their MIAB as the list then would be long. So I’ll keep double checking every time I enter an alias
This topic was automatically closed 40 days after the last reply. New replies are no longer allowed.