I’ve been happily using IPFire many years at my former company, now I’m evaluating it again for replacing our current VPN-solution.
Currently I’m struggling with the setup of the mail-server. We have a dedicated mail-relay here that can be used by internal whitelisted devices. The service runs plain SMTP with not auth needed.
I also tried with an IP instead of hostname for the server address.
When I click “Send test mail”, nothing happens. No email is sent, not even a connection attempt is made to the server host.
Could it be that non-authenticated SMTP does no longer work?
How can I debug this on the shell?
Thanks!
Just a quick check after enabling and setting up the mail service page did you press the Save button before pressing the Send test mail button?
Is your mail-relay in the green zone of your IPFire network?
Can you shown what is in the IPFire logs for this.
Press the Send test mail button and then go to the WUI menu Logs - System Logs - then select mail in the dropdown selection box marked Section: and choose Mail. Then press the Update button.
You will then see the log info for the dma mail system.
Of course, I saved the settings everytime.
The relay is not in the same subnet, but the host can reach the other subnet via routing. I tried ping to that host and that works.
In the log there are entries like this one:
11:13:47
dma[540379.3d470430]:
trying delivery
11:13:47
dma[540379.3d470430]:
using smarthost (mail-relay.xxxx.yyyy:25)
11:13:47
dma[540379.3d470430]:
trying remote delivery to mail-relay.xxxx.yyyy [192.168.xx.yyy] pref 0
11:13:47
dma[540379.3d470430]:
connect to mail-relay.xxxx.yyyy [192.168.xx.yyy] failed: Connection refused
Actually, the IPFire does not reach the mail-relay. There isn’t even any trace of an connect-attempts in the connection-table of the relay host.
Also, on the internal firewall that connects the two subnets (green and the subnet where the relay is in) does not show any log-entry that a TCP connect is made.
So it look to me as if the “connection refused” is already triggered on the IPFire itself before it actually tries to make an outgoing connection.
Oh, I think I found the reason: It seems that IPFire always uses the RED IP when connecting to the SMTP-server, no matter where it actually is.
Can this be changed somewhere, maybe via a firewall-rule?
Okay, I found the solution myself: I needed to add static routes for these networks.
Now it works.
Thanks, Adolf, for the hint with the logs. I did not remember that. Too long ago when I last used IPFire.
