0

My work laptop is used in a “road warrior” setup. This means it’s often used in whatever WLAN and other networks I find, but I have a VPN connection to the office I can use.

The company’s mailserver accepts incoming mail over the VPN and relays it for me, but I cannot just use it as smarthost on my laptop: when I sent an eMail in offline mode, as soon as any network connection comes up, Postfix runs the queue, and (unless the public network blocks port 25) the smarthost rejects it with a 5xx code because the mail arrives from an external nōn-VPN IP.

Therefore I’m looking for a solution that puts Postfix in queue-only mode unless the VPN is up. (This can easily be detected by testing whether tun13 is up, for example. The exact method to use would, of course, rely on whatever Postfix can do to check.)

Bonus: unless the VPN is up or I’m connected to company LAN (eth0) or WLAN. But that’s not urgent.

I’m using shell wrapper scripts around ifupdown to connect, so adding extra commands there is not a hardship. Simply stopping Postfix when not connected to the VPN is, however, not a solution: package upgrades and reboots tend to start it, and sending mail to [::1]:25 must work (queue-only) when the VPN is not up.

This is Debian bullseye, and OpenVPN is used (manually started/stopped from the command line), in case that matters.

Paul
  • 3,037
  • 6
  • 27
  • 40
mirabilos
  • 737
  • 1
  • 7
  • 22
  • I don't see why the smarthost that is exclusively available for VPN&WLAN users would a) use port 25 instead of port 465 or b) respond with a *permanent* rejection for a temporary policy decision because of the currently used connection. If the smarthost would just defer instead of reject for those cases, everything else including the bonus would work without any further configuration, right? – anx Jun 07 '22 at 21:54
  • @anx A smarthost always accepts at port 25, there’s no configuration for a port, not in sendmail (which I know somewhat better) either, so that’s alright. This is really MTA to MTA communication, not MSA to MTA. The permanent rejection is also right because it’s a regular mailhost that just also allows relaying for certain local IP ranges. And anyway, I’m not in a position any more to change anything on the setup of the smarthost. – mirabilos Jun 07 '22 at 23:11

2 Answers2

2

Your situation is similar to a dialup user.

Copy /etc/postfix/main.cf to /etc/postfix/main.cf.nodefer.

Copy /etc/postfix/main.cf to /etc/postfix/main.cf.defer and add defer_transports = smtp.

In your VPN connection script link/copy /etc/postfix/main.cf.nodefer to /etc/postfix/main.cf and restart postfix.

In your VPN disconnection script link/copy /etc/postfix/main.cf.defer to /etc/postfix/main.cf and restart postfix.

Mark Wagner
  • 18,019
  • 2
  • 32
  • 47
1

Postfix supports dynamic configuration using various databases http://www.postfix.org/DATABASE_README.html

That might be too much for your setup. Since you always want to use a relayhost, you can use iptables to reject outbound on port 25 on non VPN interfaces, something like this:

iptables -I OUTPUT ! -o tun13 -p tcp --dport 25 -j REJECT

This will reject connections to port 25 from interface which is not tun13. So postfix will not be able to relay & fail. You may have to configure the queue retry parameters so that postfix does not drop the message from queue, since you want to send it when you connect to the VPN.

Do note that this will also reject port 25 connections to localhost, unless you have this:

iptables -I OUTPUT -o lo -j ACCEPT
Nilesh
  • 289
  • 1
  • 7
  • Hmm, interesting approach (would have to adopt to nftables though)… but it breaks manual SMTP testing (with netcat), which I have to do just often enough to make this approach annoying. Thanks for the idea anyway. – mirabilos Jun 09 '22 at 18:30