Member Avatar for Iueras

Hi guys,

I am having a problem with my mail server configuration. I am hosting 2 mail domains (one for a game I play, the other for my business). I had set up the game domain first. It works beautifully, receiving mail from both domains just fine. I can access everything from my workstation on the LAN. The strangeness comes when I try to get my IMAP mail from any other comuter on the internet. I can access the mail server just fine using the but if I try to connect to it using mail.business-domain.com, I get a connection refused message. Both domain names point to the exact same IP address! I reconfigured postfix to use the business-domain.com address when I first started that domain.

I am sure where the problem could be. It's not a firewall problem, cause I can connect just fine coming into the same IP with a different domain. Anyone have an idea what I am looking for to fix here?

Thanks,
Charles

  • 2 Contributors
  • 2 Replies
  • 186 Views
  • 11 Hours Discussion Span
  • Latest Post Latest Post by DimaYasny

Dani AI

Generated

Good catch, — that “it works for one name but not the other” behavior is almost always a networking/binding issue rather than a Postfix bug. TCP connections use IP:port, not the DNS name, so a literal “connection refused” means nothing was listening on that IP:port (or the remote stack immediately rejected the SYN). TLS/name mismatches cause certificate errors, not refused connects.

Common causes and quick checks (these explain why the same IP can behave differently depending on the name you use):

  • IPv6 vs IPv4: a second name may resolve to an AAAA record while the server only listens on IPv4. Many clients prefer IPv6.
  • Service binding: the IMAP daemon (dovecot/couriert) or your firewall may be bound to a specific interface/address instead of 0.0.0.0. Postfix’s inet_interfaces only affects SMTP, not IMAP.
  • Router/NAT or provider filtering: port-forward rules or upstream filters can differ. CDNs or DNS hosts sometimes proxy or block non-HTTP ports.
  • Local/client DNS/hosts cache or CNAME differences that resolve to an unexpected host.

Concrete checks to run on the client and server:

dig +short A mail.business-domain.com
dig +short AAAA mail.business-domain.com
ping -4 mail.business-domain.com
ping -6 mail.business-domain.com
openssl s_client -connect mail.business-domain.com:993
ss -tlnp | grep :993   # on the mail server, shows what IPs the IMAP service listens on
iptables -L -n; iptables -t nat -L -n
tcpdump -n -i any host <your-public-ip> and port 993

If those show an AAAA but no listener on IPv6, either remove the AAAA, add IPv6 support, or force clients to use IPv4. Also verify the IMAP service’s listen setting and any NAT rules. ’s pointer to Postfix virtual-domain docs is useful for mailbox routing, but the immediate “connection refused” symptom is solved at the network/socket level rather than Postfix virtual maps.

Member Avatar for Iueras

Never mind, I found the problem. Even though business-domain.com and mail.business-domain.com are the same machine, I can only connect to mail.business-domain.com. This is a good thing, after thinking about it for a moment.

Problem solved (there was no problem).

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.