delaying postfix until/unless VPN is up/connected
Hi, 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? For the record, I am running a fully updated Fedora 31 linux distribution but this is likely irrelevant to the question. Many thanks in advance for all your help and suggestions and best wishes, Ranjan
Re: delaying postfix until/unless VPN is up/connected
>Ranjan Maitra: > 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? Before VPN goes down: # postconf defer_transports=smtp # postfix reload After VPN comes up: # postconf -X defer_transports # postfix reload Wietse
Re: delaying postfix until/unless VPN is up/connected
On Mon, 23 Mar 2020 15:05:17 -0400 (EDT) Wietse Venema wrote: > >Ranjan Maitra: > > 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? > > Before VPN goes down: > > # postconf defer_transports=smtp > # postfix reload > > After VPN comes up: > > # postconf -X defer_transports > # postfix reload > > Wietse > Thank you for this! I am very new to this so would like some more advice. Where do I put this? Also, I have control over it going up but not always over it going down (which appears to be sometimes arbitrary). How do I do that? Btw, in case this matters, my VPN is through Cisco's Anyconnect VPN with Okta's 2-factor authentication. NetworkManager's openconnect VPN does not work any more for me because of the 2-factor authentication (or at least I could not figure it out). Many thanks again and best wishes, Ranjan
Re: delaying postfix until/unless VPN is up/connected
On 24/03/20 8:05 am, Wietse Venema wrote: Ranjan Maitra: 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? Before VPN goes down: # postconf defer_transports=smtp # postfix reload After VPN comes up: # postconf -X defer_transports # postfix reload If he's using relayhost and postfix can't reach the nexthop shouldn't postfix just defer automatically without having to do this every time? Peter
Re: delaying postfix until/unless VPN is up/connected
Ranjan Maitra: > 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? Wietse: > Before VPN goes down: > > # postconf defer_transports=smtp > # postfix reload > > After VPN comes up: > > # postconf -X defer_transports > # postfix reload Ranjan Maitra: > Thank you for this! I am very new to this so would like some more > advice. Where do I put this? Also, I have control over it going > up but not always over it going down (which appears to be sometimes > arbitrary). How do I do that? If you want to automatically execute those commands, then you need to run a program that periodically determines if the VPN is up, and that invokes the above commands when the VPN status changes. In your case, it may be sufficient to query the VPN network device status. Totally untested code follows: #!/bin/sh while : do ifconfig xxx | egrep 'UP|DOWN' sleep 2 done | while read status case "$status" in *UP*) if [ "$prev" -ne up ] then prev=up postconf -X defer_transports postfix reload fi;; *) if [ "$prev" -ne down ] then prev=down postconf defer_transports=smtp postfix reload fi;; esac I have not used VPN in years, so I don't have more specific examples. Wietse
Re: delaying postfix until/unless VPN is up/connected
On Mon, 23 Mar 2020 16:22:40 -0400 (EDT) Wietse Venema wrote: > Ranjan Maitra: > > 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? > > Wietse: > > Before VPN goes down: > > > > # postconf defer_transports=smtp > > # postfix reload > > > > After VPN comes up: > > > > # postconf -X defer_transports > > # postfix reload > > Ranjan Maitra: > > Thank you for this! I am very new to this so would like some more > > advice. Where do I put this? Also, I have control over it going > > up but not always over it going down (which appears to be sometimes > > arbitrary). How do I do that? > > If you want to automatically execute those commands, then you need > to run a program that periodically determines if the VPN is up, and > that invokes the above commands when the VPN status changes. > > In your case, it may be sufficient to query the VPN network device > status. > > Totally untested code follows: > > #!/bin/sh > > while : > do > ifconfig xxx | egrep 'UP|DOWN' > sleep 2 > done | while read status > case "$status" in > *UP*) if [ "$prev" -ne up ] > then > prev=up > postconf -X defer_transports > postfix reload > fi;; > *) if [ "$prev" -ne down ] > then > prev=down > postconf defer_transports=smtp > postfix reload > fi;; > esac > Thank you! I presume that this should go in as a cron job. I will try this out and let you know, but at least it is a good place for me to at least start if not more. Many thanks again and best wishes, Ranjan Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.
Re: delaying postfix until/unless VPN is up/connected
Corrected code follows (missing do/done). Save to file, chmod +x name-of-file, don't run this script from cron. It needs to be started at boot time, or before you make a VPN connection. #!/bin/sh while : do ifconfig xxx | egrep 'UP|DOWN' sleep 2 done | while read status do case "$status" in *UP*) if [ "$prev" -ne up ] then prev=up postconf -X defer_transports postfix reload fi;; *) if [ "$prev" -ne down ] then prev=down postconf defer_transports=smtp postfix reload fi;; esac done Wietse
Re: delaying postfix until/unless VPN is up/connected
On Mon, Mar 23, 2020 at 03:36:52PM -0500, Ranjan Maitra wrote: > I presume that this should go in as a cron job. This depends on your distribution and VPN settings. For example, on my ArchLinux system which uses OpenVPN, I'd make this a systemd unit that binds to the tun network interface... HTH, L. -- Leonid Isaev iFAX Solutions, Inc.
Re: delaying postfix until/unless VPN is up/connected
Leonid Isaev wrote: > This depends on your distribution and VPN settings. For example, on my > ArchLinux system which uses OpenVPN, I'd make this a systemd unit that binds > to > the tun network interface... I know you said you are running Fedora but I imagine that Fedora has something like this but in a different place. Doesn't Fedora have a /etc/sysconfig/network-scripts/ directory where event scripts reside? I am sure a Fedora knowledgeable person would be able to say. On my Debian (and therefore Ubuntu, Mint, other derivatives) I would add a script /etc/network/if-up.d/postfix-local (in addition to the already existing "postfix" script there) that does this when the VPN interface comes up, and a script /etc/network/if-down.d/postfix-local for the other end. The packaged "postfix" scripts there are complicated by needing to deal with every possible situation such as being a conffile in the package removed state with the rest of the package being gone. But since this is your local script you don't need to worry about what happens if Exim is actually installed instead or that someone has diverted the directories to different locations. You can make the local script much simpler and focused on your needs. But it is good to look at the packaged scripts to get concepts and ideas. Scripts in that directory are called when any interface changes state. So check that the vpn is the interface being changed. Check that it has gone up, or down, and perform the appropriate associated action. I create and debug those types of scripts by shear brute force rather than documentation. I create a sample script. I put commands like the following in it and whatever else I think I might need and no actions. I then bring interfaces up and down and look in the file to see what changes have happend to the environment variables. #!/bin/sh exec >> /var/tmp/foo.env.out 2>&1 echo echo "args: $*" env Then knowing that information I can write the script to trigger the actions I want when the VPN device changes state and it will all work event driven immediately and not need to be polled by cron. This is what I would suggest. But with the Fedora paths not the ones I mention above from Debian which I was writing simply as an example. Bob
Re: delaying postfix until/unless VPN is up/connected
On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote: > On my Debian (and therefore Ubuntu, Mint, other derivatives) I would > add a script /etc/network/if-up.d/postfix-local (in addition to the > already existing "postfix" script there) that does this when the VPN > interface comes up, and a script /etc/network/if-down.d/postfix-local > for the other end. if-up and if-down are Debian (and derivative) specific. I don't believe it is shared with distros from any other lineage. Scott K
Re: delaying postfix until/unless VPN is up/connected
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
Re: delaying postfix until/unless VPN is up/connected
Scott Kitterman wrote: > On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote: But don't forget I also said: > > I know you said you are running Fedora but I imagine that Fedora > > has something like this but in a different place. Doesn't Fedora > > have a /etc/sysconfig/network-scripts/ directory where event > > scripts reside? I am sure a Fedora knowledgeable person would be > > able to say. > > On my Debian (and therefore Ubuntu, Mint, other derivatives) I would > > add a script /etc/network/if-up.d/postfix-local (in addition to the > > already existing "postfix" script there) that does this when the VPN > > interface comes up, and a script /etc/network/if-down.d/postfix-local > > for the other end. > > if-up and if-down are Debian (and derivative) specific. I don't > believe it is shared with distros from any other lineage. Right. I said that. But many people like Fedora. I hear it is a capable OS. Therefore I assume it must have capability. Even if you and I do not know how it should be done ourselves. What about /etc/sysconfig/network-scripts/ifup-post and the others? I see a /etc/sysconfig/network-scripts/ifup-tunnel event script. Surely there is a Right Place in there somewhere to insert an event driven action? Those appear to source a file /etc/sysconfig/network that could be (ab)used for this purpose too. If I had no other way then I would wedge it in there. I am looking at RHEL which is as close to a Fedora system as I have available to peek into at this moment. But I would find it very shocking if the answer really is that Fedora does not have this capability. Bob
Re: delaying postfix until/unless VPN is up/connected
On Mon, 23 Mar 2020 18:46:11 -0600 Bob Proulx wrote: > Scott Kitterman wrote: > > On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote: > > But don't forget I also said: > > > > I know you said you are running Fedora but I imagine that Fedora > > > has something like this but in a different place. Doesn't Fedora > > > have a /etc/sysconfig/network-scripts/ directory where event > > > scripts reside? I am sure a Fedora knowledgeable person would be > > > able to say. > > > > On my Debian (and therefore Ubuntu, Mint, other derivatives) I would > > > add a script /etc/network/if-up.d/postfix-local (in addition to the > > > already existing "postfix" script there) that does this when the VPN > > > interface comes up, and a script /etc/network/if-down.d/postfix-local > > > for the other end. > > > > if-up and if-down are Debian (and derivative) specific. I don't > > believe it is shared with distros from any other lineage. > > Right. I said that. But many people like Fedora. I hear it is a > capable OS. Therefore I assume it must have capability. Even if you > and I do not know how it should be done ourselves. > > What about /etc/sysconfig/network-scripts/ifup-post and the others? I > see a /etc/sysconfig/network-scripts/ifup-tunnel event script. Surely > there is a Right Place in there somewhere to insert an event driven > action? Those appear to source a file /etc/sysconfig/network that > could be (ab)used for this purpose too. If I had no other way then I > would wedge it in there. > > I am looking at RHEL which is as close to a Fedora system as I have > available to peek into at this moment. But I would find it very > shocking if the answer really is that Fedora does not have this > capability. Thanks very much for this. Yes, indeed, on Fedora 31, there is the directory called /etc/syconfig/network-scripts and there are scripts called ifup-* and ifdown-* However, I am a little confused as to what I should do. It appears to me that an example such as here: https://blog.skbali.com/2019/03/start-a-script-on-boot-using-systemd/ would be enough to get this started at boot? Many thanks and best wishes, Ranjan -- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.