0

When attempting to telnet postfix from a different host in the same LAN through the FQDN (and thus the LAN's public IP), the following error occurs:

root@mailer:/var/log# telnet mail.domain.com 25
Trying 1.2.3.4...
telnet: Unable to connect to remote host: Connection refused

Other services can be reached from the exact same host, however:

root@mailer:/var/log# telnet mail.domain.com 22
Trying 1.2.3.4...
Connected to mail.domain.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u1

To make matters more intriguing, Postfix can be accessed from outside the LAN:

nunos-mbp:mailog nzimas$ telnet mail.domain.com 25
Trying 1.2.3.4...
Connected to mail.domain.com.
Escape character is '^]'.
220 mail.domain.com ESMTP Postfix (Ubuntu)

To sum thing up:

a) Postfix (running on 10.10.10.4 / mail.domiain.com) refuses connection from a host in the same LAN (10.10.10.2), but only when queried through the FQDN (mail.domain.com)

b) mail.domain.com accepts connections to other services (but Postfix) from 10.10.10.2

c) mail.domain.com accepts connections to all services, including Postfix, from the outside world

If it were a firewall issue, then I believe it would not be possible to connect to any service from 10.10.10.2 through the FQDN / public IP. It ought to be some missing parameter in Postfix, although I haven't found any clear pointers so far.

Improve this question
6
  • 2
    You need to check your firewall.
    – Michael Hampton
    Jun 8, 2014 at 4:01
  • If it were a FW issue, don't think i'd be able to reach other ports.
    – manchine
    Jun 8, 2014 at 14:48
  • Did you check it anyway? Why not?
    – Michael Hampton
    Jun 8, 2014 at 15:00
  • Yes I did. iptables is forwarding connections to 10.10.10.4 on port 25. things go wary when the connection happens from within the LAN through the public IP and only when sending mail from one postfix instance to another.
    – manchine
    Jun 9, 2014 at 0:13
  • Many ISPs block port 25 outbound to locations other than authorised mail servers to help prevent spam. This may be what you have. Where is this server located? At a data centre, cloud, at home?
    – nOw2
    Jun 9, 2014 at 6:40

1 Answer 1

Reset to default
1

Adding 10.10.10.4 mail.domain.com to /etc/hosts on 10.10.10.2 solved the issue. This way the public IP is bypassed altogether.

Still wondering why Postfix refuses connections through the public IP of the network when the request is sent from another host in that same network (whereas all other running services accept them).

Improve this answer
1
  • Although this workaround works a treat when telneting, sending a message from a postfix instance on 10.10.10.2 to postfix running on 10.10.10.4 will always take into account the MX records associated with mail.domain.com, therefore bypassing /etc/hosts.
    – manchine
    Jun 9, 2014 at 0:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .