Ranjan Maitra wrote: > I am using postfix to deliver my work mail from a remote > location. This works fine when I am on VPN (the postfix traffic goes > through VPN then). However, it gets identified as spam when VPN is > not up while sending the e-mail. Since most people do not routinely > check their spam folders especially when an e-mail is not expected > from a recipient, and since VPN does not always stay up for me, this > presents a problem. > > So, I am wondering if I it is possible to have a setup whereby > postfix is delayed unless/until VPN is up and running. If VPN is > down, then I would like postfix to be delayed until such time as it > comes up. If it is possible, how do I go about doing this? Other > ideas?
I have over the years used different "road warrior" laptop configurations. That has included the most excellent OpenVPN. And I also responded with a suggestion of what I would do there in another message. But at the moment on my laptop I am using a non-vpn port tunneled configuration. This allows me to do something which is working very well for me. YMMV. I'll mention it because you or someone might find it useful. I am tunneling port 2501 on my road warrior laptop to port 25 on my mail server. Connections on my laptop to port 2501 pop into the tunnel on the laptop and pop out of the tunnel connecting to Postfix on my mail server. Postfix sees the connection as coming from 127.0.0.1 when it pops out of the tunnel. I set 'relayhost' this way. relayhost = [127.0.0.1]:2501 This has the advantage that when the port forwarding is up then my laptop Postfix can send mail immediately. No delays. It is encrypted through the port forwarded tunnel. On my server the connection is seen as from 127.0.0.1 and therefore is permitted without additional authentication or authorization, those tasks being performed by my VPN port forwarded tunnel. And the advantage that when the vpn, port forward, or network is down, then Postfix queues the mail locally. It remains in the queue. It will be delivered when the network goes online. As mentioned in my other message the packaged Postfix has a network script that runs when the network state changes to online. When that event happens the if-up.d/postfix script calls "sendmail -q" which triggers a queue flush as soon as the network is available for it. The result is that I can read and respond to mail on my laptop offline and it will queue. Then when I later connect to a network the queued mail transfers as soon as the network goes online. It is very convenient. This works very well for me. It's a simple configuration. I have been vague about how I am port forwarding. I am using AutoSSH from https://www.harding.motd.ca/autossh/ which is clever. But probably not for everyone. OpenVPN is the most industrial strength. 'sshuttle' has interesting use cases too. I use the tool that fits the best in each situation. Bob P.S. I write too much. So stop reading at this point. But let me tell this story which I think is somewhat funny. This was some many years ago before networking was everywhere. And back in the earlier days when the Internet was not quite so hostile as it is now. I was driving across the middle of Kansas on the I-70 Interstate highway. I stopped at a rest area. They had a sign up. Complimentary WiFi available from KDOT (Kansas Department of Transportation). Wow! I could get on the Internet for a moment! While out where nothing was visible other than wheat fields. What a novelty! At the time networking was not commonly available so this was very cool. I got on on the net. I sent an email back to my wife to say where I was and wow I had found this WiFi access point at this rest area hosted by KDOT. And that I was continuing on the trek. Sent it. Didn't think about it again. It was not an important message. I did not know at the time that it though an SMTP server had accepted the message that was not my server and that it had not been delivered. But literally *six months later* I got a bounce return undeliverable from that message back to me! WAT?! I examined it in detail. It turns out that while my laptop sent the mail that it had not delivered it to my mail server where it had been configured using a very simple configuration of "relayhost = proulx.com" or similar. No security. It was simply email back then. Store and forward. Instead it turns out that KDOT routers had intercepted and diverted the port 25 SMTP transaction to one of their servers instead of mine. I had not expected that. I had not seen that ever happening before. And then they sat on the message. For months. And then six months later some admin had kicked their system and triggered a bounce of all of the queued mail. Which six months later was probably the best action as delivering it would have been more confusing. That event caused me to know that random leaf networks might be configured very strangely indeed. One cannot trust them in any way. Fortunately I learned that on a trivial message of no consequence. But one should never use simple transports on random network connections in a road warrior mobile device setting. Instead one should always require authentication. That's when I switched to a different relayhost strategy. Of course the server needs to authenticate the clients. That's expected. Everyone knows that. But clients must also authenticate the server! Don't just hand off the mail to any random MITM who offers to take the message off your hands. It might not ever get delivered. It might bounce back in six months!
